124% more reported CVEs per day in 2026 than last year.

SBOM export and CRA evidence from every build

SBOMs recorded during the build, the build record through the API, and vulnerability records through to the fixed release: the evidence your technical documentation draws on

Build-time SBOMs in CycloneDX or SPDX

CRACI records the SBOM while each build runs on its runner, so it lists the packages the job actually pulled in, including packages restored from CI caches. Every SBOM exports as CycloneDX or SPDX, with transitive dependencies, the vulnerabilities found in their components and each component's declared license. Each job's SBOM also carries a completeness state.

An SBOM recorded during the build Packages from npm, PyPI, Cargo, Go, OCI registries and the CI cache pass through a package-aware proxy on the CRACI runner. The job's SBOM lists what was fetched, states its completeness and exports as CycloneDX or SPDX. Package sources npm PyPI Cargo · Go OCI registries CI cache restore Package- aware proxy on the runner Job SBOM express 5.2.1 requests 2.32.3 serde 1.0.219 + transitive deps Declared license on every component Complete Completeness states per job and cache: Complete, Complete with connections, Incomplete, Unavailable, Not recorded CycloneDX · SPDX

SBOMs, network traces and provenance through the API

The public REST API returns a job's SBOM, its network trace and provenance data, so the build record can flow into your own documentation and tools. The SBOM API returns CycloneDX 1.7 JSON.

Provenance data from every build Every job on CRACI records the packages it fetched and its network trace. The public REST API returns the job's SBOMs, network trace and provenance. Build release job on CRACI Recorded packages fetched network trace Provenance build data, via the API Ask the API about any job Job → SBOM, trace, provenance Returned by the API Job Packages CycloneDX SBOM Network trace Recorded on every CRACI job, no extra step

Vulnerability records from triage to a fixed release

Monitored SBOMs are re-evaluated as new vulnerabilities are published. Security teams triage each finding and send it to the team that owns the fix, and CRACI keeps the record through to the fixed release. Build history shows every past build and its SBOM, and which builds contained the vulnerable dependency, direct or transitive, so you know the period you were exposed.

Vulnerability tracking after release After a release ships, its SBOM stays monitored. When a new vulnerability is published, CRACI re-evaluates the monitored SBOMs, finds the affected releases, and the security team triages the finding and routes it to the team that owns the fix. The inventory view shows which software versions are deployed to which products. Release shipped SBOM monitored Later New advisory published Re-evaluated automatically Finding: critical, in 2 releases 1. Triage 2. Route to owner 3. Team fixes Policy gates can block a build on findings · VEX supported Inventory: deployed versions Product Version Web app v4.12.0 Mobile API v2.3.1

Policy gates that keep a known issue out

Policy gates can stop a build in real time on findings, including builds that contain a specific CVE, and on licenses. Every build also runs under an egress policy that is enforced at the runner, validated before the job starts and fails closed, with alerts on policy violations.

Policy gates in CI Every build on CRACI records its SBOM, runs under an egress policy and records provenance data. Policy gates can block the build on findings or on a license, so issues are caught in CI before release. Pull request New dependencies, added by a developer or an AI agent Every change reaches the build the same way CRACI build SBOM recorded Egress enforced Provenance Every build, no extra step Policy gate Findings or licenses outside your policy Build blocked Or passes to release

Evidence for your CRA technical documentation

Under the Cyber Resilience Act, the manufacturer prepares the technical documentation, runs the conformity assessment and draws up the EU declaration of conformity. CRACI does not do those steps. It supplies the evidence that comes out of the build: SBOMs, vulnerability and remediation records, and provenance data. CRACI also submits the CRA vulnerability notifications on your behalf: the early warning, the notification and the final report.

CRA obligations and the evidence for them The CRA obligations that touch the software supply chain, such as the SBOM, vulnerability handling, reporting, due diligence and technical documentation, are where CRACI provides evidence. The risk assessment and the conformity assessment stay with the manufacturer. Obligation CRACI evidence Software bill of materials Yes Vulnerability handling Yes Reporting exploited vulnerabilities Submitted for you Due diligence on components Yes Technical documentation Evidence and exports Risk assessment, secure design Yours Conformity assessment, CE Yours CRACI automates a significant part of the supply chain visibility and evidence your CRA process needs

See the evidence your builds produce

Book a demo to see SBOM export, the API and vulnerability tracking in CRACI

Book a demo