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 and OCI, plus OS packages and source or 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 email alert on violation.

Provenance

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 the build that produced it. The API takes you from an artifact to its producing build, its CycloneDX SBOM and the job network trace.

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 reports in PDF, HTML, CSV, Excel and JSON. 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 compliance reports.

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, signs provenance for each artifact, 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.

Common questions

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. Threshold alerts and build blocking are on the roadmap.

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.

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.