Attestation

An attestation is digitally signed using a private key or ephemeral workload identity, creating a non-repudiable link between the signer and the asserted facts.

• The signature is verified against a trusted public key or certificate chain
• Any tampering with the attestation payload immediately invalidates the signature
• Supports both long-lived keys and keyless signing via OIDC-bound ephemeral certificates

This binding ensures that the asserted claim—such as a vulnerability scan result or build provenance—can be cryptographically traced to a specific identity or system.

Once an attestation is generated and recorded in a transparency log or append-only registry, it cannot be retroactively altered or deleted without detection.

• Transparency logs like Rekor provide a publicly auditable, tamper-evident ledger
• Each entry is cryptographically chained to previous entries, preventing backdated insertion
• Supports WORM (Write-Once-Read-Many) storage models for long-term compliance

This immutability guarantees that auditors can replay the exact sequence of attestations to reconstruct the full history of an artifact's lifecycle.

Attestations use structured predicates to assert specific, verifiable facts about a subject (the artifact). Common predicate types include:

• SLSA Provenance: Describes the build environment, source repository, and build steps
• Vulnerability Scan Result: Reports the outcome of a container image security scan
• Test Result: Asserts that a specific test suite passed against the artifact
• SBOM Reference: Links the artifact to its Software Bill of Materials

Each predicate follows a standardized schema, enabling automated policy engines like OPA to evaluate attestations programmatically.

Every attestation explicitly identifies its subject—the specific artifact being attested to—using a content-addressable digest rather than a mutable tag.

• Subjects are referenced by their SHA256 hash (e.g., sha256:abc123...)
• This prevents tag mutation attacks where an attacker overwrites a tag to point to a malicious artifact
• Multiple attestations can be bound to the same subject, creating a rich, layered trust profile

By anchoring attestations to immutable digests, the system ensures that the assertion always refers to the exact artifact it was generated for.

Attestations are designed for machine consumption, enabling fully automated verification within CI/CD pipelines and admission controllers.

• Binary Authorization systems reject artifacts that lack required attestations
• Admission Controllers in Kubernetes can block deployment if provenance attestations are missing or invalid
• Policy engines evaluate attestation predicates against Rego policies to enforce organizational rules

This automation eliminates manual approval gates while maintaining strict security postures, ensuring only attested artifacts reach production.

Attestations recorded in public transparency logs provide universal auditability, allowing any party to independently verify the signing event.

• Rekor logs include the signed artifact hash, signature, and timestamp
• Auditors can query the log to confirm that a specific attestation was recorded at a specific time
• Monitors can watch logs for unexpected signing events, triggering alerts on anomalies

This property is critical for non-repudiation: a signer cannot later deny having signed an artifact, as the log entry provides undeniable proof of the event.