How CRACI works

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:

jobs:
  build:
    runs-on: craci

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 23% less at €1 = $1.16). Together, a build that takes 10 minutes on GitHub finishes in about 5 on CRACI and costs about 61% 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.

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 and OCI registries, plus operating system and source download hosts. Evidence travels with CI caches, so packages restored from a cache are still accounted for.

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 violations can be sent to you by email. A compromised dependency or build tool that tries to call home is stopped at the runner.

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.

1:16

6. Supply chain tracing: CRACI Digital Inventory

Every artifact can be traced back through the build that produced it to its SBOM and the network trace of that build. Signed provenance links an artifact, including OCI images, to its build. When a new vulnerability or a compromised package makes the news, you can answer which of your builds and artifacts are affected from one place.

7. Supply chain reporting: CRACI Compliance Reporting

The evidence collected along the way becomes reports you can hand to the people who ask for them: customers, vendors and authorities. Reports export as PDF, HTML, CSV, Excel and JSON.

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 and is traceable back to the build that produced it. CRACI cryptographically signs each artifact's provenance, using Ed25519 over SHA-512, so you can check at any point later that what you have deployed is exactly what you built. Compare the deployed artifact with its signed provenance, retrieved through the CRACI API, and you know the artifact you run is the artifact your SBOM describes.

Go deeper

• CI/CD integration
• SBOM generation
• Vulnerability tracking
• Compliance reports
• CRACI documentation, including how to connect your GitHub organization and move your first workflow