What Is a Release Governance Platform for the Agentic Era?

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 simply wrap SCA scans in one of the major SBOM formats (CycloneDX or SPDX). This approach fails to capture the true state of the released product. Such scans are also frequently done outside of the release management process, making it impossible to answer a basic question: what does this SBOM actually represent?

Evidence Is Not Enough

Even when evidence is collected correctly at the release level, storing it passively is not sufficient. In the Agentic Era, where AI can produce an order-of-magnitude more code than human developers ever could, the volume and velocity of releases is accelerating dramatically. Code production is no longer the bottleneck - release control is.

Organizations need more than an archive. They need an active control plane that can:

  • Enforce policies before a release is promoted or shipped
  • Require approvals from the right stakeholders at each lifecycle stage
  • Block releases that violate security, licensing, or compliance rules
  • Track who approved what, when, and under what conditions
  • Answer auditor and incident-response questions instantly, across all past releases

This is the distinction between a passive evidence store and a Release Governance Platform.

Related Operational Problems

In practical scenarios, there are several "simple" questions that are very difficult to answer with legacy tooling:

  • What is the exact security posture of version 1.0.3 of product X today?
  • What was the security posture of that same version 3 months ago when it was shipped to a key customer?
  • Has any Shai-Hulud 2.0 infected dependency ever entered the organization's supply chain, and if so, in which releases?
  • Has the log4shell CVE ever appeared anywhere across the organization?
  • Which releases were approved for production, by whom, and when?
  • Was a policy violation overridden before this release shipped - and who authorized it?

Why the Release Is the Right Unit of Governance

The release is the fundamental unit of software delivery. It is what gets deployed to production, what customers install, and what regulators ask about during audits. Governance must be organized around releases - not repositories, branches, or individual commits.

Modern regulations such as CRA require organizations to maintain evidence and control records at the release level. Many contract requirements demand the same.

The supply chain also forms a Directed Acyclic Graph: releases include other releases as components. This is why ReARM distinguishes between Product Releases (what is shipped to customers) and Component Releases (the building blocks of those products). Evidence, policy checks, and approvals propagate through this hierarchy, giving a complete picture of security posture at every level.

These relationships form the basis of the Product-Component release metadata organization model, described in detail by the creators of ReARM here.

What a Release Governance Platform Is

A Release Governance Platform is an active control plane that organizes all supply chain artifacts, security evidence, policies, and approvals around the release as the primary entity. It is not a passive archive - it is the system that decides whether a release is allowed to move forward.

It provides:

  • Policy enforcement: Automated checks that block or flag releases violating security, licensing, or organizational rules - enforced at each lifecycle stage.
  • Approval workflows: Configurable gates requiring sign-off from the right stakeholders before a release can be promoted or shipped.
  • Unified evidence repository: SBOMs, HBOMs, xBOMs, VEX, VDR, SARIF, attestations, build metadata, and other artifacts - all stored per release, not per repository.
  • Release hierarchy: Product releases composed of component releases, with evidence, policies, and approvals aggregated and applied through the hierarchy.
  • Security posture tracking: Unified view of vulnerabilities and policy violations across releases, with deduplication and scoped auditing.
  • Automated versioning: Intelligent version bumping and changelog generation for every release based on code, dependency, and security changes.
  • Long-term retention: Immutable storage of all raw evidence for 10+ years to meet regulatory requirements, alongside enriched or augmented evidence artifacts.
  • API-first integration: Standards-based APIs (including OWASP Transparency Exchange API) to integrate with existing CI/CD and security tools.

How ReARM Implements Release Governance

ReARM was built from the ground up as a Release Governance Platform for the Agentic Era. Here is how it works:

1. Release-First Data Model

Every artifact, SBOM, security finding, approval record, 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. Policy Enforcement and Approval Gates

ReARM enforces configurable policies at each release lifecycle stage. Releases that violate security policies, contain unlicensed dependencies, or fail compliance checks can be automatically blocked or flagged. Approval workflows ensure the right stakeholders authorize each promotion, with a full audit trail of who approved what and when.

3. 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, stored with the release, and attributed to its proper release element.

4. Unified Security Posture

ReARM aggregates findings from Dependency-Track, CodeQL, and other security tools into a single view per release, tracking how findings change over time with rich changelogs and scoped auditing at organization, product, component, or release level. Findings include vulnerabilities, weaknesses (SAST/DAST), licensing violations, and other policy violations.

5. Intelligent Versioning and Changelogs

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

6. Standards-Based Integration

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

The Path Forward

As AI accelerates code production and software supply chain regulations continue to mature, the industry is moving beyond simple SBOM generation - and beyond passive evidence storage - toward active release governance. Organizations need platforms that can enforce policies, require approvals, answer auditor questions, support incident response, and provide long-term traceability, all organized around the release as the fundamental unit of delivery.

A Release Governance Platform for the Agentic Era is the control plane that creates shared environment for multiple stakeholders, ensuring that every release is authorized, evidenced, and traceable.

Ready to See ReARM in Action?

Experience how release governance transforms supply chain security, approvals, and compliance.