A public survey

You paste a public repository's address. Borehole's worker clones it, reads it, and deletes the copy.

1. You paste the address of a public repository. Besides GitHub, it can be on Azure DevOps, Bitbucket, Codeberg, GitLab, Gitea or SourceHut.
2. borehole.dev asks the host's API for the repository's size and default branch, so size limits apply before anything is cloned. For a host with no such API, size is checked while cloning.
3. It queues the survey for a scan worker. The web tier cannot clone: its image has no git.
4. The worker clones the repository into a temporary directory. The clone carries no credential, and the worker refuses any job for a private repository.
5. It reads the git history and the working tree, and runs the checks.
6. For a paid survey only, a language model reviews the findings. The findings and the code the review needs are sent to Anthropic. Commit authors are never shown to it.
7. The review can withdraw a finding the code contradicts, and the report lists each withdrawal with its reason. It never adds a finding and never raises a band.
8. The worker keeps the facts it read, not the source, so the reading can be re-run under new checks without a second clone. Author names and addresses are hashed under a key made for this survey and discarded, so nobody, Borehole included, can test a guessed address against them.
9. It deletes the working copy. The delete runs when the survey fails too.
10. It stores the report.
11. The survey's page becomes the report.

A private survey

The collector runs where the repository is: your laptop, your CI, or a server of yours. It reads the repository there and sends facts and short excerpts. Your repository is never sent, cloned or held by Borehole.

No language model reviews a private survey. The review reads whole files, and a private survey never sends a whole file, so a private report is the checks' work alone, paid or not.

1. You run borehole collect . in the repository. The collector asks borehole.dev for the detection rules, with your collector token. The token needs the collect scope (Keys and tokens).
2. The rules are not shipped in the package. They are fetched for each run, signed, and marked so a leaked copy can be traced to the account it was issued to.
3. The collector checks the signature against Borehole's public key, which it ships, and refuses rules that are unsigned or signed with any other key.
4. It reads the git history and the working tree on your machine. From collector 0.7.12, author names and addresses are hashed under a key made for this survey and never sent.
5. It builds the bundle: never whole files; facts and short excerpts of up to 120 characters where a check matched. --dry-run prints the whole bundle and sends nothing about the repository.
6. It sends the bundle to borehole.dev.
7. The web tier checks the upload's size and the collector's version without parsing it, and reserves a use of the key your account holds. Borehole accepts collector 0.7.10 or later.
8. It queues the bundle for a worker.
9. The worker reads the bundle and deletes it in the same step, then scores it with the same checks as a public survey.
10. It stores the report. A private report is never listed. It is readable by your account, by anyone GitHub says controls the repository, by Borehole's administrators, and by anyone you give a share link.
11. The collector prints the report's link.

What happens to your code Everything the bundle can hold, field by field, and what we still cannot prove.

A private survey in your own cloud

The same collector can run in a Confidential VM in your own Google Cloud project. The repository stays in your project, and Borehole never receives credentials to it. What this adds: Google Cloud attests which collector image ran, so a buyer can check the facts were not edited on the way.

1. You run our script in your project. It starts one Confidential VM from the collector image we publish, pinned by its digest.
2. The VM clones the repository with a read-only token you store in your project's Secret Manager. The clone stays in your project.
3. The collector fetches the signed rules and builds the bundle, as in a private survey.
4. It asks Google to attest the bundle's SHA-256.
5. Google signs a token that names the image that ran and that hash.
6. The collector sends the bundle and the token.
7. Borehole checks the token before it scores anything, and the report carries it. The bundle is then scored and deleted as in a private survey.
8. The script deletes the VM.

Run it in your own cloud Every command, and what it does not prove.