What Attestree signs for each installer, and how to check it

This page holds the detail behind the first promises on the trust page: a signed record for each installer Attestree verifies, and an SBOM made before anything reaches your fleet.

The signed statement

When a detonation verifies an installer, the platform writes a signed statement about it: an in-toto Statement in a DSSE envelope, signed with ECDSA P-256 by your deployment’s own catalog-attest key. Its subject is that installer’s SHA-256, so a version can have several statements, one for each installer a sandbox verified. The statement also records the package, the run (its network posture and when it ran), the run’s evidence digests, the SBOM’s digest or the reason there is none, and the attestation tier at signing. The statement does not yet name the installer’s architecture or install scope, or the architecture of the sandbox that ran it: the console shows those, and the statement does not prove them. The platform keeps it with the version byte for byte. You download it from the version’s page, together with the SBOM, a component summary and keys.json, the deployment’s public keys.

Signing follows the attestation; it does not gate it. If signing fails, the version stays attested, and the platform retries the statement up to eight times. After that, a re-test signs it.

Three cases have no statement:

• Verified before platform 0.240.0. There is no backfill. The installer gets its statement when its version is re-tested, either by hand or by the paced re-test sweep you arm from the console with a typed confirmation. The sweep re-tests attested winget versions one at a time, about 25 a day by default, only while the detonation queue is idle, and pauses itself after repeated failures.
• Vouched for by hand. An installer vouched for by hand is not attested. On Community Edition it is an unverified-installer acceptance, with no statement. A dedicated instance has no hand vouch.
• Attested through a waiver.

The statement says what your deployment saw. It is not SLSA build provenance, because Attestree does not build a vendor’s installer, and it does not say the installer is safe. The format is specified at /attestation/detonation/v1/.

What the SBOM covers

Syft runs inside the sandbox during the detonation and writes a CycloneDX document. What it scans depends on the golden image the sandbox was cloned from:

• An image built with platform 0.240.0 tooling or later scans the folder the installer registers, plus each new folder the install created, at most eight in all, as CycloneDX 1.6.
• An older image scanned only the folder the installer registers. A package that registers none got no SBOM.

When a version has no SBOM, its statement records why.

From platform 0.239.0 on, the platform keeps each run’s SBOM document, up to 32 MiB; for a larger one it keeps only the digest. A version with a signed statement offers its SBOM for download beside a component summary. Both are labelled as third-party SBOMs: a scan of what an installer put on disk, not the vendor’s own bill of materials. The summary is not a top-level-dependency view, because a scan of installed files cannot tell top-level components from transitive ones.

Checking it offline

wep-bundle-verify ships with every platform release, for Windows and Linux. One command checks a version’s statement:

wep-bundle-verify attestation <pkg>_<ver>.intoto.jsonl --key keys.json --expected-fingerprint <sha256>

--key is required, because a certificate inside an envelope never vouches for itself. Add --artifact <installer> to check that the installer you hold is the statement’s subject, and --sbom <file> to check the SBOM it names.

A 35-line Python sample checks a statement too. Its one dependency is the cryptography library.

keys.json is not signed: it is a convenience copy, never a trust anchor. Pin a fingerprint you took from a channel you trust, not from the files you are checking. The same tool checks the other exported formats; the commands are on the trust page.

Sigstore, Rekor and cosign

You do not need to wrap anything in cosign. The statement is a DSSE envelope, not a Sigstore bundle. A Rekor transparency-log entry for each attestation is wired, but off by default and not yet proven against the public log. Cosign is what we sign our own release images with; the statements do not use it.

Where the signing keys live

Your deployment holds two signing keys:

• the catalog-attest key signs statements, catalog evidence bundles and inventory exports;
• the span key signs the platform’s audit events and the audit bundle.

Their fingerprints differ.

Community Edition keeps both as files on the host. A dedicated instance keeps them in a Key Vault in your own Azure subscription: a standard vault, not HSM-backed. HSM-backed custody and air-gapped evidence sync are not built.