What Is a Release-Level Supply Chain Evidence Platform?

The Problem: What does SBOM actually represent?

Organizations today face a critical challenge in managing software supply chain security. While SBOMs (Software Bill of Materials) have become a regulatory requirement under frameworks like the EU Cyber Resilience Act (CRA), NIS2, and US Executive Order 14028, most teams struggle to see the benefits in practice.

That is because SBOMs are often generated at the source code repository level during regular SCA scans.

In other words, to tick some checkboxes on compliance forms, many tools would simply wrap SCA scans in one of the major SBOM formats (CycloneDX of SPDX). This approach fails to capture the true state of the released product. It is also easy to notice that frequently such SCA scans are done outside of the release management process. Thererefore, it is impossible to answer a simple question, what does such SBOM actually represent?

Why Release-Level Evidence Matters

The release is the fundamental unit of software delivery. It's what you deploy to production, what customers install, and what regulators ask about during audits. Release-level evidence management aligns with how organizations actually operate.

Further, modern regulations such as CRA require organizations to maintain evidence at the release level. Similarly, many contract requirements also demand release-level evidence.

It is also important to note that supply chain represents a Directed Acyclic Graph with releases including other releases as components. This is why we establish notion of Product Releases and Component Releases, where Product Releases are understood as what is shipped to the customer, while Component Releases are elements of such Product Releases.

Next, while the evidence is frequently collected at component release level, it is important to be able to aggregate this evidence at the product release level. Thus, we usually understand per-release security posture as a combination of security posture of all components and their dependencies. And we need to be able to reason about security posture on each level.

This various relationships have become a basis of the Product-Component release metadata organization model, described with additional details by creators of ReARM here.

What a Supply Chain Evidence Platform Is

A Release-Level Supply Chain Evidence Platform is a system of record that organizes all supply chain artifacts and security evidence around the release as the primary entity. It also recognizes specific elements within releases, such as Source Code Entries and Deliverables (or Distributions).

It provides:

Unified evidence repository: SBOMs, HBOMs, xBOMs, VEX, VDR, SARIF, attestations, and build metadata. All stored per release.
Release hierarchy: Products composed of components, with evidence automatically aggregated and propagated through the hierarchy.
Automated versioning: Intelligent version bumping and changelog generation for every release based on code, dependency, and security changes.
Security posture tracking: Unified view of vulnerabilities and policy violations across releases, with deduplication and scoped auditing.
Long-term retention: Immutable storage of all raw evidence for 10+ years to meet regulatory requirements. And separate storage of augmented or enriched evidence artifacts.
API-first integration: Standards-based APIs (like OWASP Transparency Exchange API) to integrate with existing CI/CD and security tools.

How ReARM Implements Release-Level Evidence Management

ReARM was built from the ground up as a release-level supply chain evidence platform. Here's how it works:

1. Release-First Data Model

Every artifact, SBOM, security finding, and piece of evidence is associated with a specific release. Products are composed of component releases, creating a complete hierarchy that mirrors your actual software architecture.

2. Automated Evidence Collection

ReARM integrates with your CI/CD pipeline to automatically collect and version all evidence as part of your build process. SBOMs, security scan results, signatures, attestations. Everything is captured and stored with the release and attributed to its proper release element.

3. Unified Security Posture

ReARM aggregates findings from Dependency-Track, CodeQL, and other security tools into a single view per release. ReARM then allows to track how findings change over time with rich changelogs and scoped auditing at organization, product, component, or release level. ReARM findings include vulnerabilities, Weaknesses (SAST/DAST and other scanning results), Licensing Violations and other policy violations.

4. Intelligent Versioning and Changelogs

ReARM automatically generates comprehensive changelogs for every release, covering source code changes, SBOM component changes, and security finding changes. ReARM is also capable to act as a versioning authority, automatically generating version numbers based on chosen versioning schema (such as SemVer 2.0.0).

5. Standards-Based Integration

ReARM implements the OWASP Transparency Exchange API, ensuring interoperability with the broader supply chain security ecosystem.

The Path Forward

As software supply chain regulations continue to evolve and mature, the industry is moving beyond simple SBOM generation toward comprehensive evidence management. Organizations need platforms that can answer auditor questions, support incident response, and provide long-term traceability - all organized around the release as the fundamental unit of delivery.

A Release-Level Supply Chain Evidence Platform isn't just a better SBOM tool, it's a new category of infrastructure that aligns with how modern software is actually built, delivered, and deployed.

Ready to See ReARM in Action?

Experience how release-level evidence management transforms supply chain security and compliance.