Attestation
Every claim on this page is one you can check yourself. That is the only kind worth making about somebody else's code.
What is true today
Scans of private repositories run in Confidential Space. The image below is the only one the policy will release a repository access token to.
The published image
| Environment | staging |
|---|---|
| Role | scanner |
| Reads repositories | yes |
| Image | europe-west1-docker.pkg.dev/borehole-staging/borehole/cs-scanner |
| Digest | sha256:33918f415c394e58da266343195bd856d3049625d06664d8ac0d0370ff7212e8 |
| Boot image family | confidential-space |
| Published | 2026-09-23 |
Also served as JSON at
/.well-known/borehole-workload,
so a script can fetch it without scraping this page.
That number is not decoration. The same file the service reads it from is the file Terraform pins the attestation policy to, and a test fails the build if the two disagree. A digest a customer checks against that nothing enforces would be a number we made up; a digest the policy enforces that nobody published would be unverifiable. Only the pair is worth anything.
What the guarantee actually is
A Confidential VM running the production confidential-space
boot image runs exactly one container, identified by digest, on memory the
host cannot read. That image has no shell and no SSH. We cannot
get into it either, which is the entire point — if we could, the
guarantee would be ours to break.
Google's launcher issues a token asserting which image ran, on what hardware, and whether the boot image was the production one or the debug one. Two things follow, and the second is what matters:
- You can be told which image processed your repository.
- The access token that clones your repository is released only to a workload whose attestation matches the policy. Not "we promise not to read it" — there is no path by which anything other than the published image obtains it.
How to check a report
Fetch /r/<owner>/<repo>/<commit>/attestation.json.
It carries the raw token, the published digest, and these steps as data.
Not our summary of the signed statement — the signed statement.
- Take `execution.token`. It is a JWT signed by Google, not by us.
- Verify the signature against Google's confidential computing keys, at https://confidentialcomputing.googleapis.com/.well-known/openid-configuration
- Check `swname` is CONFIDENTIAL_SPACE and that the support attributes contain STABLE. STABLE is what rules out the debug image, which permits a shell and would make the rest of this meaningless.
- Check `submods.container.image_digest` equals `digest` from /.well-known/borehole-workload. That is the image we publish as the one allowed to run here.
- Check `eat_nonce` equals the SHA-256 of the report, serialised as JSON with sorted keys and no whitespace — the same bytes served at <report url>.json. This is what ties the token to your report rather than to some other run of the same image.
The last step is the one people skip and the one that matters. A token proves an image ran. Only the nonce proves it ran your scan — without it, a single token could be waved at every report we ever issue.
What this does not prove
It does not prove what is inside the image. You can verify that Google signed a statement naming digest X, and that X is the digest we publish. You cannot pull X and read it, because the image is not public. What the guarantee gives you is that whatever X does, it did it on hardware nobody could observe, and that X is the same thing for you as for everyone else.
A stale token proves a past moment, not a present one. Tokens expire in about an hour. A verifier checking one months later is checking a signature over a statement made then, which is the correct thing to check and not the same as a live proof.
The digest can change. We publish a new one when we ship. Old attestations keep naming the digest that actually ran; the published file says what is trusted now, and is not a claim about the past.
See also what happens to your code and the Privacy Policy.