CRACI vs FOSSA

The short answer

FOSSA is strongest at open-source license compliance and SBOM lifecycle management: generating application SBOMs, importing third-party SBOMs, monitoring them for vulnerabilities and sharing them with customers and authorities. 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.

FOSSA manages the SBOMs you give it. CRACI produces one from the build and keeps monitoring it, so for your own software the CI, the SBOM and the vulnerability tracking sit in one place. Where license compliance is the main concern, FOSSA is still ahead.

At a glance

What FOSSA does well

• License compliance. This is where FOSSA started, and it shows. It detects licenses from full text, applies policies automatically, extracts copyright information and generates attribution notices in SPDX, HTML and text. Legal and engineering teams can work from the same data.
• SBOM lifecycle. FOSSA "produces and consumes SBOMs." It generates SBOMs in SPDX and CycloneDX, optionally with VDR or VEX statements, and imports existing SBOMs to "analyze dependencies you don't build yourself." SBOM policies can require NTIA and FDA minimum elements on imported files.
• Distribution. On Enterprise, the SBOM Portal shares SBOM data with partners or publicly, so you are not emailing files to customers.
• Broad scanning. The FOSSA CLI integrates with more than 20 build systems, and container scanning is included. Snippet scanning and binary scanning are available as add-ons.
• A free way in. The Free plan covers 5 projects and 5 imported SBOMs. Business costs $20 per project per month, billed annually, and Enterprise is custom (as of September 2026).

If your main problem is license risk, or managing SBOMs that arrive from many suppliers, FOSSA covers ground CRACI does not. CRACI shows declared license metadata and includes it in SBOM export, but license policy is on the roadmap.

Where CRACI is different

The SBOM comes from what the build did

The FOSSA CLI analyzes a project by integrating with its build tool when a working build is available, and by inferring dependencies from source when it is not. That is a sound approach, and it is still analysis of the project. CRACI runs the job instead. 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, including all transitive dependencies the build used.

The method matters because SBOM generators disagree, and they disagree by design. Each decides for itself what counts as a component and which files to trust, so pointing two of them at one repository gives two overlapping but different lists. Neither FOSSA nor CRACI can be compared on those terms, since CRACI records builds and cannot scan a directory. The point is about static analysis in general: the answer depends on the tool, its settings and the files present.

It tells you when it is incomplete

FOSSA's SBOM policies check that required fields are present. CRACI adds a different signal: a completeness state per job and per cache (Complete, Complete with connections, Incomplete, Unavailable or Not recorded) that says whether the recording itself had a gap. When an auditor asks how you know an inventory is complete, that is the answer.

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. FOSSA's fossabot works on a different problem: it reviews dependency updates, including those from Dependabot or Renovate, for breaking changes and impact.

Replacing FOSSA with CRACI

For the software you build yourself, CRACI covers what FOSSA's SBOM and vulnerability features do, from the source. It runs your GitHub Actions jobs, records the SBOM of 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. Vendor SBOMs can be added too, so bought-in components are monitored alongside your own builds. There is no separate CLI step to maintain.

Be clear about what you give up. FOSSA's license compliance is mature: policies, full-text license detection, copyright extraction and attribution notices. CRACI exports the declared license of every component, but license policy is on the roadmap. CRACI also has no snippet or binary scanning, no SBOM sharing portal, and supports GitHub Actions only. If license compliance is your first concern, keep FOSSA.

For the Cyber Resilience Act

FOSSA publishes CRA guidance. Its summary of the SBOM requirement: manufacturers draw up an SBOM in a commonly used, machine-readable format covering "at the very least the top-level dependencies of the products," and share it with market surveillance authorities as part of the technical documentation. FOSSA positions import, generation, vulnerability analysis and secure sharing with authorities as its CRA help.

Top-level dependencies are the floor, not the goal. A vulnerability in a transitive package is still in your product. The CRA's reporting obligations apply from September 11, 2026, with an early warning due within 24 hours for an actively exploited vulnerability, and its main provisions apply from December 11, 2027. CRACI records the full dependency set each build used, links artifacts to builds and SBOMs through its API, and exports reports 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 and CRA compliance with CRACI.