Gnu Group Learning AcademyGnu Group ↗
DevSecOps Fundamentals · Module 07 of 12

Artifact signing, attestations and provenance

Protect artifact integrity with signatures and provenance so consumers can verify what was built, by whom, and from which source/build process.

Learning objectives

By the end of this module, you should be able to:

  • Distinguish signatures, attestations and provenance.
  • Explain identity-based/keyless signing at a conceptual level.
  • Verify artifact digest and signer identity rather than trusting a tag.

Sign immutable identity

Container signatures bind claims to image digests. Verification should evaluate the digest plus expected signer/issuer identity.

Attestations carry statements

An attestation can describe build provenance, SBOM or other predicates. Verification proves integrity/authenticity of the statement, not that every claim is desirable.

Provenance answers origin

SLSA provenance describes where, when and how an artifact was produced and connects outputs back to build/source context.

Worked example

Verification decision

digest verified + expected signer identity + trusted issuer + policy predicate → allow
tag-only reference or unknown signer → reject/review
  • Connect each finding to a concrete risk and control.
  • Preserve evidence so a reviewer can reproduce the decision.
Core lab · account-free

Lab 07 — Verify a signed-metadata model

Goal: Validate identity and digest claims in a synthetic attestation.

Before you start

  • No cloud account required.
  • Core lab uses bash/Python 3 and local files only.
STEP 1

Create claims

cat > /tmp/provenance-demo.json <<'EOF'
{"subject":"sha256:abc123","issuer":"https://token.actions.githubusercontent.com","identity":"repo:gnu/demo:ref:refs/heads/main","builder":"github-actions"}
EOF
STEP 2

Apply trust policy

python3 - <<'PY'
import json
x=json.load(open('/tmp/provenance-demo.json'))
assert x['subject'].startswith('sha256:')
assert x['issuer']=='https://token.actions.githubusercontent.com'
assert x['identity'].startswith('repo:gnu/demo:')
print('claims satisfy demo policy')
PY
STEP 3

Explain limitation

State why valid signature/provenance does not prove the artifact has no vulnerabilities.

Verify

  • Digest and identity are checked.
  • The learner distinguishes integrity/origin from vulnerability status.

Expected outcome

  • A small identity-based verification policy exists.

Diagnose / troubleshoot

  • If verification checks any signer, tighten expected identity and issuer.
  • If only a tag is available, resolve and record the immutable digest before approval.
Real-world connection

Supply-chain controls are useful when deployment verifies evidence rather than assuming the build system was trustworthy.

Optional real-tool lab

Optional tool lab — Cosign

Inspect Cosign signing/verification commands without using production artifacts.

Prerequisites

  • Install the referenced open-source CLI only for the optional lab.
  • Use an organization-approved pinned version in real CI; do not blindly use latest.

Cost / risk

  • Expected cloud cost: none. Use only approved repositories and disposable training artifacts.

Warnings

  • Never scan or publish real production secrets in a training lab.
  • Scanner output is evidence for triage, not an automatic statement of exploitable risk.
TOOL 1
cosign version
TOOL 2
printf '%s\n' 'demo artifact' > /tmp/devsecops-artifact.txt
TOOL 3
cosign sign-blob --help | head -30
TOOL 4
cosign verify-blob --help | head -30
Avoid these traps

Common mistakes

  • Signing a mutable tag but never verifying the digest.
  • Verifying cryptography but not expected signer identity.
  • Calling provenance a vulnerability guarantee.
Knowledge check

Can you connect the finding to the control?

Three concept checks plus one scenario check.

1What does a signature primarily protect?

Artifact integrity/authenticity relative to a trusted signing identity or key.

2What is provenance for?

Verifiable information about where, when and how an artifact was produced.

3Why verify signer identity?

A valid signature from an unexpected identity should not automatically authorize deployment.

4Scenario: cosign verification succeeds for an unknown identity. Should production deploy?

Not until policy confirms the signer/issuer is authorized for that artifact.

My Learning

Record your progress for this module.

Progress is saved in this browser immediately. When you sign in to My Learning, it can also sync across devices.

Not started

Attempt the core lab and knowledge checks before marking the module complete.