Automatisierte Cyber-Resilienz für Entwickler und Agenten

Machen Sie jeden Build zu Ihrer ersten Verteidigungslinie.

Stellen Sie Lieferkettensicherheit ins Zentrum Ihrer Software, mit schnellen, zuverlässigen Runnern, die weniger kosten.

Ersten Build starten So funktioniert es

Sichere Runner
Build-Time-SBOMs
Schwachstellenüberwachung
Reaktion auf Schwachstellen

185 Pakete aufgezeichnet
6 Verbindungen abgewiesen
SBOM vollständig
Behoben in v2.4.1

Build

northwind-controls/web-portal

release.yml #1843 · 5d08e3b
runs-on: craci
size 2 · x86-64
Pakete
185 Pakete aufgezeichnet
- 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 gestoppt
CVE-2025-29927 · Critical
Build #1844 bestanden
Behoben in next 15.2.3
Veröffentlichtes Artefakt

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

sha256:e2b9…5c07
Veröffentlicht als v2.4.1

Teams, die auf CRACI bauen

Schwachstellen kommen schneller als jeder Fix.

Angreifern genügt ein einziger Weg hinein, und Agenten helfen ihnen, ihn schneller denn je zu finden. Ihr Team muss jede Lücke schließen, meist von Hand.

2026 bisher

veröffentlichte CVEs pro Tag: 293; Im Schnitt eine alle 5 Minuten.
Mehr pro Tag als im Vorjahr: +124%; Im Vergleich zur Tagesrate von 2025.
Als High oder Critical eingestuft, jeden Tag: 148; Nach ihren CVSS-Werten.

Veröffentlichte CVEs pro Tag, nach Jahr
Jahr	CVEs pro Tag	High oder Critical pro Tag
2020	39	7
2021	54	12
2022	68	20
2023	78	28
2024	109	48
2025	131	54
2026 bisher	293	148

Aus der öffentlichen CVE-Liste, täglich aktualisiert. Wählen Sie ein Jahr zum Vergleich. Zum CVE-Bericht

Warum jetzt

Warnungen sind zu Rauschen geworden.
Wenn Hunderte von Befunden dringend sind, ist es keiner. Teams steuern kein Risiko mehr, sondern zählen Warnungen.
Die Menge überfordert jedes Team.
Triage und Fixes passieren noch immer von Hand. Bei dieser Menge schließt mehr Personal die Lücke nicht.
Fixes konkurrieren mit Features.
Produktteams werden an ausgelieferten Features gemessen, also wartet die Sicherheitsarbeit auf einen ruhigen Sprint, der nie kommt.
Scanner schätzen nur.
Eine Liste, die nach dem Build aus Dateien abgeleitet wird, übersieht, was tatsächlich eingeflossen ist, und falsche Sicherheit hält Menschen davon ab, genauer hinzusehen.

Ihre Software nimmt im Build Gestalt an.

Ihr Lockfile legt fest, was installiert werden soll. Der Build entscheidet, was tatsächlich ankommt. CRACI zeichnet jedes Paket beim Eintreffen auf, mit aufgelöster Version, Herkunft und der Angabe, ob es aus einem CI-Cache wiederhergestellt wurde.

package-lock.json Was Sie festgelegt haben

"packages": {
  …
  
  
  
  
  
  …
}

Listet nur Versionen, nicht, woher jedes Paket kam oder wie es hineingelangt ist.

Build-Aufzeichnung #1842 185 Pakete aufgezeichnet

Pakete, die während des Beispiel-Builds #1842 von northwind-controls/web-portal aufgezeichnet wurden, gruppiert danach, wie sie in den Build gelangt sind.
Paket	Aufgelöst	Gelangt über	Quelle
Über package.json
express über package.json	4.21.2	package.json	registry.npmjs.org
next über package.json Jetzt betroffen von CVE-2025-29927 · Critical	15.2.2	package.json	registry.npmjs.org
react über package.json · aus CI-Cache	19.0.0	package.json	CI-Cache
react-dom über package.json · aus CI-Cache	19.0.0	package.json	CI-Cache
styled-jsx über next	5.1.6	next	registry.npmjs.org
Über Build-Skript
tailwindcss über Build-Skript	4.0.14	Build-Skript	registry.npmjs.org
typescript über Build-Skript	5.8.2	Build-Skript	registry.npmjs.org
und 178 weitere aufgezeichnete Pakete

185 Pakete aufgezeichnet · 2 aus dem Cache wiederhergestellt

Sichern Sie den Build. Zeichnen Sie seine Abhängigkeiten auf.

Ihre Jobs laufen auf CRACI-Runnern statt auf GitHub-gehosteten Runnern, doppelt so schnell. Jedes Paket, das sie laden, wird mit Version, Quelle und Lizenz aufgezeichnet. Alles aus einer Quelle außerhalb Ihrer Richtlinie wird abgewiesen.

Secure Build Service

Jeder Job läuft in einer eigenen isolierten virtuellen Maschine, hinter einer Egress-Richtlinie, die vor dem Start des Jobs geprüft wird.

Isolierte VM
Egress standardmäßig gesperrt
Fail-closed
Warnung bei Verstoß

Package Analytics

Ein paketbewusster Proxy zeichnet jedes Paket auf, das ein Job lädt, mit aufgelöster Version, Quelle und deklarierter Lizenz.

npm
PyPI
RubyGems
Cargo
Go
Nix
OCI
Yocto
und weitere

Richtlinien-Ereignis 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 ist nicht in der Richtlinie
actionAm Runner blockiert

Verbindung abgewiesen. Warnung gesendet.

Abhängigkeitsgraph v2.4.0

SBOM-Auszug 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" } }
    ]
  }, …]
}

Export als CycloneDX oder SPDX, transitive Abhängigkeiten und Schwachstellen eingeschlossen.

CRACI sieht den Datenverkehr, den Scanner nicht sehen.

Andere SBOM-Tools lesen das Lockfile oder das Build-Ergebnis und raten, was eingeflossen ist. CRACI sieht, was tatsächlich in jeden Build hineinkommt, einschließlich der versteckten Abhängigkeiten, die Build-Time-Hooks, Build-Skripte und Basis-Images nachladen.

Scanner

Scanner eines Mitbewerbers

Methode: Liest package-lock.json
Wann: Nach dem Build
Sieht: Was das Lockfile auflistet

SBOM, die ein Scanner aus dem Lockfile des Beispiel-Builds #1842 erstellt.
Paket	Version	Lizenz	Gefunden 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
In keinem Lockfile, also nicht in der SBOM
In keinem Lockfile, also nicht in der SBOM
In keinem Lockfile, also nicht in der SBOM

142 Pakete aufgelistet 43 fehlen

Aufgezeichnete SBOM

Methode: Sieht den Datenverkehr des Builds
Wann: Während des Builds
Sieht: Was der Build geladen hat

SBOM, die CRACI aus dem Datenverkehr des Beispiel-Builds #1842 aufzeichnet.
Paket	Version	Lizenz	Geladen von
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
vorkompilierte Binärdatei versteckt über postinstall-Hook · pkg:npm/hidden-package	—	—	registry.npmjs.org
2 Downloads des Build-Skripts versteckt über Build-Skript · pkg:generic/[email protected]?download_url=example.com/tool	—	—	example.com
40 Betriebssystempakete des Basis-Images versteckt über Dockerfile FROM · pkg:oci/ubuntu	—	—	registry.hub.docker.com

185 Pakete aufgezeichnet 43 mehr, als das Lockfile zeigt

Beispiel-Build. So funktionieren Build-Time-SBOMs

Ordnen Sie potenzielle Schwachstellen exakt den Releases zu.

CRACI prüft aufgezeichnete SBOMs laufend auf neue Schwachstellen. In diesem Beispiel zur Veranschaulichung wird 7 Tage nach dem Release eine kritische Schwachstelle veröffentlicht. Folgen Sie der Build-Aufzeichnung vom betroffenen Paket bis zum Fix des Teams.

Schritt 1 von 4

CVE-2025-29927 wird veröffentlicht

next ist eine direkte Abhängigkeit, und Build #1842 hat die genaue Version aufgezeichnet.

Schweregrad: Critical 9.1
Paket: next
Betroffen: 15.0.0 bis 15.2.2
Behoben in: 15.2.3

Schritt 2 von 4

Ein Release ist betroffen

CRACI gleicht es mit der aufgezeichneten SBOM ab.

Release: web-portal v2.4.0
Treffer: next 15.2.2, direkte Abhängigkeit
SBOM: Complete

Schritt 3 von 4

Ausgeliefert als dieses Image

Release, Image und SBOM bleiben zusammen.

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

Schritt 4 von 4

Der Fix hat eine verantwortliche Person

Sichten, zuweisen und bis zum behobenen Release verfolgen.

Verantwortlich: Plattformteam
Maßnahme: next auf 15.2.3 aktualisieren und neu bauen
Behoben in: web-portal v2.4.1, 2025-03-22

Beantworten Sie jede Auditfrage mit Nachweisen.

Jeder Build hinterlässt Nachweise: SBOMs, Schwachstellendatensätze und den Weg jedes Fixes in ein Release. Nutzen Sie sie für Ihre Prozesse zu CRA, NIS2, ISO 27001 und SOC 2, damit die Frage eines Auditors ein Download ist und kein Projekt.

Zusammensetzung: Eine Build-Time-SBOM für jedes Release.

CycloneDX
SPDX
Transitive Abhängigkeiten
Schwachstellen
Deklarierte Lizenzen
Schwachstellenbehandlung: Aufgezeichnete SBOMs werden laufend neu bewertet.

Triage
Fix
Beim Release aufbewahrt
Meldung: CRACI meldet in Ihrem Namen.

Frühwarnung
Meldung
Abschlussbericht

Cyber Resilience Act

11. September 2026 Meldepflichten gelten
11. Dezember 2027 Verordnung gilt vollständig

Zum CRA-Leitfaden

Schwachstellenmeldung Auszug

web-portal v2.4.0

northwind-controls/web-portal · Build #1842

SBOM: CycloneDX · Complete
Build: #1842 · Commit 9f3c2e1
Schwachstelle: CVE-2025-29927 · Critical
Komponente: next 15.2.2
Meldet an: CSIRT und ENISA, über die einheitliche CRA-Meldeplattform

Ablauf der Behandlung

2025-03-14 Release gebaut und SBOM aufgezeichnet
2025-03-21 Advisory veröffentlicht und diesem Release zugeordnet
2025-03-21 Gesichtet von Produktsicherheit, zugewiesen an Plattformteam
2025-03-22 v2.4.1 veröffentlicht mit next 15.2.3

SBOM-Export als CycloneDX oder SPDX

Ihr erster Build in 5 Minuten.

In dieser Demo bringen wir eine TanStack-Start-Website von der Registrierung bis zum ersten Lauf auf CRACI. Wir verbinden GitHub, leiten die Jobs mit runs-on: craci um und verfolgen den ersten Lauf. CRACI zeichnet jede externe Abhängigkeit auf, die der Build lädt, markiert bekannte Schwachstellen und führt jede auf den Job zurück, der sie hereingebracht hat.

Sehen Sie, wie CRACI in Ihren Delivery-Workflow passt.

CRACI ersetzt den Runner, nicht GitHub Actions. Ihre Workflows, Reviews und Deployment-Schritte bleiben, wie sie sind.

GitHub App verbinden

Für alle Repositories oder nur für ausgewählte.
Runner umstellen

Setzen Sie runs-on: craci im Workflow. Sonst ändert sich nichts.
Nächsten Build starten

Die Läufe erscheinen weiterhin in GitHub. Build-Aufzeichnung und SBOM erscheinen in CRACI.

Runner: Verwaltete Linux-Runner auf x86-64 und ARM64, auf europäischer Infrastruktur.
Builds: Docker Engine, Buildx und Compose v2. Yocto- und BitBake-Builds sind dokumentiert.
Ihr Code und Ihre Daten: CRACI verarbeitet Quellcode während Ihres Builds und speichert ihn nicht. Build-Daten werden in Europa gehostet. Was im Cache liegt, hängt davon ab, was Ihre Workflows speichern. Zur Sicherheitsseite.
Auf der Roadmap: GitLab, Jenkins und weitere CI-Systeme, Windows- und macOS-Runner, On-Prem-Runner, Maven und Java.

Ersten Build starten So funktioniert CRACI

Fragen, die Teams vor einer Demo stellen

Kompatibilität, Einrichtung, Sicherheit und Datenverarbeitung.

Welche CI-Umgebungen und Paket-Ökosysteme werden unterstützt?

GitHub Actions ist heute die unterstützte CI-Integration, weitere CI-Systeme sind auf der Roadmap. CRACI zeichnet npm-, PyPI-, RubyGems-, Cargo-, Go-, Nix- und OCI-Registries auf, Paketquellen von Debian, Ubuntu und Alpine sowie Git- und andere Quell-Downloads. Maven und Java sind auf der Roadmap. Die Runner laufen unter Linux auf x86-64 und ARM64.

Was erfordert die Einrichtung?

Sie verbinden die CRACI GitHub App mit allen oder ausgewählten Repositories und setzen runs-on: craci in Ihrem Workflow. CRACI ersetzt den Runner, nicht GitHub Actions, Ihre Läufe erscheinen also weiterhin in GitHub.

Auf welche Daten greift CRACI zu, und wo werden sie gespeichert?

Die GitHub App liest Ihren Code und Ihre Actions-Läufe und verwaltet die Runner, die sie für Ihre Organisation registriert. CRACI verarbeitet Quellcode während Ihres Builds und speichert ihn nicht. Build-Daten, darunter Metadaten, Paketdaten, Netzwerk-Traces, SBOMs, Provenienz, Caches und Audit-Protokolle, werden in Europa gehostet, mit individueller Aufbewahrungsdauer im Enterprise-Plan. Was im Cache liegt, hängt davon ab, was Ihre Workflows speichern. Mehr zu Sicherheit und Datenverarbeitung.

Blockiert CRACI oder warnt es nur? Was passiert mit einem Build, der gegen eine Richtlinie verstößt?

Die Egress-Richtlinie wird am Runner durchgesetzt. Sie wird vor dem Start des Jobs validiert und blockiert im Fehlerfall (Fail-closed): Eine Verbindung außerhalb der Richtlinie wird abgewiesen, und Sie erhalten eine Warnung. Policy-Gates können einen Build außerdem in Echtzeit stoppen.

Welche Formate kann ich exportieren?

SBOMs lassen sich als CycloneDX oder SPDX exportieren, einschließlich transitiver Abhängigkeiten, Schwachstellen und deklarierter Lizenzen.

Was ist heute verfügbar und was ist auf der Roadmap?

Heute verfügbar: verwaltete Linux-Runner für GitHub Actions, Build-Time-SBOMs mit Schwachstellen, Egress-Richtlinie, laufende Schwachstellenüberwachung mit Triage und Policy-Gates. Auf der Roadmap: GitLab, Jenkins und weitere CI-Systeme, Windows- und macOS-Runner sowie On-Prem-Runner.

Unterstützt von