In-toto attestation is a signed, machine-readable statement that records a verifiable fact about a software artifact — who built it, from what source, through which steps — expressed in a standard JSON format called the in-toto Attestation Framework. Developed by researchers at NYU and first presented as an academic supply chain security framework at USENIX Security 2019, in-toto has since become the metadata format underneath standards like SLSA, and it now ships by default in tools including GitHub Artifact Attestations, Sigstore's cosign, and npm's package provenance feature. Each attestation contains a "subject" (the artifact's name and cryptographic digest), a "predicateType" (a URI identifying the kind of claim being made — build provenance, a vulnerability scan, an SBOM), and a "predicate" (the claim's payload). Security teams use in-toto attestations to answer a specific question after incidents like SolarWinds (2020) or Codecov (2021): can we prove, cryptographically, that this binary actually came from the source and pipeline we think it did — not just assert it in a README?
What Is an In-toto Attestation, Exactly?
An in-toto attestation is a signed JSON document that binds a claim to a software artifact using cryptographic hashes, following the in-toto Attestation Framework specification (informally "ITE-6"). The framework defines a layered structure: a "Statement" layer that's identical across all attestation types, and a "Predicate" layer that varies by use case. The Statement always includes _type (set to https://in-toto.io/Statement/v1), subject (an array of artifacts identified by name and digest, typically SHA-256), predicateType, and predicate. This design lets a single verification tool check the signature and subject binding on any attestation, regardless of what claim it's making, while letting the ecosystem define new predicate types without changing the core spec. The project has been hosted by the Cloud Native Computing Foundation since 2019, first as a Sandbox project and later promoted to Incubating status, alongside neighboring projects like Sigstore and SLSA.
This matters because before in-toto, supply chain "provenance" was usually an unsigned text file, a build log nobody checked, or a claim buried in release notes. In-toto turns that into a structured, cryptographically verifiable record that can be checked automatically at deploy time — the same way a TLS certificate is checked automatically instead of trusted on sight.
What's Inside an In-toto Attestation's Predicate?
The predicate holds the actual content of the claim, and its predicateType URI tells a verifier how to interpret it. The most widely deployed predicate type is SLSA Provenance (https://slsa.dev/provenance/v1), which records the builder identity, the build's entry point, the source repository commit, and the materials consumed during the build — enough detail to answer "was this artifact built by the CI system I authorized, from the commit I expect?" Other common predicate types include in-toto's original "Link" metadata (recording each step of a supply chain — clone, compile, test, package — and the materials/products hashed at each step), Sigstore's vulnerability-scan predicate (https://cosign.sigstore.dev/attestation/vuln/v1), and SBOM predicates that wrap a full CycloneDX or SPDX document as the payload.
That last point is the one teams find counterintuitive: an SBOM can itself be the thing an in-toto attestation signs and vouches for, rather than a competing format.
How Is an In-toto Attestation Different From an SBOM?
An SBOM is an inventory; an in-toto attestation is a signed proof about that inventory or about how an artifact was produced. A CycloneDX or SPDX SBOM lists the components, versions, and licenses inside a piece of software — it answers "what's in here?" An in-toto attestation answers a different question: "who claims this, and can I verify they're telling the truth?" You can generate a perfectly accurate SBOM and still have no way to know it wasn't tampered with after generation, or that it actually corresponds to the artifact you're about to deploy. Wrapping that SBOM in a signed in-toto Statement — with the artifact's digest as the subject — closes that gap. In practice, mature pipelines produce both: an SBOM for component visibility and license/vulnerability matching, and one or more in-toto attestations (provenance, vulnerability scan, sometimes the SBOM itself) that make specific, checkable claims about that SBOM and the build that produced it.
How Are In-toto Attestations Signed and Verified?
In-toto attestations are signed using the DSSE (Dual-Signature Envelope) format, which wraps the Statement's JSON payload with one or more signatures and a payload type identifier before it's transmitted or stored. Signing keys can be static keypairs managed by an organization, but the more common pattern since 2021 is Sigstore's "keyless" signing: a CI job authenticates with an OIDC token (from GitHub Actions, GitLab CI, etc.), Sigstore's Fulcio certificate authority issues a short-lived (10-minute) code-signing certificate bound to that identity, and the signature plus certificate are logged in Rekor, a public append-only transparency log. Verification then checks three things: the signature is valid, the certificate chains to a trusted root and matches an expected identity (e.g., "this workflow file, in this GitHub repo, triggered by a push to main"), and the subject's digest matches the artifact being deployed. cosign attest and cosign verify-attestation are the most widely used CLI commands for producing and checking these end to end, and they store the resulting attestation as a separate OCI artifact alongside the container image it describes.
Where Are In-toto Attestations Used in Production Today?
In-toto attestations are already the backbone of several mainstream supply chain security products, not just an academic proposal. SLSA v1.0, published in April 2023, formally requires that build provenance be expressed as an in-toto attestation to satisfy its Build track levels. GitHub shipped Artifact Attestations — which generate signed in-toto/SLSA provenance for build outputs directly inside GitHub Actions — as a public beta in late 2023 and took it generally available in mid-2024, so any GitHub Actions workflow can now call actions/attest-build-provenance and get a verifiable attestation without standing up separate signing infrastructure. npm added provenance statements to its CLI in 2023, letting published packages carry an in-toto/SLSA attestation that ties the tarball back to the exact GitHub Actions run and commit that built it — visible on npmjs.com as a "Provenance" badge on the package page. PyPI followed with PEP 740, adding native support for digital attestations on uploaded packages. Kubernetes' own release process and Google's GUAC (Graph for Understanding Artifact Composition) project both consume in-toto attestations as first-class inputs for build and dependency graphs.
The common thread: in-toto isn't a standard security teams have to bolt on separately — it's increasingly emitted automatically by the build tooling developers already use, which means the security problem is shifting from "how do we generate attestations" to "how do we verify them at scale and act on the gaps."
How Safeguard Helps
Safeguard treats in-toto attestations as a first-class signal, not a compliance checkbox to tick after the fact. The platform ingests and verifies in-toto and SLSA provenance attestations attached to your builds and container images, then cross-references the recorded subjects and build steps against the SBOMs Safeguard generates — or ingests from your existing CycloneDX/SPDX pipeline — to flag artifacts shipping without verifiable provenance. Griffin AI, Safeguard's reasoning engine, combines those attestation predicates with reachability analysis to determine whether a component flagged by a missing or suspicious attestation is actually exploitable in your running application, rather than surfacing every gap as an equally urgent alert. When Safeguard finds a build missing a required attestation, or provenance pointing to an untrusted builder identity, it can open an auto-fix pull request that pins the dependency to an attested version or adds the missing signing step to the CI workflow. The outcome is attestation coverage you can demonstrate to auditors on demand, paired with remediation that doesn't sit in a backlog waiting for a human to triage it.