In-Toto Attestations as Regulatory Evidence

The EU Cyber Resilience Act sets a vulnerability-reporting deadline for September 2026, with a machine-readable SBOM requirement following in December 2027. The EU AI Act imposes a documentation and traceability deadline of August 2, 2026, for covered AI systems. OMB M-26-05, issued January 23, 2026, rescinded the standardized self-attestation approach and directed agencies to use a risk-based model for software assurance, including requesting SBOMs when appropriate, making the prior form superseded but the underlying obligation to demonstrate evidence ongoing. That last point matters because it is easy to misread M-26-05 as loosening the requirement. It changed the mechanism agencies use while leaving the underlying expectation that vendors can produce evidence on demand in place.

The UK's Cyber Security and Resilience Bill signals a wider scope of covered entities and faster incident reporting timelines, reinforcing that assurance must be operational, repeatable, and provable. None of these frameworks were written in coordination with each other, yet they converge on the same demand: show the work, not just the result.

That convergence is reshaping how compliance gets built. Manual checklists, the kind a vendor fills out once a year and files away, are giving way to automation and what practitioners call compliance as code, because procurement officers, auditors, and enforcement bodies increasingly want evidence they can check themselves rather than assertions they have to trust. A vendor claiming it signs artifacts and tracks provenance is no longer sufficient. The vendor has to produce the SBOM, the signature, and the attestation on request. The commercial stakes are direct: a vendor that cannot produce this evidence risks disqualification from procurement altogether, which turns what looks like a paperwork requirement into a revenue question. This is the backdrop against which in-toto attestations have moved from a supply-chain security tool used by a narrow set of security engineers into a primary mechanism for satisfying regulatory evidence requirements across jurisdictions.

What an in-toto attestation is and what it cryptographically proves

An in-toto attestation is a signed document that binds metadata to an artifact, in a way that lets any downstream system verify the metadata hasn't been altered and still corresponds to the exact artifact under evaluation. That sentence is doing more work than it first appears to. A signature alone proves an artifact hasn't changed since it was signed. It says nothing about who built it, what inputs went into it, or whether the process that produced it followed any particular set of rules. An in-toto attestation closes that gap by capturing the full chain of custody: which functionary performed a step, from what inputs, producing what outputs, under what conditions.

The framework defines this through a small number of structural pieces. Functionaries are the entities that perform supply chain steps, building code, running tests, signing artifacts, and each one holds its own keypair and signs the attestation for the step it performed. Layouts define what's expected across the pipeline: which steps must happen, which functionaries are authorized to perform each one, and what inspection rules a verifier must apply before trusting the result. The layout is effectively a policy document, written in advance, that says who is allowed to do what, and anything that happens outside those bounds fails verification rather than passing silently.

For portability across tooling, the attestation payload gets wrapped in a DSSE envelope, the Dead Simple Signing Envelope, which carries a payload type, a base64-encoded payload, and one or more signatures. This wrapper is why in-toto attestations interoperate with SLSA's v1.x provenance predicates: SLSA provenance is itself expressed as an in-toto attestation, using this same envelope format, rather than a separate, incompatible scheme.

The distinction that matters most for a compliance-minded reader is the one between signing and attesting. Research synthesized by Emergent Mind, drawing on 2026 work published in ScienceDirect, states that signing alone does not prove correspondence between a document like an SBOM and the artifact it describes. Existing signing and provenance mechanisms protect integrity (nobody tampered with this file) and traceability (this file came from this source), but they lack a consumer-side way to reproducibly verify that the described build process actually produced the artifact in hand. An in-toto attestation, with its functionary signatures tied to specific pipeline steps and its layout defining what was supposed to happen, is built to close exactly that gap. It gives a downstream verifier, whether that's an automated policy engine or a human auditor, something to check against.

How attestation structure maps to regulatory evidence requirements

The reason in-toto attestations have become central to regulatory compliance rather than a niche security practice is that their structure happens to match what regulators are asking for, almost clause for clause, across frameworks that were never written with each other in mind.

Start with EO 14028, which mandated SBOMs for companies selling software to the federal government. The CISA attestation form built around SSDF requires vendors to certify that they followed specific secure development practices. A certification is just a signature on a claim unless there's a way to check it, and that's where in-toto link files do their work: a link file generated at each pipeline stage gives an auditor machine-readable evidence that build integrity checks, test execution, and signing steps actually happened, and that they were performed by functionaries authorized to perform them. SSDF's requirement to protect the build environment and produce well-secured software maps directly onto the layout's authorized-functionary model: the layout states up front who is allowed to do what, and any deviation causes verification to fail rather than pass through unnoticed.

The EU Cyber Resilience Act asks a related but distinct question. Its September 2026 vulnerability-reporting deadline and its December 2027 requirement for machine-readable SBOMs together demand that an organization can say, at any moment, what's inside a shipped artifact and trace that artifact back to the build that produced it. An SBOM predicate carried inside an in-toto attestation satisfies both halves of that demand at once: the SBOM supplies the content, and the attestation's signature supplies proof of when and how that SBOM was generated. The Rivet/Sigil supply-chain integration design illustrates what this looks like assembled into a single compliance check: SBOM present, vulnerability assessment current, SLSA provenance level confirmed, vulnerability reporting capability present, with each condition backed by an attestation or an attestation-derived artifact rather than a manual assertion.

The EU AI Act extends the same logic to a different kind of artifact. Its August 2, 2026, deadline requires documentation and traceability for covered AI systems, and for an AI artifact, that means recording exactly which datasets, base models, container images, and hyperparameters contributed to a trained model. The AIBoMGen proof-of-concept platform, described by Vandendriessche and colleagues in January 2026, treats this as a hard requirement: only artifacts provably anchored to their training context through signed link files are valid for regulatory purposes. A model card or a data-sheet filed separately from the model doesn't meet that bar. A signed link file binding the model to its training inputs does.

SLSA produces the enforcement mechanism that all three of these mappings rely on. An InfoQ article lays out how SLSA's graded levels translate into concrete tooling requirements: Level 2 requires signed, tamper-resistant provenance, typically produced through cryptographic signing by a hosted build platform, with Sigstore and a transparency log as common (though not mandatory) tools for achieving it; Levels 3 and 4 add verified source control and isolated build environments. At every one of those levels, the layout-and-link model is the mechanism actually doing the enforcement work. That's not a coincidence of design. SLSA provenance is itself a predicate type expressed within the in-toto attestation format, so the two frameworks aren't competing standards a team has to choose between. SLSA defines the policy levels; in-toto supplies the cryptographic substrate those levels are built on.

Looked at together, EO 14028, the CRA, the AI Act, and SLSA aren't four separate compliance problems requiring four separate tools. Each one is asking some version of the same question: what does this artifact contain, how was it built, who authorized each step, and did it pass the checks it was supposed to pass. The in-toto layout, link, and verification model is structured to answer exactly that question. That is why the same attestation infrastructure can satisfy federal procurement rules, EU product-safety law, EU AI governance, and a voluntary industry framework without four different implementations.

Why post-hoc attestations fail against build-native generation

An attestation assembled after the build has already finished, stitched together from logs and CI output, proves only that someone wrote down a plausible account of what happened. It does not prove the account is true, because nothing tied the signature to the moment the work occurred. Only attestations generated in-band, at each pipeline step, by the functionary actually performing that step, carry the evidentiary weight regulators are asking for.

The mechanism that makes this possible is straightforward. The attestation is a byproduct the build step generates as it runs.

That distinction has a concrete consequence for tamper-resistance. When signing happens at execution time, using the authorized functionary's keypair, any later tampering with the artifact breaks the chain: the product hash recorded in the link file will no longer match the artifact a verifier is checking. A post-hoc attestation can't offer this guarantee, because it's generated by inspecting the artifact after the fact rather than alongside its creation. A sufficiently careful tamperer can alter both the artifact and the attestation describing it in a way that still looks consistent.

There's a second failure mode that build-native generation addresses: drift. Research synthesized by Emergent Mind, citing work published in MDPI, points out that traditional audits conducted as a snapshot in time, paired with compliance tooling that isn't integrated into the delivery pipeline, struggle to keep up with how fast continuous delivery actually moves. Compliance drift follows: the audited state and the actual running state diverge, and remediation lags behind. Generating the attestation at build time, storing it with the artifact, and verifying it again at deploy time closes that gap structurally, because there's no interval during which the audit record and the deployed reality can quietly separate.

This logic has produced a specific operating model in continuous delivery pipelines, sometimes called the Continuous Compliance Framework. Instead of asking only whether a user or service account is authorized to deploy, the pipeline asks whether the artifact itself carries a valid, signed attestation from CI proving it passed the required checks. Verifying that attestation independently, rather than trusting the CI system's say-so, creates a zero-trust handoff between build and deploy. In a Kubernetes environment, this handoff happens at the admission controller: tools like Sigstore and Cosign sign container digests, in-toto provenance travels with the image, and policy engines at the cluster gate deployments based on the attestation, CVE thresholds, and residency rules. The attestation stops functioning only as an audit record and becomes the credential that gets an artifact deployed at all.

Production systems already run on this model rather than treating it as a research proposal. The attestation is what the pipeline produces. GitHub has moved in the same direction: InfoQ reports that GitHub introduced artifact attestations and SBOM attestation as part of its Actions platform, letting teams generate signed provenance aligned with the SLSA specification as a built-in part of the workflow, rather than a separate step bolted on afterward.

Environment consistency as a prerequisite for attestation validity

An attestation is only as trustworthy as the environment that produced it. A build that generates different output depending on which machine ran it, which compiler flags were set, or which tool versions happened to be installed cannot produce attestations that satisfy the reproducible-and-verifiable standard regulators are converging on, because there is no single build to verify against.

Work presented at the S3C2 Government Summit in 2025, synthesized by Emergent Mind, frames reproducible build infrastructure as a direct contributor to integrity: documented, consistent build environments, isolated build processes, and verifiable provenance together make build output deterministic, so a given set of inputs reliably produces the same output every time. That determinism is what lets a third party take the recorded inputs, rerun the build, and check that the result matches what was shipped.

Without it, the provenance chain fragments in a specific way. If a developer's laptop, the CI runner, and the production build server differ in package versions, compiler flags, or tool paths, an attestation signed in CI proves only what that particular CI build produced. It doesn't prove the build is reproducible, and it doesn't prove that what a developer builds locally matches what CI ships. Two attestations describing supposedly the same software can both be valid on their own terms and still describe two different artifacts, because the environments that generated them were never actually the same environment.

Every regulatory mapping laid out above, from SSDF's build-environment protections to SLSA's isolated-build requirements at Level 3 and above, assumes the environment generating the attestation is itself stable and known. Environment consistency is the condition that gives the attestation its meaning.