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

Software supply chain security, recorded from every build

Your software supply chain meets your product in the CI build. CRACI runs your GitHub Actions jobs on secure runners and records every dependency they pull in, controls what each build can reach, signs what it produces and keeps tracking vulnerabilities in what you shipped.

Book a demo How CRACI works →

Secure runners for GitHub Actions

Change runs-on to craci and your GitHub Actions jobs run on CRACI's runners, with runs still showing in GitHub. Every job gets its own isolated virtual machine on Linux x86-64 or ARM64, hosted in Europe. Builds run about twice as fast as on GitHub-hosted runners, thanks to faster hardware, shorter queue times and caching.

GitHub Actions jobs on CRACI runners A GitHub Actions workflow sets runs-on to craci. Each job runs in its own isolated virtual machine on a CRACI runner, on Linux x86-64 or ARM64, hosted in Europe, and the run still appears in GitHub. .github/workflows/release.yml jobs: build: runs-on: craci was: ubuntu-latest CRACI runners Hosted in Europe Job VM build Linux x86-64 Job VM test Linux ARM64 Job VM publish Linux x86-64 One isolated virtual machine per job, 1 to 32 vCPU Runs still appear in GitHub About 2x GitHub-hosted speed

An SBOM recorded from every build

CRACI is a recorder, not a scanner. A package-aware proxy on the runner sees every package the job pulls in from npm, PyPI, RubyGems, Cargo, Go, Nix and OCI registries, plus OS and download sources, including packages restored from CI caches. Each job's SBOM carries a completeness state and exports as CycloneDX or SPDX with transitive dependencies and each component's declared license.

An SBOM recorded during the build Packages from npm, PyPI, Cargo, Go, OCI registries and the CI cache pass through a package-aware proxy on the CRACI runner. The job's SBOM lists what was fetched, states its completeness and exports as CycloneDX or SPDX. Package sources npm PyPI Cargo · Go OCI registries CI cache restore Package- aware proxy on the runner Job SBOM express 5.2.1 requests 2.32.3 serde 1.0.219 + transitive deps Declared license on every component Complete Completeness states per job and cache: Complete, Complete with connections, Incomplete, Unavailable, Not recorded CycloneDX · SPDX

Control what a build can reach

An egress policy decides which hosts a job may connect to: default deny or default 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 violations trigger an email alert. A compromised dependency or build step cannot quietly send data to a host you never approved.

An egress policy on the build network A build job connects to hosts in its egress policy, such as package registries and Git, and a connection to a host outside the policy is blocked. The policy is validated before the job starts and fails closed, and a violation sends an email alert. Egress policy Default deny Validated before the job starts Fails closed · 24 source presets Build job on a CRACI runner npm registry allowed PyPI allowed Git over HTTPS allowed Unapproved host blocked Email alert on policy violation Connections are recorded in the job's network trace

Signed provenance for what you ship

CRACI signs provenance that links each artifact, including OCI images, to the build that produced it, using Ed25519 over SHA-512. At any later point you can check that what is deployed is exactly what was built, and trace an artifact through its build and SBOM to the network trace of the job.

Signed provenance from artifact to build The build produces an artifact such as an OCI image. CRACI signs provenance with Ed25519 over SHA-512 that links the artifact to its build, so what is deployed can later be verified as exactly what was built. The artifact traces to its build, its CycloneDX SBOM and the job's network trace. Build release job on CRACI Artifact OCI image sha256:9f2c… Signed provenance Ed25519 over SHA-512 Later: verify what is deployed Deployed artifact = What was built Traceable through the API Artifact Build CycloneDX SBOM Network trace Covers your own artifacts, including OCI images

Vulnerability tracking after release

CRACI keeps re-evaluating the SBOMs of what you shipped as new vulnerabilities are published, and aggregates findings across builds and repositories. Security teams triage them and route each one to the team that owns the fix. Policy gates can block a build on findings or on a license, VEX is supported, vendor SBOMs are monitored alongside your own builds, and the inventory view shows which software versions are deployed to which products.

Vulnerability tracking after release After a release ships, its SBOM stays monitored. When a new vulnerability is published, CRACI re-evaluates the monitored SBOMs, finds the affected releases, and the security team triages the finding and routes it to the team that owns the fix. The inventory view shows which software versions are deployed to which products. Release shipped SBOM monitored Later New advisory published Re-evaluated automatically Finding: critical, in 2 releases 1. Triage 2. Route to owner 3. Team fixes Policy gates can block a build on findings · VEX supported Inventory: deployed versions Product Version Web app v4.12.0 Mobile API v2.3.1

Evidence for customers and auditors

Customers, auditors and regulations increasingly ask for an SBOM per release and a record of how vulnerabilities were handled. CRACI exports reports as PDF, HTML, CSV, Excel or JSON, and a public REST API returns SBOMs, network traces and artifact provenance. The same evidence supports the EU Cyber Resilience Act, NIS2, FDA SBOM requirements and ISO 27001 supply chain controls.

Evidence exports from the build record SBOMs, vulnerability records, signed provenance and network traces export as PDF, HTML, CSV, Excel or JSON, or through the public REST API, for customers, auditors and frameworks such as the EU Cyber Resilience Act, NIS2, FDA SBOM requirements and ISO 27001 supply chain controls. The build record SBOMs Vulnerability records Signed provenance Network traces Export PDF HTML CSV Excel JSON or the REST API Who asks for it Customers Auditors Security reviews Frameworks this evidence supports EU Cyber Resilience Act NIS2 supply chain security FDA SBOM for cyber devices ISO 27001 supply chain controls

The questions a supply chain incident raises

When a package, a CI action or a registry is compromised, the first hours go to working out whether you are affected. These are the questions teams ask, and where CRACI's record of the build answers them.

The question How CRACI answers it
Did any of our builds pull in the compromised package version? Every build's SBOM lists the packages the job actually fetched, so you search recorded builds instead of re-scanning repositories.
Which of our products and releases are affected? Monitored SBOMs are re-evaluated continuously, and the inventory view maps software versions to the products they are deployed to.
Could a build step have sent secrets somewhere? Each job's network trace records the connections it made, and the egress policy blocks hosts outside the policy before they are reached.
Is the artifact in production the one we built? Signed provenance links the artifact to its build, so it can be verified at any later point.
Is this SBOM complete enough to hand over? Each job's SBOM states its completeness: Complete, Complete with connections, Incomplete, Unavailable or Not recorded.
Who is fixing it, and can we prove it was handled? Findings are triaged and routed to owning teams, and the record exports as PDF, HTML, CSV, Excel or JSON.

CRACI covers the build and what it ships. Code scanning, secrets scanning and reachability analysis stay with your application security tools. GitHub Actions is supported today, with other CI systems on the roadmap.

Software supply chain security, answered

What it covers, why it belongs in CI/CD, and where CRACI fits

What is software supply chain security?

Software supply chain security protects everything that goes into your software between the first commit and the release: open-source dependencies, base images, build tools, third-party CI actions, the CI pipeline itself and the artifacts you ship. It means knowing what those parts are, controlling where they come from, and proving what went into each release.

Why secure the software supply chain in CI/CD?

The release build is where your dependencies are resolved, downloaded and packaged. A production build is not the build on a laptop: version ranges, mutable tags and caches mean it can pull in something different. A record taken while the release build runs is the only reliable record of what shipped, and the build runner is where you can control what the build may reach.

How is CRACI different from a supply chain security scanner?

Scanners read files after the fact: a manifest, a lockfile, source code or a finished binary. CRACI is the runner for your GitHub Actions jobs, so it observes the build as it happens and records the packages each job actually pulled in, including packages restored from CI caches. Each SBOM states its own completeness, an egress policy controls what the build can reach, and signed provenance links each artifact to its build.

Does CRACI replace my GitHub Actions workflows?

No. CRACI replaces the runner, not GitHub Actions. You change runs-on to craci, and your workflows, triggers and run history stay in GitHub.

Which CI systems and platforms does CRACI support?

GitHub Actions today; other CI systems are on the roadmap, GitLab CI among them. Runners are Linux on x86-64 and ARM64, with Windows and macOS on the roadmap.

Does CRACI do SAST, secrets scanning or reachability analysis?

No. CRACI records and controls the build, tracks vulnerabilities in what you shipped and produces the evidence. Scanning your own code for flaws or secrets, and reachability analysis, are jobs for an application security tool.

Where is my build data stored?

CRACI is hosted in Europe, on European bare-metal infrastructure, and data is kept for 180 days by default, with custom retention on Enterprise. CRACI does not store your source code. CRACI is ISO 27001 certified; details are in the Trust Center.

See what your builds actually pull in

Book a demo to see the SBOM, network trace, egress policy and signed provenance CRACI records for a GitHub Actions build

Book a demo