An artifact attestation is a signed, machine-readable statement that makes a verifiable claim about a specific software artifact — such as how it was built, what it contains, or that it passed a test. The statement is cryptographically bound to the artifact by its content digest and signed by an authority, so anyone can confirm both who made the claim and which exact artifact it applies to. Attestations are the general-purpose container that carries supply chain metadata like provenance, SBOMs, and vulnerability results in a consistent, verifiable form.
Why It Matters
Supply chain security depends on being able to trust metadata, not just artifacts. It is easy to publish a document claiming "this image was scanned and is clean" or "this package came from our repo" — the hard part is proving those claims are authentic, unaltered, and about the artifact in front of you rather than some other build. Loose metadata in a wiki or a README proves nothing.
Attestations solve that by making every claim tamper-evident and self-verifying. Because the claim is signed and pinned to a digest, a consumer can enforce policy automatically: accept an artifact only if it carries a valid provenance attestation from an approved builder, or block deployment unless a signed vulnerability-scan attestation exists. This is what lets platforms move from "trust us" to "verify it yourself," and it is why ecosystems from container registries to language package repositories have standardized on attestations for their supply chain guarantees.
How It Works
The industry standard for structuring attestations is the in-toto Attestation Framework, which defines a consistent envelope regardless of what the claim is about. At its core sits a Statement with two parts: a subject, which names the artifact and its digest, and a predicate, which holds the actual claim. A predicateType field declares what kind of claim it is, so tools know how to interpret it — a provenance predicate is read differently from an SBOM predicate.
That Statement is then wrapped in a signing envelope (commonly a DSSE envelope) and signed. In modern pipelines the signature is produced through Sigstore's keyless flow, binding the attestation to a workload identity such as a CI job rather than a long-lived key. GitHub's artifact attestations, generally available since 2024, are a widely used implementation of exactly this model. Verification then checks the signature, confirms the subject digest matches the artifact, evaluates the identity that signed it, and applies policy to the predicate contents.
Key Parts of an Attestation
| Element | Role | Example |
|---|---|---|
| Subject | Names the artifact and its digest | An image or package plus its SHA-256 hash |
| Predicate | The actual claim being made | Build provenance, an SBOM, scan results |
| predicateType | Declares how to interpret the predicate | A provenance or SBOM type identifier |
| Envelope | Wraps and carries the signed statement | A DSSE envelope |
| Signature | Proves authenticity and integrity | A Sigstore keyless signature |
Common predicate types illustrate the range of what attestations carry: build provenance (how it was made), SBOM (what is inside), VEX (which vulnerabilities apply), and test or vulnerability-scan results (what checks it passed). The framework is deliberately open-ended, so new claim types can be added without changing the envelope.
Best Practices
- Bind every attestation to a digest. A claim that is not pinned to specific content can be relocated onto a different artifact. Digest-binding is the whole point.
- Sign with pipeline identity, not shared keys. Keyless signing tied to a workload identity makes the signer auditable and removes long-lived key management.
- Record attestations in a transparency log. An append-only log makes signing events publicly auditable and detectable if something is backdated or tampered with.
- Verify predicates against policy, not just signatures. A valid signature on an unwanted claim is not enough. Enforce that the provenance names an approved builder or that a required scan attestation exists before you trust the artifact.
- Store attestations with the artifact. Keep the attestation discoverable alongside the artifact in your registry so verification is automatic at pull or deploy time.
How Safeguard Helps
Safeguard treats attestations as the connective tissue of a supply chain program. The Safeguard CLI generates and verifies in-toto attestations in your pipeline — provenance, SBOM, and scan-result claims — so producing signed, digest-bound metadata is a build step rather than a custom project. Those attestations are collected and correlated with the component inventory in SBOM Studio, giving you a single view of every signed claim attached to an artifact.
At enforcement time, Griffin AI evaluates attestations against policy and correlates them with vulnerability and reachability data, so a missing provenance attestation or an unverifiable scan result on a critical artifact becomes a prioritized finding instead of a silent gap. For related concepts, see the concepts library.
Create a free account to start generating and verifying attestations, or read the documentation for supported predicate types.
Frequently Asked Questions
What is the difference between an attestation and provenance? An attestation is the general container — a signed claim about an artifact — and provenance is one specific claim that describes how and from where the artifact was built. Provenance is carried as an attestation using a provenance predicate type. Other attestations carry SBOMs, VEX statements, or test results, so provenance is one member of a broader family.
How is an attestation different from a plain signature? A signature proves an artifact has not changed and identifies who signed it, but it carries no additional meaning. An attestation adds a structured, machine-readable claim — how it was built, what it contains, what it passed — and signs that. So an attestation includes a signature but conveys far more than authenticity alone.
What does in-toto have to do with attestations? The in-toto project defines the Attestation Framework, the standard structure of subject, predicate, and predicateType that most attestations use. Standardizing that shape is what lets different tools — from SLSA to Sigstore to registry tooling — produce and consume attestations interchangeably rather than inventing incompatible formats.
Do I need special infrastructure to verify attestations? Not much. Verification needs the artifact, the attestation, and the ability to check the signature and consult a transparency log — capabilities built into modern signing tooling and platforms like Safeguard. The heavier lift is defining the policy you want to enforce on the predicate contents, which is a security decision rather than an infrastructure one.