Visor de atestaciones in-toto online

Three layers of an attestation

An in-toto attestation is a signed claim about software artifacts, built in layers by the in-toto attestation framework:

• The envelope. DSSE — the Dead Simple Signing Envelope — carries a payloadType, the base64 payload and one or more signatures. The signatures do not cover the payload alone but its pre-authentication encoding, DSSEv1 <len> <type> <len> <payload>, so a payload cannot be reinterpreted as another type.
• The Statement. The payload of type application/vnd.in-toto+json is a Statement (https://in-toto.io/Statement/v1, or the older v0.1): a list of subjects, each a name and a set of digests, and a predicateType saying what kind of claim follows.
• The predicate. What is claimed about the subjects: how they were built, how they were verified, what they contain.

The viewer peels the layers one by one and shows each. It reads a bare envelope, the .intoto.jsonl files that release pages publish (one envelope per line), Sigstore bundles with a DSSE envelope, the list the npm registry returns for a package version, and an unsigned Statement — the last only to read it, since nothing vouches for it.

SLSA provenance and the other predicates

The predicate you meet most is SLSA build provenance. SLSA provenance v1 says which builder ran (runDetails.builder.id), what kind of build it was (buildDefinition.buildType), with which external parameters — for GitHub Actions the repository, workflow, ref and trigger — and which sources and dependencies it resolved, with their digests; v0.2 says the same with builder, invocation.configSource and materials. The viewer lists those fields, and warns when a field the specification requires is missing. It also reads SLSA verification summaries (VSA: who verified what, when, against which policy, with what result), SPDX and CycloneDX SBOMs (their packages or components), npm publish attestations, in-toto links and test results. Any other predicate is shown with its fields, uninterpreted.

Who signed it

A signature is checked with every key you paste — PEM public keys or certificates, JWKs, OpenSSH public keys — trying the schemes each key type allows (ECDSA in ASN.1 or IEEE P1363 form, RSA PKCS #1 v1.5 and PSS, Ed25519, Ed448). Envelopes made by slsa-github-generator and cosign carry the Sigstore certificate next to the signature: the viewer verifies with its key, checks that it chains to the Sigstore public-good root at its issuance, and shows the workflow identity and CI claims it records. That proves the certificate was issued by Fulcio, not that the signature was logged in Rekor: a DSSE envelope has no room for the log entry. For the full Sigstore verification — transparency log, time-stamps, the identity you expect — use the bundle with the Sigstore bundle verifier.

Finally, give it the file the attestation is about, or its digest: the viewer compares the file's SHA-256, SHA-384, SHA-512 and SHA-1 with every subject and names the one that matches. A provenance that verifies but does not list your file says nothing about your file.

The examples are a release asset of slsa-verifier v2.6.0, the attestations npm serves for sigstore@3.0.0, a bundle of the sigstore-conformance suite, and the decoded provenance Statement of that npm package. For npm packages, the npm provenance checker fetches the attestations itself and checks them against the package; why provenance is worth publishing is the subject of Signing releases with Sigstore.