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 is signed and published to a transparency log.

Signing

Safeguard signs with two backends:

Sigstore (default)

• Keyless signing via Sigstore Fulcio — short-lived certificates bound to workload identity (GitHub OIDC, GitLab OIDC, AWS IAM Roles Anywhere, Azure Workload Identity, GCP WIF).
• Transparency logging via Rekor — anyone can verify your artifact was signed with a known identity.
• No long-lived keys to rotate or leak.

X.509 / Notation

• For regulated environments that require traditional PKI.
• Certificates issued by your internal CA.
• Compatible with the Notation tool and OCI artifact signing.

Set your signing backend in Settings → Signing.

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

safeguard sign \
  --image registry.example.com/my-app:1.2.3 \
  --predicate slsa \
  --predicate sbom

Pushes signatures to the OCI registry alongside the image. cosign verify and docker trust inspect both work.

For Packages

safeguard sign \
  --npm ./dist/package.tgz \
  --predicate sbom \
  --predicate provenance

Publishes alongside the package; npm's provenance field will surface the Sigstore attestation automatically.

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

safeguard verify \
  --artifact registry.vendor.com/widget:4.5.6 \
  --expect-signer "sigstore:widget-inc" \
  --expect-slsa-level 3

Exits non-zero if any expectation fails.

From Your CLI

safeguard attestation list --image my-image:1.0
safeguard attestation show  --digest sha256:abc123 --predicate sbom

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.

Transparency Log Access

Every Sigstore attestation is published to Rekor — the public, append-only transparency log.

• Query by artifact digest: https://rekor.sigstore.dev/api/v1/log/entries?entryUUIDs=<uuid>
• Query by signer identity for Safeguard artifacts: https://rekor.safeguard.sh/by-identity?email=<identity>

Enterprise tenants get a private Rekor instance at rekor.<tenant>.safeguard.sh if you need the transparency semantics without using the public log.

Tamper Evidence

Every attestation carries:

• The artifact digest (SHA-256).
• The signer's certificate chain.
• A Rekor transparency log inclusion proof.
• An in-toto-formatted predicate body.

Any change to the artifact invalidates every attestation. Any attempt to sign as a different identity creates an additional Rekor entry that Safeguard flags as anomalous.

API

# Create
POST /v1/attestations
{
  "artifact_digest": "sha256:abc...",
  "predicate_type": "https://slsa.dev/provenance/v1",
  "predicate": { ... }
}

# Verify
GET /v1/attestations/verify?digest=sha256:abc...&min_slsa=3

Related

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