Attestation & Signing

A signed attestation is a cryptographically verifiable claim: "this artifact was built by this pipeline from this commit, with this SBOM, at this time." Safeguard produces attestations for every artifact your pipelines build, and verifies attestations on every artifact you consume.

What Gets Attested

Five attestation types, all in in-toto v1 format:

Every attestation Safeguard produces is signed with Safeguard's own key, held in a cloud key management service. Signatures are not written to a public transparency log. You verify them with cosign against Safeguard's published public key (see Verifying Safeguard signatures).

Signing

Safeguard signs with one backend: its own key.

Safeguard key

• Signed with Safeguard's own ECDSA P-256 key, held in a cloud key management service. The private key never leaves it.
• Verified with cosign against the published public key at https://registry.safeguard.sh/_gold/keys/cosign.pub.
• No public transparency log: there is no Rekor entry to look up, which is why the cosign commands below pass --insecure-ignore-tlog.

Producing Attestations

In CI

The standard workflow step:

- name: Attest build
  uses: safeguard/attest@v2
  with:
    artifact: ./dist/app.tar.gz
    predicates:
      - slsa-provenance
      - sbom-cyclonedx
      - vuln-scan

This step runs inside GitHub Actions, GitLab CI, Azure DevOps, Buildkite, CircleCI, Jenkins, and Safeguard's runner.

For Container Images and Packages

There is no CLI command for signing yet.

Verifying Attestations

Inline, at consumption time

The Kubernetes admission controller (see Guardrails) verifies attestations on every pod admission:

• SBOM presence.
• Signature validity.
• SLSA level meets the policy (default: Level 3).
• Signer identity matches an allow-list.

Failed verification = admission denied.

CI-time verification for vendor artifacts

There is no CLI command for verifying or listing attestations yet.

SLSA Level Support

Safeguard produces attestations at every SLSA level; which one you achieve depends on your build environment:

See the blog post on SLSA Level 3 for practical guidance on which level to target.

Verifying Safeguard signatures

Safeguard signs with a key rather than through a public transparency log, so verification uses the published public key:

KEY=https://registry.safeguard.sh/_gold/keys/cosign.pub

# Container images: signature and SLSA provenance
cosign verify --key "$KEY" --insecure-ignore-tlog registry.safeguard.sh/library/python@sha256:<digest>
cosign verify-attestation --key "$KEY" --insecure-ignore-tlog --type slsaprovenance registry.safeguard.sh/library/python@sha256:<digest>

# Files: a detached signature next to the file
cosign verify-blob --key "$KEY" --insecure-ignore-tlog --signature <file>.sig <file>

The trade-off: a public transparency log gives an independent public record of every signature. With key-based signing, you rely on Safeguard to protect the key, which is held in a cloud key management service.

Tamper Evidence

Every attestation carries:

• The artifact digest (SHA-256).
• A signature made with Safeguard's key, verifiable with the published public key.
• An in-toto-formatted predicate body.

Any change to the artifact invalidates every attestation.

API

There is no public attestation API yet. Attestation records for your projects, products and components are shown on their Attestation tab in the Safeguard app. See API Reference for what the public API supports today.

Related

• Guardrails & Enforcement — policies that require signed attestations.
• ESSCM Attestation — the UI for browsing attestations.
• CI/CD Integration — adding the attest step to pipelines.