Practice software provenance vocabulary: SBOM, artifact traceability, unbroken provenance chains, signed provenance requirements, and linking builds to source commits.
0 / 5 completed
1 / 5
'The SBOM tracks all components.' What is an SBOM?
An SBOM (Software Bill of Materials) is a machine-readable inventory of all components in a software product: open-source libraries, their versions, licences, and known vulnerabilities. SBOMs became a US government requirement for critical software after the 2021 executive order on cybersecurity. Common formats include SPDX and CycloneDX.
2 / 5
'The artifact was produced from commit X at time Y.' Why is this provenance data important?
Provenance data linking an artifact to its exact source commit, build time, and build environment allows: audit trails (who built what and when), reproducibility verification (can we rebuild the same artifact from the same source?), and incident investigation (if a vulnerability is found, which artifacts are affected?).
3 / 5
'We can trace the build to the exact source commit.' What security property does this enable?
Traceability from artifact to source commit enables you to verify that what's running in production is exactly what was reviewed and approved in source control. This is critical for detecting build-time attacks (where malicious code is injected during the build process) and for forensic investigation after a security incident.
4 / 5
'The provenance chain is unbroken.' What does an unbroken provenance chain mean?
An unbroken provenance chain means every transformation of the artifact — from source commit to compiled binary to container image to deployment — has a linked, signed attestation. If any step is missing an attestation, the chain is broken and consumers cannot fully verify the artifact's integrity. Gaps in the chain are potential injection points for attackers.
5 / 5
'We require signed provenance for all production artifacts.' What does signed provenance prevent?
Requiring signed provenance means every production artifact must have a cryptographically signed record of its origin and build process. This prevents attackers from creating or modifying artifacts outside the approved pipeline — any artifact without a valid signature from a trusted build system is rejected before deployment.