CRACI and Dependabot

Keep Dependabot. Here is what it covers.

If your code lives on GitHub, you probably already use Dependabot. It does three useful things. Dependabot alerts tell you when a dependency in your repository matches a known vulnerability. Security updates open pull requests that upgrade vulnerable dependencies. Version updates keep dependencies current even when nothing is vulnerable.

All of this sits on GitHub's dependency graph, which parses the manifests and lockfiles in your repository. GitHub can export that graph as an SPDX SBOM. For ecosystems such as Go, Gradle and Maven, pre-made actions can submit dependencies resolved at build time through the dependency submission API.

For keeping dependencies patched with little effort, Dependabot is hard to beat, and CRACI does not open pull requests. What CRACI adds is the other half: a record of what each build actually pulled in, monitored for new vulnerabilities, so you know which shipped builds a new advisory affects and which update pull requests to merge first.

The questions Dependabot does not answer

Dependabot is built around the repository. It scans the default branch and relies on your manifests and lockfiles. GitHub's documentation is direct about this: alerts cannot catch every security issue, you should keep manifest and lock files up to date for accurate detection, and only advisories reviewed by GitHub trigger alerts.

That leaves questions a security or compliance lead will eventually be asked:

• What did the build for release 4.2 actually download, including tools and images not in any manifest?
• Could a build reach an arbitrary host on the internet while it ran?
• Can you prove that the binary a customer received came from that build?
• Can you produce that evidence for an auditor months later?

Answering those needs a view from inside the build, which is where CRACI runs.

What CRACI adds

Build-time visibility

CRACI is a GitHub Actions-compatible runner. You change runs-on to craci and your jobs run on CRACI in isolated virtual machines, while runs still show in the GitHub UI. During each job, a package-aware proxy records traffic to package sources: npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk and Git sources, plus download presets. Packages restored from CI caches are carried forward, because dependency evidence travels with the cache.

Each SBOM states how complete it is, per job and per cache: Complete, Complete with connections, Incomplete, Unavailable or Not recorded. That is different from a graph that is only as good as the files it parses.

The difference shows up in practice. GitHub's dependency graph export is built from what GitHub knows about the repository, so it can list components no file-based scanner finds, and it reflects the default branch rather than the commit you built. Neither behavior is wrong for what the graph is designed to do. They show why a repository view and a build record are different things. (CRACI cannot be compared that way, since it records builds instead of scanning directories.)

Runtime controls

Dependabot tells you about a vulnerable package after it is in your manifest. It has no say over what a build can connect to. CRACI does, because it runs the build. Egress policies are default deny or default allow, with 24 built-in software-source presets, typed custom sources for npm, PyPI, apt, apk, the Go proxy, Nix, Cargo, OCI registries and Git, and explicit TLS, TCP, UDP and ICMP rules. Policies are validated before the job starts, fail closed, and trigger an alert on violation.

Provenance

CRACI generates the SBOM inside its own runner, from what the job fetched. The API returns SBOMs, network traces and provenance.

Compliance evidence

Regulations such as the EU Cyber Resilience Act ask manufacturers to know what is in each product release and to handle vulnerabilities in it. CRACI aggregates vulnerabilities across builds and repositories, keeps re-evaluating monitored SBOMs as new advisories appear, and exports SBOMs as CycloneDX or SPDX, including vulnerabilities. It automates a significant part of the software supply chain visibility and evidence that companies need for their wider CRA compliance process. Learn more on what the CRA is and CRA evidence.

An inventory of what is deployed where

CRACI's inventory view shows exactly which software versions are deployed to which products, globally. When a new vulnerability lands, you can see which products run the affected version instead of piecing it together from release notes and spreadsheets.

How teams use both

• Dependabot keeps dependencies patched on the default branch and opens pull requests when advisories land.
• CRACI runs the GitHub Actions jobs, records what each build fetched, limits where builds can connect, monitors what each build pulled in for new vulnerabilities, and keeps the release evidence.

There is nothing to migrate. Dependabot keeps working on your repositories, and your workflows keep running on GitHub Actions, just on a different runner.

CRACI and Dependabot: common questions

What each tool covers, SBOMs, pricing and compliance

Does CRACI replace Dependabot?

No. Keep Dependabot on. It flags vulnerable dependencies in your repositories and opens pull requests that upgrade them. CRACI runs your GitHub Actions jobs and records what each build actually pulled in, controls where builds can connect and monitors what shipped for new vulnerabilities.

Do CRACI's vulnerability views replace Dependabot alerts?

No. They answer a different question. Dependabot alerts are about the default branch of one repository. CRACI aggregates vulnerabilities across builds and repositories and keeps re-evaluating monitored SBOMs, so you can see which builds share a vulnerable dependency, and security teams can triage findings and send them to the team that owns the fix. Policy gates can block a build; threshold alerts are on the roadmap.

Does CRACI open pull requests like Dependabot?

No. Dependabot security updates and version updates open pull requests; CRACI does not. What CRACI adds is the build record, so when a new advisory lands you know which shipped builds it affects and which update pull requests to merge first.

How do the SBOMs from GitHub and CRACI differ?

GitHub exports the dependency graph as an SPDX SBOM, built from the manifests and lockfiles in the repository and the dependency submission API, and it reflects the default branch. CRACI records the SBOM while each build runs and exports it as CycloneDX or SPDX, with a completeness state per job and per cache that tells you whether the recording had a gap.

Does CRACI help when a dependency is not in any manifest?

Yes, if the build fetches it from a package source. Because CRACI records traffic during the job, a tool downloaded by a script or a package restored from a cache still shows up in the build record, and the SBOM's completeness state tells you if anything could not be recorded.

How much do Dependabot and CRACI cost?

Dependabot security updates and version updates are included in every GitHub plan, including Free (as of September 2026). CRACI charges only for build minutes: $0.002 per vCPU-minute ($0.004 for a default 2 vCPU runner), metered per second, with no monthly fee and no per-SBOM charge. See pricing for current terms.

Is CRACI only for teams with compliance requirements?

No, but that is where the evidence pays off most. If you sell software into the EU, the Cyber Resilience Act makes a per-release component inventory and vulnerability handling part of the job. For everyone else, knowing what your builds fetch is still the basis of supply-chain incident response. Book a demo to see the build record for one of your own workflows.