Why Root Artifacts Matter

Root's transparency model is built on the principle that you should be able to verify what Root does. Unlike black-box security solutions, Root provides artifacts that let you:

• Verify what was fixed - see exactly which vulnerabilities were remediated
• Understand how it was fixed - review the remediation approach
• Trust the fix - cryptographic attestations prove authenticity
• Meet compliance - artifacts support audit and compliance requirements

These artifacts enable verifiability—you don't have to trust Root blindly. You can verify that Root did what it claims to have done.

What Artifacts Root Produces

Root produces three types of security artifacts:

SBOM (Software Bill of Materials)

What it represents: A complete inventory of all components in an image or library—every package, every dependency, every version.

Why it matters:

• Transparency - you know exactly what's in your software
• Compliance - required for many security frameworks (SLSA, NIST)
• Audit trails - complete record of what was included and why
• Dependency tracking - understand your full dependency tree

In Root terms: The SBOM shows you what Root included in a secured image or library, including all patched components.

VEX (Vulnerability Exploitability eXchange)

What it represents: A statement about which vulnerabilities are present, which are fixed, and which are not exploitable in your specific context.

Why it matters:

• Reduces false positives - explains why some CVEs aren't actually exploitable
• Shows what was fixed - clear record of remediation
• Context-aware - considers your specific environment and usage
• Compliance - supports vulnerability disclosure requirements

In Root terms: The VEX explains which vulnerabilities Root fixed, which weren't exploitable, and why—reducing security noise and providing clarity.

Provenance

What it represents: A record of how an artifact was built, who built it, and what process was used.

Why it matters:

• Build transparency - you know how Root created the secured artifact
• Trust verification - cryptographic signatures prove authenticity
• Supply chain security - verifies the artifact came from Root
• Compliance - required for many security frameworks (SLSA, NIST)

In Root terms: Provenance shows you that Root's AVR Factory built the artifact, when it was built, and how—with cryptographic proof.

Patch Explorer

What it is: Patch Explorer is Root's interface for understanding what Root fixed and how.

What problem it solves: Security teams need to understand:

• What vulnerabilities were fixed in a specific image or library version
• How Root fixed them - the remediation approach
• When fixes were applied - timeline of security updates
• What changed - before/after comparison

Patch Explorer provides this visibility without requiring deep technical knowledge of patches, CVEs, or remediation techniques.

Why it matters:

• Security teams can verify Root's work and understand remediation
• Compliance teams can audit security fixes and remediation processes
• Developers can understand what changed without diving into patch details
• Operations teams can track security updates and plan deployments

Transparency and Verifiability

Root's artifact model is built on transparency and verifiability:

• You can verify what Root claims to have fixed
• You can understand how Root fixed it
• You can trust the fix because of cryptographic attestations
• You can audit the entire remediation process

This is fundamentally different from security solutions that operate as black boxes. Root provides the artifacts you need to verify, understand, and trust Root's work—without requiring expertise in file formats, standards, or patch analysis.