A software attestation is a signed, verifiable claim about how a piece of software was built, tested, or secured — created by a producer and checked by a consumer before the software is trusted or deployed. Attestations turned from a niche supply-chain concept into a legal requirement in the United States on March 11, 2024, when CISA published the Secure Software Development Attestation Form under OMB Memorandum M-22-18. Any vendor selling software to a federal agency now has to attest, in writing, that it followed NIST SP 800-218's Secure Software Development Framework. Outside government contracting, attestations show up as SLSA provenance files, in-toto link metadata, and signed SBOMs attached to container images and releases. They exist because a changelog or a vendor's word is not evidence — a cryptographically signed, machine-readable record is. This post breaks down what attestations actually contain, which standards define them, and how to tell a real one from a rubber stamp.
What Is a Software Attestation?
A software attestation is a structured, signed statement asserting a specific fact about a software artifact — for example, "this container image was built from commit a1b2c3d in a GitHub Actions runner on June 4, 2026, with no network access during the build step." Unlike a self-reported security questionnaire, an attestation is designed to be machine-verifiable: it names the artifact by cryptographic hash (not filename or version string), it's signed by an identity tied to the build system or the producer, and it can be checked automatically by a policy engine before deployment. The in-toto framework, which underpins most modern attestation tooling, defines this as an "ITE-6" attestation: a signed envelope (DSSE — Dead Simple Signing Envelope) wrapping a predicate type and a subject (the hashed artifact). Attestations can cover provenance (how something was built), vulnerability scan results, code review sign-off, or SBOM contents — each is a separate, separately signed claim rather than one omnibus document.
What's the Difference Between an Attestation and an SBOM?
An SBOM lists what's inside a piece of software; an attestation is the signed proof of a claim about that software, which can include the SBOM itself as its payload. A CycloneDX 1.6 or SPDX 3.0 SBOM is inert data — a JSON file naming components and versions, with no built-in guarantee it matches the artifact it claims to describe or wasn't edited after the fact. Wrap that same SBOM in an in-toto attestation, sign it with a key or keyless identity (via Sigstore), and hash-bind it to the specific artifact, and it becomes verifiable: a consumer can confirm the SBOM was produced by the claimed build pipeline and hasn't been altered since. This distinction mattered in practice after the May 2021 Executive Order 14028, which mandated SBOMs for federal software; agencies quickly found that unsigned SBOMs delivered as email attachments were nearly impossible to trust or automate against, which is part of why the subsequent attestation requirements insist on cryptographic binding rather than a document handoff.
Why Do Federal Contractors Now Have to Sign Attestation Forms?
Federal contractors selling "critical software" to the U.S. government must submit a signed attestation because OMB Memorandum M-22-18 (issued September 14, 2022, revised by M-23-16 in June 2023) made it a condition of sale, not a best practice. CISA's self-attestation form, finalized March 11, 2024, requires software producers to affirm compliance with specific NIST SP 800-218 practices: development environments are separated and access-controlled, provenance data is maintained for all components, automated vulnerability scanning runs prior to release, and a vulnerability disclosure process exists. Agencies can accept a third-party assessment instead of self-attestation, but the deadlines were real: initial critical-software attestations were due within 90 days of collection guidance, moving to 180 days for the rest of an agency's software inventory. A false attestation exposes the vendor to False Claims Act liability — a materially different risk profile than an SBOM that simply turns out to be incomplete.
What Technical Standards Define an Attestation's Format?
Two frameworks dominate: in-toto for the attestation envelope and predicate structure, and SLSA (Supply-chain Levels for Software Artifacts) for what a trustworthy build process has to prove. SLSA, which reached v1.0 in April 2023 under the OpenSSF, defines four levels: Level 1 requires a documented, scripted build process; Level 2 requires a hosted build service that generates signed provenance automatically; Level 3 requires that provenance be non-forgeable, generated in an isolated, ephemeral build environment the source code can't tamper with. Google, npm, and PyPI's Trusted Publishing all target SLSA Level 3 build provenance as of 2024-2025, meaning packages published through GitHub Actions OIDC tokens carry provenance attestations without a human ever holding a signing key. In-toto's role is narrower but foundational: it standardizes the JSON envelope (_type, subject, predicateType, predicate) so that a SLSA provenance attestation, a vulnerability-scan attestation, and a code-review attestation are all parseable by the same verification tooling regardless of who issued them.
How Are Attestations Signed and Verified Without Managing Keys?
Most new attestation pipelines use keyless signing through Sigstore, which eliminates long-lived private keys by issuing short-lived certificates tied to an OIDC identity (a GitHub Actions workflow, a Google account) at signing time. Sigstore's Fulcio component issues a certificate valid for roughly 10 minutes bound to that OIDC identity, cosign uses it to sign the attestation, and the signature plus certificate are logged to Rekor, an append-only transparency log, so anyone can later prove the signature existed at a specific time without trusting the signer's continued cooperation. This is how npm audit signatures and cosign verify-attestation work in practice: a consumer checks that the artifact's hash matches the attestation subject, that the signature verifies against a certificate chained to a trusted OIDC issuer, and that a corresponding entry exists in Rekor. The npm registry began accepting Sigstore-based provenance attestations for published packages in April 2023, and by 2025 tens of thousands of packages, including widely used ones like chalk and debug, published provenance this way.
What Happens When an Attestation Is Missing, False, or Unverifiable?
When an attestation is missing or fails verification, the correct default is to treat the artifact as unproven — not to assume good faith. The XZ Utils backdoor discovered in March 2024 (CVE-2024-3094) is instructive here: the compromised release tarballs differed from the project's public git history, something a build-provenance attestation binding the release artifact to a specific, inspectable commit would have exposed immediately, because the tarball's hash would never have matched anything the attestation could legitimately sign. Similarly, SolarWinds' 2020 Orion compromise involved a build system compromise that a self-issued vendor claim ("we tested this") did nothing to catch, precisely the gap SLSA Level 3's tamper-resistant build isolation targets. Unverifiable attestations aren't automatically malicious — a broken key rotation or an expired certificate produces the same failure signal as a forgery — but the remediation is the same either way: block deployment, or at minimum flag the artifact for manual review, until the chain of custody can be reconstructed.
How Safeguard Helps
Safeguard turns attestation data from a compliance checkbox into an active control. Griffin AI ingests SLSA provenance, in-toto link metadata, and signed SBOMs alongside your dependency graph, then cross-references what an attestation claims against what reachability analysis actually finds exploitable in your running code — so a vulnerable component with no attestation and a reachable call path gets prioritized over one that's attested but never executed. Safeguard generates CycloneDX and SPDX SBOMs directly from your build pipeline and can also ingest third-party attestations for verification against Rekor and known OIDC issuers, flagging gaps before an auditor or a CISA attestation deadline does. Where an artifact fails verification or lacks required provenance, Safeguard opens an auto-fix PR to pin to an attested version or add the missing signing step, closing the loop between detection and remediation instead of leaving it as an open finding.