Skip to main content
Every artifact Root delivers includes a provenance attestation — a cryptographic record that proves the artifact was built by Root’s AVR pipeline, documents exactly how it was built, and includes the test results that validated the fix. Provenance is what makes Root’s claims verifiable, not just trustworthy. You don’t have to take Root’s word that a CVE was fixed — provenance gives you the proof to check.

​
What Provenance Records

A Root provenance attestation includes:
  • Builder identity — proof that Root’s AVR Factory produced the artifact (cryptographically signed)
  • Build timestamp — when the artifact was built and when the patch was applied
  • Build inputs — the exact source materials used: which patch was applied, from which upstream source
  • Test results — the outcomes of package tests, functional tests, and CVE regression tests run against the patch
  • Configuration — the parameters used to produce the artifact, ensuring reproducibility

​
Why Provenance Matters

For supply chain security: Provenance verifies that an artifact wasn’t tampered with between Root’s build pipeline and your registry pull. The cryptographic signature is unforgeable. For compliance: Provenance supports SLSA (Supply chain Levels for Software Artifacts) requirements and satisfies audit needs for software build verification. For trust: Provenance answers the question “how do I know Root actually fixed this?” with evidence, not assertion.

​
Patch Explorer

Root’s Patch Explorer is the platform interface for reviewing provenance without needing to parse raw attestation formats. It provides a human-readable view of:
  • Which vulnerabilities were fixed in a specific image or package version
  • How Root fixed them — the remediation approach and patch type
  • When fixes were applied — the full timeline of security updates
  • Before/after comparison — what changed and what was preserved
Patch Explorer is accessible from the Root platform UI in three places: the image report for a specific image, the library report for a specific package, and the Vulnerabilities page for any remediated CVE.

​
Accessing Provenance Attestations

For container images (RIC): SLSA compliant Provenance files are available via API or in the UI using the unique image id (rrtID): Via the Root platform UI: Navigate to any subscribed image and download the Provenance directly. Via the Root API: See API Reference for the /images/tags/{rrtID}/provenance endpoint.

​
SLSA Compliance

Root’s build pipeline is designed to meet SLSA (Supply chain Levels for Software Artifacts) requirements. Provenance attestations are generated in SLSA format and are verifiable using standard tooling. [SLSA level certification and verification instructions coming soon]