Software supply-chain integrity
Move from detection (scanning what you already shipped) to attestation: produce verifiable evidence of what an artifact contains and how it was built, then refuse to deploy anything that fails verification. OWASP elevated this risk to A03 — Software Supply Chain Failures — in its 2025 Top 10, expanding the older "Vulnerable and Outdated Components" category to cover dependencies, build systems, and distribution.
Two artifacts per build
Every release build MUST produce, alongside the binary/package:
- An SBOM (Software Bill of Materials) listing every component and version. Use CycloneDX or SPDX — both are widely tooled; pick one and stay consistent.
- Signed build provenance describing what built the artifact, how, and from which inputs (source commit, builder identity, parameters).
Build: emit SBOM + provenance
- The CI pipeline SHOULD generate the SBOM from the resolved dependency graph (lockfile), not from declared ranges, so it reflects what actually shipped.
- Provenance SHOULD be generated by the hosted CI platform itself, not by a step the build author fully controls — this is what raises trust from "self-asserted" to "platform-attested."
- Sign artifacts and attestations. Keyless signing tied to CI workload identity (e.g. Sigstore/cosign with OIDC) avoids long-lived private keys; managed KMS keys are an acceptable alternative.
- Pin the toolchain and base images by digest so the build is reproducible enough to attest.
SLSA Build levels (v1.0, Build track L0–L3)
The SLSA v1.0 spec defines a single Build track with levels 0–3. Target L2 as a realistic baseline; reach for L3 where the threat model justifies it.
| Level | What it adds |
|---|---|
| L1 | Provenance exists and shows how the package was built |
| L2 | Build runs on a hosted platform; provenance is signed |
| L3 | Build platform enforces isolation; provenance is non-forgeable |
Deploy: verify before promotion
Detection alone is insufficient — the gate is verification.
- The deploy step MUST verify the artifact signature against the expected signer identity (CI workload, repo, ref).
- The deploy step SHOULD verify provenance: the artifact was built from the expected source repo and commit, on the expected builder, with expected parameters. A signature without provenance only proves who signed, not how it was built.
- A failed signature or provenance check MUST block promotion (fail-fast) — never warn-and-continue.
- Store SBOMs and attestations as immutable release evidence for incident response and audits.
Combine with pinning and lockfiles
Attestation complements — does not replace — the controls in the dependency-security guideline (agenticdevelopercookbook://guidelines/shipping/dependency-security):
- Commit lockfiles; install with the frozen/locked flag in CI so resolution is deterministic.
- Pin dependencies (and CI actions) by version, ideally by digest/hash, not floating tags.
- Keep scanning for known-vulnerable components — it answers a different question (is this version exploitable?) than provenance (did this come from where I think?).
Regulatory drivers (dated — treat timelines as forecasts)
These are drivers, not engineering requirements; confirm current applicability for your jurisdiction and sector.
- EU Cyber Resilience Act (CRA) — entered into force 2024; main obligations for products with digital elements apply from December 2027, with SBOM and vulnerability-handling expectations.
- US federal procurement — agencies increasingly require SBOMs for purchased software, building on EO 14028 (2021) and subsequent CISA guidance.
MUST NOT
- Do not ship a release build with no SBOM and no provenance.
- Do not treat an unsigned or unverifiable attestation as passing.
- Do not generate provenance from a fully build-author-controlled step and claim hosted-build (L2) trust.