CRACI vs Cybeats SBOM Studio

The short answer

Cybeats SBOM Studio calls itself "the SBOM system of record." It stores SBOMs from your products and suppliers, enriches them with vulnerability and license intelligence, monitors them continuously and shares them with customers and regulators. CRACI is a GitHub Actions runner that records the dependencies each job actually fetched and produces the SBOM from that record, with a completeness state and signed provenance.

A system of record is only as accurate as what goes into it. SBOM Studio manages SBOMs that some other tool generated. CRACI produces them from the build and monitors them, so the CI, the SBOM and the vulnerability tracking come from one product.

At a glance

What Cybeats does well

• One governed place for every SBOM. SBOM Studio is built for product security teams in ICS and OT, medical devices, telecom, automotive and financial services. It gives them "one governed source of truth for every SBOM across your products and suppliers."
• Wide format support. SPDX 2.2 through 3.0.1 and CycloneDX 1.2 through 1.7, for import and export. The platform also handles VEX, AIBOM, CBOM and HBOM.
• Quality control at the door. The SBOM Quality Score validates files before import, checks that they are correctly formatted against the standard, and logs why an SBOM falls short.
• Enrichment and monitoring. Every component is matched continuously against vulnerability intelligence, with policy-based alerts, VEX to communicate which vulnerabilities affect your products, and OSS and COTS license analysis.
• Sharing. Controlled SBOM and VEX exchange with customers, including over the Transparency Exchange API. SBOM Consumer, a separate product, validates and monitors the vendor SBOMs you receive.

VEX, supplier SBOM intake, license analysis and hosted sharing are all areas where SBOM Studio does more than CRACI today. If your team's job is running an SBOM program across many products and suppliers, it is built for that.

Where CRACI is different

It produces the SBOM, from the build

SBOM Studio ingests SBOMs. For generation, Cybeats points to its Marketplace, which brings together vendors of binary composition analysis and SBOM generation tools. So the component list in the system of record still comes from a scanner of some kind.

CRACI runs the job. You change runs-on to craci, and a package-aware proxy records traffic to package sources during the build: npm, PyPI, RubyGems, Cargo, Go, Nix and OCI, plus OS packages and source or download presets. Dependency evidence travels with CI caches, so a package restored from a cache is still in the record. The SBOM includes all transitive dependencies the build actually used.

Well formed is not the same as complete

A quality score can confirm that an SBOM follows the standard and carries the expected fields. It cannot tell you what the generator never saw. Generators disagree structurally, because each reads a different set of files and resolves them differently, and a well formed document says nothing about whether the dependency it omits was ever in front of the tool. The NTIA supplier field is a good example: it validates as present or absent, and most generators have no source for it. CRACI cannot be scored this way, because it records builds and cannot scan a directory.

CRACI states completeness from the recording itself, per job and per cache: Complete, Complete with connections, Incomplete, Unavailable or Not recorded. The gaps in the record are known rather than guessed.

Control and provenance

Because CRACI runs the job, it enforces a network egress policy: default deny or default allow, with 24 built-in software-source presets and typed custom sources, validated before the job starts and failing closed. Signed provenance (Ed25519 over SHA-512) links each artifact, including OCI artifacts, to the build that produced it.

Monitoring

CRACI re-evaluates monitored SBOMs continuously and aggregates vulnerabilities across builds and repositories.

Replacing SBOM Studio with CRACI

For software teams on GitHub Actions, CRACI covers what an SBOM system of record is there to do for their own products: it produces the SBOM in each build, keeps re-evaluating monitored SBOMs as new vulnerabilities are published, aggregates findings across builds and repositories, and lets security teams triage them and route each one to the team that owns the fix. You can add vendor SBOMs too, so bought-in components are monitored alongside your own builds. There is no separate generator to run and no import step to maintain.

Be clear about what you give up. SBOM Studio handles VEX, license analysis, AIBOM, CBOM and HBOM, scores SBOM quality at import, and shares SBOMs with customers over the Transparency Exchange API. CRACI has none of those today. If your job is running an SBOM program across many products, suppliers and customers, SBOM Studio is built for that.

For the Cyber Resilience Act

Cybeats addresses the CRA directly. It calls the regulation "the main driver of SBOM adoption today" and says SBOM Studio "produces compliant, up to date SBOMs" to help manufacturers maintain software transparency through the product lifecycle. Its regulations guide sets out the 24-hour, 72-hour and 14-day reporting timeline.

The CRA's reporting obligations apply from September 11, 2026, through the CRA Single Reporting Platform, and its main provisions apply from December 11, 2027. A 24-hour early warning depends on knowing quickly which releases contain an affected component, and on trusting the inventory that tells you. CRACI's API takes you from an artifact to its producing build, its CycloneDX SBOM and the job network trace, and reports export in PDF, HTML, CSV, Excel and JSON.

CRACI automates a significant part of the software supply chain visibility and evidence that companies need for their wider CRA compliance process. Neither product makes a manufacturer compliant on its own. See what the CRA requires, CRA compliance with CRACI and industrial IoT.