CRACI vs Dependency-Track

What Dependency-Track does well

OWASP Dependency-Track is a strong choice for component analysis. It is open source under the Apache 2.0 license, it tracks component usage across every version of every application in your portfolio, and it pulls vulnerability intelligence from several sources, including the National Vulnerability Database and GitHub Advisories. Its policy engine covers security, license and operational rules, and it consumes and produces CycloneDX VEX documents. Its API-first design fits CI/CD: pipelines upload SBOMs to /api/v1/bom.

Teams in regulated sectors like it because it is transparent, self-hosted and built around a standard format. Its weak point is not the analysis. It is what goes into it.

Analysis depends on its input

Dependency-Track consumes SBOMs; it does not generate them. Every finding, policy violation and portfolio view depends on the SBOM your pipeline sends. If the SBOM misses a dependency, Dependency-Track cannot flag it. If two generators disagree, Dependency-Track shows whichever one you uploaded.

In practice, SBOM generators disagree a lot, and the reasons are in their own documentation:

• No common ground. Each generator decides for itself what counts as a component and which files to trust, so two of them pointed at one repository return overlapping but different lists.
• Missing the obvious. A tool that resolves dependencies from lock files has nothing to resolve in a repository that commits none, as express 5.2.1 does not. It can still return a list, made of whatever else it recognizes, such as GitHub Actions and workflow files.
• Configuration swings. Syft picks its catalogers by scan type, so one flag changes what the same tool at the same version reports from the same checkout.
• No manifest, no SBOM. A repository with no dependency manifest at all gives a file-based scanner nothing to work from, and what each tool returns then says more about the tool than about the project.
• Thin metadata. Most generators have no source for the NTIA supplier field, so it comes out empty whatever the repository holds.

CRACI cannot be compared this way. It records builds rather than scanning a directory, so it cannot be run the same way. The point is not that any of these tools is bad. It is that a static scan of a repository is an estimate of what a build will use, and the estimate varies with the tool, its settings and the files present.

What CRACI changes at the source

The SBOM comes from the build

CRACI is a GitHub Actions-compatible runner. You change runs-on to craci, and your jobs run on CRACI in isolated virtual machines. During each job, a package-aware proxy records traffic to package sources: 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, in CycloneDX or SPDX, includes all transitive dependencies the build actually used.

It tells you when it is incomplete

Every CRACI SBOM carries a completeness state per job and per cache: Complete, Complete with connections, Incomplete, Unavailable or Not recorded. You know whether each SBOM is a full record or has a gap. That matters when an auditor asks how you know your inventory is complete.

It ties the SBOM to the artifact

CRACI generates the SBOM inside its own runner, so the artifact shipped is provably the artifact described. Signed provenance (Ed25519 over SHA-512) links each artifact, including OCI artifacts, to its build. The API takes you from an artifact to its producing build, its CycloneDX SBOM and the job network trace.

It controls what the build can reach

Because CRACI runs the job, it can enforce a network egress policy: default deny or default allow, with 24 built-in software-source presets and typed custom sources. Policies are validated before the job starts and fail closed. Dependency-Track can tell you a component is risky after the fact; an egress policy limits which sources a build could pull from in the first place.

Replacing Dependency-Track with CRACI

CRACI covers both halves of the job that used to take a generator and Dependency-Track. It produces the SBOM in the 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. There is no upload step to maintain and no server to run.

Be clear about what you give up. Dependency-Track's policy engine and VEX support are mature, and CRACI has neither today: license policy is on the roadmap, as are comments and threshold alerts. Dependency-Track is also open source and self-hosted, while CRACI is a managed service. If those matter more than the quality of the inventory, keep Dependency-Track.

Why this matters in regulated sectors

Under the EU Cyber Resilience Act, manufacturers need to know what is in each product release and handle vulnerabilities in it, with reporting obligations for actively exploited vulnerabilities starting in September 2026. A vulnerability you cannot see because your SBOM missed the component is still your vulnerability.

CRACI automates a significant part of the software supply chain visibility and evidence that companies need for their wider CRA compliance process, and exports reports in PDF, HTML, CSV, Excel and JSON. The inventory and the monitoring come from the same record of what each release was built from. See CRA compliance, industrial IoT and telecom.