Provenance
Information about how, where and from what an artifact was produced, such as a SLSA provenance attestation. Its value depends on who produced it, how it is verified and whether it is bound to the exact artifact.
- Also called
- build provenance · SLSA provenance · provenance attestation · package provenance
- Defined in
- SLSA 1.2: Provenance
Covered in
Read SLSA provenance and verify the claim you need
Connect an artifact to its build evidence while distinguishing provenance, build assurance and source controls.
Review dependency health without treating a score as a guarantee
Combine security practices, maintenance, licensing and product exposure into a recorded adoption or replacement decision.
Compliance evidence reuse: one evidence set for SSDF, PCI DSS, ISO 27001, SOC 2 and the CRA
Keep one set of release-bound engineering evidence (SBOM, provenance, review records, scan results, ASVS results and vulnerability handling) and map it to several frameworks: a worked crosswalk, an evidence index checked in CI with a CSV export, and an OSCAL component definition.
Harden container images from Dockerfile to admission
Build minimal, non-root images pinned by digest, keep secrets out of every layer, then scan, sign and verify the exact digest before it runs with dropped privileges.
Protect the path from pull request to release
Separate untrusted contribution checks from privileged release work and verify the identity of the artifact that is actually deployed.
Treat model releases as executable supply-chain inputs
Verify provenance, constrain loading and preserve the relationship between model weights, configuration and runtime dependencies.
All 15 pages that cover Provenance in the library
Practice: Local project: Build and verify a signed software release · Local project: Repair a security pipeline for GitHub Actions and GitLab CI · Local project: Gate an image build on a CIS scan and a deviation register