Automated cyber resilience for developers & agents

Make every build your first line of defence.

Put supply chain security at the heart of your software with fast, reliable runners that cost less.

Secure runners
Build-time SBOMs
Vulnerability monitoring
Vulnerability response

185 packages recorded
6 connections refused
SBOM complete
Fixed in v2.4.1

Build

northwind-controls/web-portal

release.yml #1843 · 5d08e3b
runs-on: craci
size 2 · x86-64
Packages
185 packages recorded
- next 15.2.2
- react 19.0.0
- react-dom 19.0.0
- express 4.21.2
- tailwindcss 4.0.14
- typescript 5.8.2
Policy gate

Build #1843 stopped
CVE-2025-29927 · Critical
Build #1844 passed
Fixed in next 15.2.3
Released artifact

ghcr.io/northwind-controls/web-portal:2.4.1

sha256:e2b9…5c07
Released as v2.4.1

Vulnerabilities arrive faster than any fix.

Attackers need one way in, and agents help them find it faster than ever. Your team has to close every gap, mostly by hand.

2026 so far

CVEs published a day: 264; One every 5 minutes, on average.
More a day than the year before: +101%; Against the 2025 daily rate.
Rated High or Critical, every day: 135; From their CVSS scores.

CVEs published a day, by year
Year	CVEs a day	High or Critical a day
2020	39	7
2021	54	12
2022	68	20
2023	78	28
2024	109	48
2025	131	54
2026 so far	264	135

From the public CVE list, refreshed daily. Choose a year to compare. Read the CVE report

Why now

Alerts have become noise.
When hundreds of findings are urgent, none of them are. Teams stop managing risk and start counting alerts.
The volume outpaces any team.
Triage and fixes are still done by hand. At this volume, hiring more people does not close the gap.
Fixes compete with features.
Product teams are measured on shipping features, so security work waits for a quiet sprint that never comes.
Scanners simply estimate.
A list worked out from files after the build misses what actually went in, and false confidence stops people from looking.

Your software takes shape during the build.

Your lockfile pins what should be installed. The build decides what actually arrives. CRACI records every package as it comes in, with the resolved version, where it came from, and whether it was restored from a CI cache.

package-lock.json What you pinned

"packages": {
  …
  
  
  
  
  
  …
}

Lists versions only, not where each package came from or how it got in.

Build record #1842 185 packages recorded

Packages recorded during example build #1842 of northwind-controls/web-portal, grouped by how they entered the build.
Package	Resolved	Reached via	Source
Via package.json
express via package.json	4.21.2	package.json	registry.npmjs.org
next via package.json Now affected by CVE-2025-29927 · Critical	15.2.2	package.json	registry.npmjs.org
react via package.json · from CI cache	19.0.0	package.json	CI cache
react-dom via package.json · from CI cache	19.0.0	package.json	CI cache
styled-jsx via next	5.1.6	next	registry.npmjs.org
Via build script
tailwindcss via build script	4.0.14	build script	registry.npmjs.org
typescript via build script	5.8.2	build script	registry.npmjs.org
and 178 more recorded packages

185 packages recorded · 2 restored from cache

Secure the build. Record its dependencies.

Your jobs run on CRACI runners instead of GitHub-hosted ones, twice as fast. Every package they pull in is recorded with its version, source and license. Anything from a source outside your policy is refused.

Secure Build Service

Each job runs in its own isolated virtual machine, behind an egress policy that is checked before the job starts.

Isolated VM
Default-deny egress
Fails closed
Alert on violation

Package Analytics

A package-aware proxy records every package a job pulls in, with its resolved version, source and declared license.

npm
PyPI
RubyGems
Cargo
Go
Nix
OCI
Yocto
and more

Policy event Build #1842

time2025-03-14 09:13:07 UTC
jobrelease.yml #1842
stepnpm run build
policyDefault deny. Allowed: npm, GitHub, ghcr.io, Docker Hub, example.com
denied malicious.example:443
reasonHost is not in the policy
actionBlocked at the runner

Connection refused. Alert sent.

Dependency graph v2.4.0

SBOM excerpt CycloneDX 1.7 · JSON

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.7",
  …
  "components": [{
    "name": "next",
    "version": "15.2.2",
    "purl": "pkg:npm/[email protected]",
    "licenses": [
      { "license": { "id": "MIT" } }
    ]
  }, …]
}

Exports as CycloneDX or SPDX, transitive dependencies and vulnerabilities included.

CRACI sees the traffic scanners don't.

Other SBOM tools read the lockfile or the build's output and guess what went in. CRACI sees what actually comes into each build, including the hidden dependencies pulled in by build-time hooks, build scripts and base images.

Scanner

Competitor Scanner

Method: Reads package-lock.json
When: After the build
Sees: What the lockfile lists

SBOM a scanner builds from the lockfile of example build #1842.
Package	Version	License	Found in
next pkg:npm/[email protected]	15.2.2	MIT	package-lock.json
react pkg:npm/[email protected]	19.0.0	MIT	package-lock.json
react-dom pkg:npm/[email protected]	19.0.0	MIT	package-lock.json
express pkg:npm/[email protected]	4.21.2	MIT	package-lock.json
styled-jsx pkg:npm/[email protected]	5.1.6	MIT	package-lock.json
Not in any lockfile, so not in the SBOM
Not in any lockfile, so not in the SBOM
Not in any lockfile, so not in the SBOM

142 packages listed 43 missing

Recorded SBOM

Method: Sees the build's traffic
When: During the build
Sees: What the build fetched

SBOM CRACI records from the traffic of example build #1842.
Package	Version	License	Fetched from
next pkg:npm/[email protected]	15.2.2	MIT	registry.npmjs.org
react pkg:npm/[email protected]	19.0.0	MIT	registry.npmjs.org
react-dom pkg:npm/[email protected]	19.0.0	MIT	registry.npmjs.org
express pkg:npm/[email protected]	4.21.2	MIT	registry.npmjs.org
styled-jsx pkg:npm/[email protected]	5.1.6	MIT	registry.npmjs.org
prebuilt binary hidden via postinstall hook · pkg:npm/hidden-package	—	—	registry.npmjs.org
2 build script downloads hidden via build script · pkg:generic/[email protected]?download_url=example.com/tool	—	—	example.com
40 base image OS packages hidden via Dockerfile FROM · pkg:oci/ubuntu	—	—	registry.hub.docker.com

185 packages recorded 43 more than the lockfile shows

Example build. How build-time SBOMs work

Pinpoint potential vulnerabilities to the exact releases.

CRACI continuously checks recorded SBOMs for new vulnerabilities. In this illustrative example, a critical vulnerability is disclosed 7 days after release. Follow the build record from the affected package to the team's fix.

Step 1 of 4

CVE-2025-29927 is disclosed

next is a direct dependency, and build #1842 recorded the exact version.

Severity: Critical 9.1
Package: next
Affected: 15.0.0 to 15.2.2
Fixed in: 15.2.3

Step 2 of 4

One release is affected

CRACI matches it against the recorded SBOM.

Release: web-portal v2.4.0
Match: next 15.2.2, direct dependency
SBOM: Complete

Step 3 of 4

It shipped as this image

The release, its image and its SBOM stay together.

Image: ghcr.io/northwind-controls/web-portal:2.4.0
Release: v2.4.0
SBOM: Tracked

Step 4 of 4

The fix has an owner

Triage it, route it, and track it to a fixed release.

Owner: Platform team
Action: Upgrade next to 15.2.3 and rebuild
Fixed in: web-portal v2.4.1, 2025-03-22

Answer every auditor with proof.

Every build leaves evidence behind: SBOMs, vulnerability records and how each fix reached a release. Use it for your CRA, NIS2, ISO 27001 and SOC 2 processes, so an auditor's question takes a download, not a project.

Composition: A build-time SBOM for every release.

CycloneDX
SPDX
Transitive dependencies
Vulnerabilities
Declared licenses
Vulnerability handling: Recorded SBOMs are re-evaluated continuously.

Triage
Fix
Kept with the release
Reporting: CRACI submits on your behalf.

Early warning
Notification
Final report

Cyber Resilience Act

11 September 2026 Reporting obligations apply
11 December 2027 Regulation applies in full

Read the CRA guide

Vulnerability filing Excerpt

web-portal v2.4.0

northwind-controls/web-portal · build #1842

SBOM: CycloneDX · Complete
Build: #1842 · commit 9f3c2e1
Vulnerability: CVE-2025-29927 · Critical
Component: next 15.2.2
Reports to: CSIRT and ENISA, via the CRA Single Reporting Platform

Handling timeline

2025-03-14 Release built and SBOM recorded
2025-03-21 Advisory published and matched to this release
2025-03-21 Triaged by Product security, assigned to Platform team
2025-03-22 v2.4.1 released with next 15.2.3

SBOM exports as CycloneDX or SPDX

Run your first build in 5 minutes.

In this demo we take a TanStack Start site from sign-up to its first run on CRACI. We connect GitHub, route the jobs with runs-on: craci and watch the first run. CRACI records every external dependency the build pulls in, flags known vulnerabilities and traces each one back to the job that brought it in.

See how CRACI fits your delivery workflow.

CRACI replaces the runner, not GitHub Actions. Your workflows, reviews and deployment steps stay as they are.

Connect the GitHub App

On all repositories or only the ones you select.
Update your runner

Set runs-on: craci in the workflow. Nothing else moves.
Run your next build

Runs still appear in GitHub. The build record and SBOM appear in CRACI.

Runners: Managed Linux runners on x86-64 and ARM64, on European infrastructure.
Builds: Docker Engine, Buildx and Compose v2. Yocto and BitBake builds are documented.
Your code and data: CRACI processes source code during your build and does not store it. Build data is hosted in Europe. Cache contents depend on what your workflows save. Read the security page.
On the roadmap: GitLab, Jenkins and other CI systems, Windows and macOS runners, on-prem runners, Maven and Java.

Run your first build See how CRACI works

Questions teams ask before a demo

Compatibility, setup, security and data handling.

Which CI environments and package ecosystems are supported?

GitHub Actions is the supported CI integration today, and other CI systems are on the roadmap. CRACI records npm, PyPI, RubyGems, Cargo, Go, Nix and OCI registries, Debian, Ubuntu and Alpine package repositories, and Git and other source downloads. Maven and Java are on the roadmap. Runners are Linux on x86-64 and ARM64.

What does setup require?

You connect the CRACI GitHub App on all or selected repositories and set runs-on: craci in your workflow. CRACI replaces the runner, not GitHub Actions, so your runs still appear in GitHub.

What data does CRACI access, and where is it stored?

The GitHub App reads your code and your Actions runs, and manages the runners it registers for your organization. CRACI processes source code during your build and does not store it. Build data, including metadata, package data, network traces, SBOMs, provenance, caches and audit records, is hosted in Europe, with custom retention on Enterprise. Cache contents depend on what your workflows save. Read about security and data handling.

Does CRACI block, or alert? What happens to a build that breaks a policy?

The egress policy is enforced at the runner. It is validated before the job starts and fails closed, so a connection outside the policy is refused and you get an alert. Policy gates can also stop a build in real-time.

Which formats can I export?

SBOMs export as CycloneDX or SPDX, including transitive dependencies, vulnerabilities and declared licenses.

What is available today and what is on the roadmap?

Available today: managed Linux runners for GitHub Actions, build-time SBOMs with vulnerabilities, egress policy, continuous vulnerability monitoring with triage, and policy gates. On the roadmap: GitLab, Jenkins and other CI systems, Windows and macOS runners, and on-prem runners.

Backed by