Provenance & SBOM
Prove where artifacts came from (SLSA, OS hash-chains) and produce the bills of materials auditors and IR teams ask for (CycloneDX, CSV, BOM inspector).
How to Verify Package Provenance with SLSA Attestations
Understand provenance statuses, create policies that require verified provenance, and interpret provenance data in the BOM.
How to Detect Mirror Tampering with APT, Yum, and DNF Hash-Chain Provenance
Enable end-to-end clearsigned InRelease + repomd.xml.asc verification for OS package mirrors by configuring the trust-root keyring.
How to Export Your Software Bill of Materials (SBOM) in CycloneDX Format
Generate a CycloneDX 1.6 SBOM from the BOM page, filter by client/ecosystem/package, and integrate SBOM exports into your compliance workflow.
How to Export and Analyze Your BOM as CSV
Export the full bill of materials with supply chain columns, filter before export, and use the CSV for compliance reporting.
How to Investigate a Violation in the BOM Inspector
When a violation fires, the per-package timeline tells you what to do about it. Walk through the BOM inspector — findings list, signal evidence, dependency paths, and one-click drill from violation to owner.
A risky package is one problem; not knowing where it came from is another. Provenance tells you whether you can trust an artifact’s origin; the SBOM tells you what you actually have. This section covers verifying build provenance (SLSA) and OS-package hash-chains, exporting standards-compliant bills of materials (CycloneDX and CSV), and investigating a specific artifact’s history with the BOM inspector.
Provenance is a policy input, not just a report. A failed SLSA or
hash-chain check refuses the install — wire it up in
Policy & Enforcement.
Where to next
To answer “are we affected by CVE-X?” across inventory, see Remediation & Patching.