What CRACI replaces in your stack, and what it works alongside

The short answer: what moves and what stays

Map your own stack with this table. Each row is a job a tool in your stack does today, what that job needs to see to do it, and whether CRACI does it from where it sits.

Job in your stack	What the job needs to see	CRACI	What you keep, and why
CI runners for Linux jobs on GitHub Actions: GitHub-hosted, a third-party runner provider or a self-hosted fleet	Somewhere to run the job	Replaces	Runners for Windows, macOS, GitHub Enterprise Server and CI systems other than GitHub Actions, which CRACI does not support today
Network monitoring or egress agents added to runners you keep	The job's outbound traffic	Replaces on CRACI runners	Agents on runners you keep elsewhere
SBOM generators run in CI, team by team: manifest, lockfile or image scanners used to produce SBOMs	What the build actually pulled in	Replaces for builds on CRACI	Generators for software you do not build on CRACI, such as images you pull and never build
Yocto's built-in SBOM generation (create-spdx) for supply chain coverage	Every source and tool the BitBake build fetched	Replaces for supply chain coverage	create-spdx, if you rely on its recipe metadata: applied patches and CVEs marked as fixed
SBOM-to-vulnerability tracking: upload SBOMs, match advisories, watch for new ones	An accurate SBOM per release, kept current	Replaces for builds on CRACI; vendor SBOMs can be added	A dedicated tool if you need what CRACI does not do: reachability, remediation metrics such as MTTR or deadlines per severity
SBOMs and component lists kept in spreadsheets	An accurate SBOM per release, kept current	Replaces	Nothing
Declared-license checks and license policy	Each component's declared license	Partly	Full-text and snippet-level license scanning, attribution notices
SAST and code scanning	Your source code	Works alongside	Keep it; it runs unchanged as a workflow step on a CRACI runner
Secret scanning and push protection	Your repository and commits	Works alongside	Keep it
DAST and API testing	Your running service	Works alongside	Keep it
Binary and firmware analysis of third-party binaries	A finished binary you did not build	Works alongside	Keep it
Snippet and signature scanning for copied or vendored code	File contents in the repository	Works alongside	Keep it
Reachability-based prioritization	Your call graph	Works alongside	Keep it if you rely on it
IaC, cluster and misconfiguration scanning	Configuration and running infrastructure	Works alongside	Keep it
CI/CD posture checks on workflow configuration	Workflow files and settings	Works alongside	Keep it
Ticketing, PSIRT case management, advisory publishing	Your process	Works alongside	Keep it
Compliance automation: collecting evidence for SOC 2 or ISO 27001 audits	Your controls across systems	Works alongside	Keep it; CRACI's records are evidence it can collect

The before and after

Before: GitHub-hosted runners, a different SBOM generator in each team's workflow, Yocto's create-spdx adding build time, and SBOMs uploaded to a tracker or a spreadsheet, with code scanning, secret scanning, binary analysis and ticketing around them. After: CRACI runners that run each job, enforce its egress policy, record its SBOM and keep it under monitoring. The tools that read code, repositories, binaries and your process are unchanged.

What CRACI replaces, and why

Each of these jobs happens during the build. CRACI can take them over because it is where the build runs. For each one: the mechanism, what you give up, and an example.

Your runners

CRACI is a runner for GitHub Actions. You change runs-on to craci, and the runs still appear in GitHub like any other Actions job. Each job gets its own virtual machine, on Linux x86-64 or ARM64, at a size from 1 to 32 vCPUs, metered per second. There is no workflow rewrite: your existing steps, scan steps included, keep running.

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. That makes it one of the most affordable CI runners. It runs builds about twice as fast as GitHub-hosted runners, thanks to faster hardware, shorter queue times and caching.

Runner, per minute	CRACI	GitHub-hosted	Difference
2 vCPU x64	$0.004	$0.006	CRACI about 33% cheaper
2 vCPU ARM64	$0.004	$0.005	CRACI 20% cheaper
32 vCPU x64	$0.064	$0.082	CRACI about 22% cheaper
32 vCPU ARM64	$0.064	$0.050	CRACI 28% more expensive

GitHub list prices as of September 2026. GitHub rounds each job up to a whole minute; CRACI meters per second. Example: a 10-minute build on a GitHub-hosted 2-core x64 runner costs $0.060. At about twice the speed it takes 5 minutes on a 2 vCPU CRACI runner and costs $0.020, about 67% lower. See pricing and CI runner pricing.

What you give up. Windows and macOS runners, other CI systems and customer-hosted runners are not available today; GitLab CI, Jenkins, Windows, macOS and customer-hosted runners are on the roadmap. GitHub Enterprise Server is not supported. Runners are managed, on European infrastructure. If you are weighing managed runners against your own fleet, see managed vs self-hosted runners.

Egress agents on runners you keep

An egress agent watches or limits the traffic of a runner someone else operates. On CRACI the runner itself enforces the egress policy: default deny or allow, 24 built-in software-source presets, typed custom sources for package registries and Git, and explicit network rules. The policy is validated before the job starts and fails closed, and CRACI alerts on policy violations. A separate agent is not needed on CRACI runners.

Example: a compromised dependency tries to send the job's secrets to a host the build has never needed. With a default-deny policy the connection is blocked, even in an attack nobody has seen before, because the policy allows only what the build needs rather than looking for known-bad hosts.

What you give up. The policy covers jobs on CRACI runners. Runners you keep elsewhere still need their own control.

The SBOM generator in every team's workflow

A generator reads the files in front of it, such as a manifest, a lockfile or an image, and reconstructs what went in. Different generators return different lists from the same checkout, and teams usually pick their own, so the organization ends up with several inventories that do not line up.

CRACI records the packages each job actually pulled in, including packages restored from CI caches, and the hidden dependencies that lockfile-based tools miss: code downloaded by npm install hooks, Rust build scripts that download at build time, and the base image and its operating system layers in a container build. Every component in the SBOM was in the build. Each job's SBOM states its completeness, as Complete, Complete with connections, Incomplete, Unavailable or Not recorded, so a gap is visible instead of silent. The result is one inventory for every repository that builds on CRACI, exported as CycloneDX or SPDX. Ecosystems recorded today: npm, PyPI, RubyGems, Composer, Cargo, Go, Nix, OCI, apt, apk and Git sources, plus Yocto and OpenEmbedded downloads.

Example: expressjs/express 5.2.1 commits no lockfile. A generator that resolves dependencies from lockfiles has nothing to resolve there, and can still return a document that lists none of the npm dependencies declared in package.json. A build of the same project on CRACI records the packages npm install fetched. More on the method in build-time SBOMs and SCA and SBOM tools compared; for a do-it-yourself generator stack, see the DIY SBOM stack.

What you give up. Ecosystems CRACI does not record yet. Maven and Java are on the roadmap, and anything not in the list above is not covered. Keep a generator for those builds.

Yocto's built-in SBOM generation

Yocto writes its own SPDX SBOM through create-spdx, and it is thorough about what BitBake builds. It cannot see what happens outside BitBake's metadata. CRACI runs the BitBake build and records what it fetched. In a side-by-side build of core-image-sato on a native ARM64 runner with 32 vCPUs, CRACI's SBOM had every component Yocto's SBOM had, plus 88 it missed: 23 host packages on the build machine, 10 GitHub sources including the GitHub Action actions/upload-artifact, and 55 other sources and tools fetched during the build. It recorded all 653 Rust crate versions with pkg:cargo package URLs, so they can be matched against advisories. The build without Yocto's SBOM generation took 43% less time: about $9.96 against $5.68 per build at CRACI's price.

What you give up. Yocto's SPDX carries recipe metadata CRACI does not record: the patches applied and the CVEs marked as fixed. If you rely on those, keep create-spdx on. The method and the full comparison are on Yocto builds on CRACI.

Turning SBOMs into vulnerability tracking

A standalone tracker has to be fed an SBOM and trusts whatever it is given. CRACI produces the SBOM and keeps the record. Monitored SBOMs are re-evaluated continuously as new advisories are published. Build history shows which builds contained a vulnerable dependency, direct or transitive, so you know the period you were affected, within your plan's retention. Findings are triaged to the team that owns the fix, CRACI notifies the relevant people of a vulnerability and its severity, and policy gates can block a build on findings, including a build that contains a specific CVE. VEX is supported. Vendor SBOMs can be added, so bought-in components are monitored alongside your own builds.

Example: an advisory is published for a crate that one of your services compiled in three months ago. CRACI matches it against every monitored SBOM and shows which builds contained that version, without anyone uploading anything again.

What you give up. CRACI does not offer reachability analysis or remediation metrics such as MTTR, deadlines per severity or backlog trends. If you depend on those, keep the tool that provides them. See vulnerability tracking for the full capability.

The spreadsheet

For teams with no SBOM tooling, the thing CRACI replaces is manual assembly: someone copies dependency lists into a spreadsheet before a release or an audit. A build on CRACI produces the SBOM as a side effect of running, so the list exists for every build, not just the ones someone remembered.

What CRACI works alongside, and how

These tools read things CRACI never reads. CRACI does not read your source for flaws, does not test running services and does not analyze binaries it did not build. They keep running as they do now.

Tools that read your code and repository

SAST, secret scanning and push protection, snippet and signature scanning, IaC scanning and CI/CD posture checks all inspect your code, your commits or your configuration. Steps in your workflow run unchanged on a CRACI runner, and repository-level features are unaffected because they never ran on the runner. A code scanning step can sit in the same job as your build. SAST is out of scope by choice: plenty of excellent SAST tools work alongside CRACI. See SAST vs SCA for how the two kinds of finding differ.

Tools that inspect what you did not build

Binary and firmware analysis of supplier binaries, scanners for images you pull but never build, and DAST against running services all look at something that was built elsewhere or is already running. CRACI records builds; a binary that arrives from a supplier was built somewhere CRACI never saw. If the supplier gives you an SBOM, CRACI can monitor it alongside your own builds.

Reachability-based prioritization reads your call graph, which CRACI does not analyze. Keep it if you rely on it; see reachability analysis for what it can and cannot tell you.

Process systems

Ticketing, PSIRT case management, advisory publishing and compliance automation platforms run your process across many systems. CRACI routes findings to the owning team and holds the evidence from the build; keep your process tools for the rest. Records leave CRACI as CycloneDX or SPDX SBOMs and through the API, which returns SBOMs, network traces and provenance data. For the audit side, see SBOM checks for SOC 2. For license work beyond declared licenses, such as notices and full-text review, see open source license compliance. CRACI carries each component's declared license and enforces license policy rules, including blocking a build on a license.

How to find the point of displacement in your own stack

Five questions you can answer in an afternoon. Each answer tells you whether a line in your stack moves.

1. Do your builds run on GitHub Actions on Linux? If yes, the runners move. If not, CRACI displaces nothing today.
2. Who generates SBOMs today, and how many different generators are in use? Each generator on a repository you move to CRACI is a line that goes.
3. Do you build Yocto images? If yes, check whether anyone relies on the applied patches and fixed CVEs in create-spdx output before you switch it off.
4. Where do SBOMs go after they are generated: a tracker, a spreadsheet, nowhere? That tool or process is the second line that goes, unless you need reachability or remediation metrics from it.
5. Which of your security tools read code, repositories or third-party binaries? Those stay. Write them down, so nobody expects CRACI to replace them.

A worked example

An illustrative device maker, not based on any real company: Linux builds on GitHub-hosted runners, two teams using two different SBOM generators, a Yocto product line with create-spdx on, SBOMs collected in a shared spreadsheet, a code scanning suite and a ticketing system. Its security team answers yes to questions 1 and 3, finds two generators for question 2 and a spreadsheet for question 4, and lists code scanning, secret scanning and the ticketing system for question 5. Nobody uses the patch metadata in the Yocto SPDX.

Moves to CRACI	Stays
GitHub-hosted runners for the Linux jobs	Code scanning, run as a step on CRACI runners
Both SBOM generators	Secret scanning
create-spdx, since nobody needs its patch metadata	The ticketing system
The SBOM spreadsheet

On the runner line, a 10-minute build that costs $0.060 on a GitHub-hosted 2-core x64 runner costs about $0.020 on CRACI with the speed-up. The other tools' costs are the company's own to fill in.

When CRACI is not the answer

• Your pipelines run on GitLab CI, Jenkins, Azure DevOps or another CI system. CRACI supports GitHub Actions only today, with GitLab CI and Jenkins on the roadmap, so it displaces nothing yet.
• Your builds need Windows or macOS runners or GitHub Enterprise Server, or must run on your own infrastructure.
• Your main pain is noise from code scanning in your own code. That is a SAST tuning problem; see SAST vs SCA and how to reduce vulnerability noise.
• Your main risk is firmware and binaries you receive from suppliers, not code you build.
• Your stack is mostly Java and Maven, which are on the roadmap, or .NET, which is not in the list of ecosystems CRACI records.
• You need reachability-based prioritization or PSIRT case management today.

For the step-by-step view of the product, see how CRACI works; for the SBOM itself, SBOM generation.

What CRACI replaces: frequently asked questions

What does CRACI replace?

Your GitHub Actions runners for Linux jobs, the SBOM generators teams run in CI for builds that move to CRACI, Yocto's create-spdx for supply chain coverage, egress agents on runners, and standalone SBOM-to-vulnerability tracking for those builds. It does not replace tools that read your code, repositories or third-party binaries.

Is CRACI an add-on to our SCA tool, or does it replace something?

It replaces jobs at the build layer: the runner, SBOM generation and the tracking that follows from the SBOM. Whether that displaces your SCA tool depends on what you use it for. If it reads your code, does snippet or binary analysis or gives you reachability, those parts stay.

Do we still need our SBOM generator if we run builds on CRACI?

Not for builds that run on CRACI and use the ecosystems it records. CRACI records the packages each job pulled in and exports the SBOM as CycloneDX or SPDX. Keep a generator for software you do not build on CRACI, such as images you pull, and for ecosystems CRACI does not record yet, such as Maven.

Do we still need Yocto's built-in SBOM generation (create-spdx)?

For supply chain coverage, no: in a side-by-side core-image-sato build, CRACI's SBOM had every component Yocto's had, plus 88 it missed, and the build without create-spdx took 43% less time. Keep create-spdx on if you rely on its applied patches and CVEs marked as fixed, which CRACI does not record.

Does CRACI replace code scanning or secret scanning?

No. CRACI does not read your source code or commits for flaws or secrets. Keep those tools. Code scanning steps run unchanged in your workflow on a CRACI runner, and repository-level features are unaffected.

Does CRACI replace binary or firmware analysis?

No. CRACI records the builds it runs. For firmware and binaries you receive from suppliers, binary analysis is the right tool. If a supplier gives you an SBOM, CRACI can monitor it alongside your own builds.

Can we keep our existing security steps in GitHub Actions on CRACI runners?

Yes. CRACI replaces the runner, not GitHub Actions: you set runs-on to craci and your workflows, steps and results stay in GitHub. Scan steps, test steps and any other steps keep running as before.