104% more reported CVEs per day in 2026 than last year.

Platform

How CRACI works

CRACI runs your GitHub Actions builds and records what each one pulls in. Everything else, from vulnerability tracking to CRA evidence, is built on that record.

Updated

CRACI platform overview. Source code on GitHub flows through GitHub Actions into the CRACI Secure Build Service. The build feeds CRACI Package Analytics, then Vulnerability Analysis (which also takes input from third-party vendors), Digital Inventory and Compliance Reporting, which reports to third parties such as customers, vendors and ENISA. The build also feeds CRACI Attack Prevention. Attack Prevention and Digital Inventory both lead to staging and production deployment.
The CRACI platform, left to right. Open the full-size diagram.

The short version

Most security tools look at your code or your manifests after the fact and infer what a build probably contained. CRACI is the build runner, so it sees what the build actually fetched, at the moment it fetched it. That record is the input to everything on the diagram: package analytics, attack prevention, vulnerability analysis, traceability and compliance reporting.

You keep GitHub and GitHub Actions. The change is one line in each workflow:

Switching a GitHub Actions job to CRACI A workflow file with a build job. The line runs-on: ubuntu-latest changes to runs-on: craci. That is the only change, and the job's runs still show up in GitHub. .github/workflows/build.yml jobs: build: runs-on: ubuntu-latest ubuntu-lates ubuntu-late ubuntu-lat ubuntu-la ubuntu-l ubuntu- ubuntu ubunt ubun ubu ub u c cr cra crac craci ✓ One line per job. Runs still show up in GitHub.

Step by step

1. Source code and CI/CD: GitHub and GitHub Actions

Your code stays on GitHub. You connect your organization by installing the CRACI GitHub App, on all repositories or only the ones you choose. Workflows keep running from GitHub Actions and their runs still show up in GitHub. GitHub Actions is the supported CI integration today; support for other CI/CD systems is on the roadmap.

2. Build: CRACI Secure Build Service

Jobs run on CRACI runners in isolated virtual machines. Runners scale from 1 to 32 compute units (1 vCPU and 3 GB of RAM each), on native x86-64 and ARM64, with a GitHub-compatible Ubuntu image or CRACI's slim images. Usage is metered per second.

Builds on CRACI run about twice as fast as on GitHub's standard hosted runners. Each minute also costs less: a standard 2 vCPU Linux runner is $0.004 per minute, against GitHub's $0.006 (about 33% less). Together, a build that takes 10 minutes on GitHub finishes in about 5 on CRACI and costs about 67% less. CRACI also bills per second instead of rounding each job up to a whole minute, so pipelines made of many short jobs save more. See the full comparison with GitHub-hosted runners.

One 10-minute build, GitHub-hosted runner versus CRACI On a GitHub-hosted 2-core Linux runner, a 10-minute build at $0.006 per minute costs $0.060, and each job is rounded up to a whole minute. On CRACI, the same build takes about 5 minutes at $0.004 per minute and costs $0.020, billed per second. That is about 67 percent less. GitHub-hosted runner standard 2-core Linux x64 build time 10 min per minute $0.006 cost of the build $0.060 CRACI size 2, Linux x64 build time about 5 min per minute $0.004 cost of the build $0.020 About 2x faster and about 67% less per build Billed per second; GitHub rounds jobs up to a minute.

3. Supply chain discovery: CRACI Package Analytics

While the job runs, a package-aware proxy observes traffic to package sources and records every external dependency the build pulls in, across npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk and Git sources, plus Yocto and OpenEmbedded download presets. Evidence travels with CI caches, so packages restored from a cache are still accounted for.

This is the difference from other SBOM tools. They read the lockfile or the build's output and work out what went in. CRACI sees the traffic, so it also records the hidden dependencies no lockfile lists: code that npm install hooks download, files Rust build scripts fetch at build time, and the base image layers of a container build.

How a scanned SBOM and a recorded SBOM are made Left, a scanner: it reads the lockfile after the build, which lists packages A to E, so its SBOM contains A to E. The build also fetched code through an install hook, a build script download and a base image, which are in no lockfile, so the scanned SBOM is missing them. Right, CRACI: it sees the traffic coming into the build, so all eight packages, including the three hidden dependencies, land in the recorded SBOM. Scanner reads files after the build package-lock.json A B C D E the build also fetched install hook download build script download base image layers in no lockfile, so the scan never sees them Scanned SBOM A B C D E missing missing missing CRACI sees the traffic into the build the network build job on CRACI every package that comes in Recorded SBOM A B C D E install hook build script base image hidden ones too
A scanner can only list what the lockfile or the output declares. CRACI sees what actually came into the build, including the hidden dependencies.

Each job and cache gets a completeness state, from Complete to Not recorded, so you know how far to trust the SBOM it produced. SBOMs export as CycloneDX or SPDX, including transitive dependencies.

4. Continuous supply chain security: CRACI Attack Prevention

The same layer that records traffic also controls it. An egress policy decides which hosts a job may reach, with default deny or default allow, built-in presets for common software sources and custom rules for your own. Policies are validated before the job starts and fail closed, and CRACI alerts you on violations. A compromised dependency or build tool that tries to call home is stopped at the runner.

Because the policy allows only what the build needs, instead of looking for known-bad hosts, it works against an attack nobody has seen before. If a worm such as Shai-Hulud reaches your build first, its attempt to send your secrets out is blocked all the same.

What happens when malware in a build tries to send your secrets out Left, a runner that allows all outbound traffic: the build reaches its package registry and publishes its output, then a malicious install hook sends the build's secrets to an attacker's server, and they arrive. Right, CRACI with a default-deny egress policy: the registry and publish connections are allowed, the connection to the attacker's server is blocked at the policy, and an alert is sent. The policy allows only what the build needs, so it works even against an attack nobody has seen before. Any outbound allowed build job holds your tokens and keys malicious install hook runs no egress policy package registry publish output attacker server allowed allowed secrets sent to the attacker CRACI default-deny egress policy build job on CRACI holds your tokens and keys malicious install hook runs egress policy: only what the build needs package registry publish output attacker server allowed allowed blocked blocked, and you get an alert
The policy allows only what the build needs, instead of looking for known-bad hosts, so it stops a new attack the first time it runs.

5. Continuous supply chain response: CRACI Vulnerability Analysis

Recorded packages are matched against known vulnerabilities, and monitored SBOMs are re-evaluated continuously, so a vulnerability disclosed after you shipped still reaches you. Organization-level views show which builds and repositories share a vulnerable dependency, and security teams can triage each finding and send it to the team that owns the fix. You can also add SBOMs from your third-party vendors, so the components you buy in are monitored alongside the ones your own builds pull in.

Using SBOMs for improved cybersecurity

How a build-time SBOM turns into vulnerability monitoring after release, which is the job CRACI's SBOM generation and vulnerability tracking do.

Petteri Pulkkinen and Erika Marttinen at Kubernetes Community Days Helsinki 2026, 22:11 to 23:27 of SBOMbastic: Getting Ready for Upcoming EU Cybersecurity Regulation in Software Supply Chains.

6. Supply chain tracing: CRACI Digital Inventory

Every build has its SBOM and the network trace of what it connected to, and the CRACI API returns SBOMs, network traces and provenance. When a new vulnerability or a compromised package makes the news, you can answer which of your builds are affected from one place.

A new vulnerability, traced back through build history Eight releases, v1.0 to v1.7, are built and recorded over time. Today a new advisory is published for example-lib 2.3.1. CRACI's build history shows that v1.2 and v1.3 contained it as a transitive dependency and v1.4 and v1.5 as a direct one, while v1.6 and v1.7 already shipped a fixed version. The exposure period is v1.2 to v1.5, answered from the recorded SBOMs without rescanning old code. Build history every build keeps its recorded SBOM New advisory today example-lib 2.3.1 today v1.0 v1.1 v1.2 v1.3 v1.4 v1.5 v1.6 v1.7 v1.2 transitive v1.3 transitive v1.4 direct v1.5 direct fixedfixed exposure period: v1.2 to v1.5 Answered from the recorded SBOMs, without rescanning old code
CRACI keeps re-evaluating the SBOMs of what you shipped. Build history follows your retention, 180 days by default.

7. Supply chain reporting: CRACI Compliance Reporting

The evidence collected along the way goes to the people who ask for it: customers, vendors and authorities. SBOMs export as CycloneDX or SPDX, including the vulnerabilities found in their components, the API returns SBOMs, network traces and provenance, and CRACI submits CRA vulnerability notifications on your behalf.

The Cyber Resilience Act is the best-known rule behind this, but not the only one. Across frameworks the ask is the same: know what is in your software, and have a process for finding and handling its vulnerabilities.

  • EU Cyber Resilience Act: an SBOM and vulnerability handling for products with digital elements sold in the EU, with reporting obligations from September 2026.
  • NIS2: supply chain security and vulnerability handling and disclosure for essential and important entities.
  • ISO/IEC 27001: does not name SBOMs, but its Annex A controls call for an inventory of assets (5.9), security in the ICT supply chain (5.21) and management of technical vulnerabilities (8.8). Build-time SBOMs and continuous monitoring are evidence for all three.
  • US FDA: an SBOM in premarket submissions for connected medical devices, plus a plan to monitor and address vulnerabilities after release.
  • US Executive Order 14028: SBOMs for each product and a vulnerability disclosure process in the software supply chain guidance for vendors selling to the federal government.

CRACI gives you the SBOMs and the continuous vulnerability monitoring these frameworks expect, and the evidence behind your compliance claims. Meeting each framework is still your process; CRACI makes the evidence part of it automatic.

8. Deployment: staging and production

What reaches staging and production has been built under your network policy, with an SBOM recorded during the build and monitored for new vulnerabilities after release.

Go deeper

See CRACI on your own pipeline

Book a demo and we will walk through your builds, your SBOMs and your compliance evidence.

Book a demo