124% mehr gemeldete CVEs pro Tag in 2026 als im Vorjahr.

Plattform

So funktioniert CRACI

CRACI führt Ihre GitHub-Actions-Builds aus und zeichnet auf, was jeder einzelne lädt. Alles andere, von der Schwachstellenverfolgung bis zu CRA-Nachweisen, baut auf dieser Aufzeichnung auf.

Aktualisiert am

Überblick über die CRACI-Plattform. Quellcode auf GitHub fließt über GitHub Actions in den CRACI Secure Build Service. Der Build speist CRACI Package Analytics, dann Vulnerability Analysis (die auch Eingaben von Drittanbietern erhält), Digital Inventory und Compliance Reporting, das an Dritte wie Kunden, Lieferanten und die ENISA berichtet. Der Build speist außerdem CRACI Attack Prevention. Attack Prevention und Digital Inventory führen beide zum Deployment in Staging und Produktion.
Die CRACI-Plattform, von links nach rechts. Diagramm in voller Größe öffnen.

Kurz gesagt

Die meisten Sicherheitstools betrachten Ihren Code oder Ihre Manifeste im Nachhinein und leiten ab, was ein Build vermutlich enthielt. CRACI ist der Build-Runner und sieht deshalb, was der Build tatsächlich lädt, und zwar in dem Moment, in dem es geschieht. Diese Aufzeichnung ist die Grundlage für alles im Diagramm: Paketanalyse, Angriffsabwehr, Schwachstellenanalyse, Rückverfolgbarkeit und Compliance-Berichte.

Sie behalten GitHub und GitHub Actions. Die Änderung ist eine Zeile in jedem 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.

Schritt für Schritt

1. Quellcode und CI/CD: GitHub und GitHub Actions

Ihr Code bleibt auf GitHub. Sie verbinden Ihre Organisation, indem Sie die CRACI GitHub App installieren, für alle Repositories oder nur für die, die Sie auswählen. Workflows laufen weiter über GitHub Actions, und ihre Läufe erscheinen weiterhin in GitHub. GitHub Actions ist heute die unterstützte CI-Integration; Unterstützung für weitere CI/CD-Systeme ist auf der Roadmap.

2. Build: CRACI Secure Build Service

Jobs laufen auf CRACI-Runnern in isolierten virtuellen Maschinen. Runner skalieren von 1 bis 32 Recheneinheiten (je 1 vCPU und 3 GB RAM), nativ auf x86-64 und ARM64, mit einem GitHub-kompatiblen Ubuntu-Image oder den schlanken Images von CRACI. Die Nutzung wird sekundengenau abgerechnet.

Builds auf CRACI laufen etwa doppelt so schnell wie auf den Standard-Runnern von GitHub. Jede Minute kostet zudem weniger: Ein Standard-Linux-Runner mit 2 vCPU kostet $0.004 pro Minute, gegenüber $0.006 bei GitHub (etwa 33 % weniger). Zusammengenommen ist ein Build, der auf GitHub 10 Minuten dauert, auf CRACI in etwa 5 fertig und kostet etwa 67 % weniger. CRACI rechnet außerdem sekundengenau ab, statt jeden Job auf eine volle Minute aufzurunden, sodass Pipelines aus vielen kurzen Jobs noch mehr sparen. Zum vollständigen Vergleich mit GitHub-gehosteten Runnern.

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. Erfassung der Lieferkette: CRACI Package Analytics

Während der Job läuft, beobachtet ein paketbewusster Proxy den Datenverkehr zu den Paketquellen und zeichnet jede externe Abhängigkeit auf, die der Build lädt, aus npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk und Git-Quellen, dazu Yocto- und OpenEmbedded-Download-Presets. Die Nachweise reisen mit CI-Caches mit, sodass auch Pakete aus einem Cache erfasst bleiben.

Das ist der Unterschied zu anderen SBOM-Tools. Diese lesen das Lockfile oder das Build-Ergebnis und leiten ab, was eingeflossen ist. CRACI sieht den Datenverkehr und zeichnet deshalb auch die versteckten Abhängigkeiten auf, die in keinem Lockfile stehen: Code, den npm-install-Hooks herunterladen, Dateien, die Rust-Build-Skripte zur Build-Zeit abrufen, und die Basis-Image-Layer eines Container-Builds.

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.

Jeder Job und jeder Cache erhält einen Vollständigkeitsstatus, von Complete bis Not recorded, sodass Sie wissen, wie weit Sie der erzeugten SBOM vertrauen können. SBOMs lassen sich als CycloneDX oder SPDX exportieren, transitive Abhängigkeiten eingeschlossen.

4. Kontinuierliche Lieferkettensicherheit: CRACI Attack Prevention

Dieselbe Schicht, die den Datenverkehr aufzeichnet, steuert ihn auch. Eine Egress-Richtlinie legt fest, welche Hosts ein Job erreichen darf, mit Default-Deny oder Default-Allow, integrierten Presets für gängige Softwarequellen und eigenen Regeln für Ihre Quellen. Richtlinien werden vor dem Start des Jobs validiert und blockieren im Fehlerfall (Fail-closed), und CRACI warnt Sie bei Verstößen. Eine kompromittierte Abhängigkeit oder ein kompromittiertes Build-Tool, das nach Hause telefonieren will, wird am Runner gestoppt.

Weil die Richtlinie nur zulässt, was der Build braucht, statt nach bekannten bösartigen Hosts zu suchen, wirkt sie auch gegen Angriffe, die noch niemand gesehen hat. Erreicht ein Wurm wie Shai-Hulud zuerst Ihren Build, wird sein Versuch, Ihre Secrets nach außen zu senden, trotzdem blockiert.

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. Kontinuierliche Reaktion in der Lieferkette: CRACI Vulnerability Analysis

Aufgezeichnete Pakete werden mit bekannten Schwachstellen abgeglichen, und überwachte SBOMs werden laufend neu bewertet, sodass Sie auch eine Schwachstelle erreicht, die nach der Auslieferung veröffentlicht wurde. Ansichten auf Organisationsebene zeigen, welche Builds und Repositories eine verwundbare Abhängigkeit teilen, und Sicherheitsteams können jeden Befund sichten und an das Team weitergeben, das für die Behebung zuständig ist. Sie können auch SBOMs Ihrer Drittanbieter hinzufügen, sodass zugekaufte Komponenten zusammen mit denen überwacht werden, die Ihre eigenen Builds laden.

Using SBOMs for improved cybersecurity

Wie aus einer Build-Time-SBOM nach dem Release eine Schwachstellenüberwachung wird: genau die Aufgabe der SBOM-Generierung und Schwachstellenverfolgung von CRACI.

Petteri Pulkkinen und Erika Marttinen bei Kubernetes Community Days Helsinki 2026, 22:11 bis 23:27 aus SBOMbastic: Getting Ready for Upcoming EU Cybersecurity Regulation in Software Supply Chains.

6. Rückverfolgung der Lieferkette: CRACI Digital Inventory

Jeder Build hat seine SBOM und den Netzwerk-Trace seiner Verbindungen, und die CRACI-API liefert SBOMs, Netzwerk-Traces und Provenienzdaten. Wenn eine neue Schwachstelle oder ein kompromittiertes Paket Schlagzeilen macht, beantworten Sie an einer Stelle, welche Ihrer Builds betroffen sind.

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. Berichte zur Lieferkette: CRACI Compliance Reporting

Die unterwegs gesammelten Nachweise gehen an diejenigen, die danach fragen: Kunden, Lieferanten und Behörden. SBOMs lassen sich als CycloneDX oder SPDX exportieren, einschließlich der in ihren Komponenten gefundenen Schwachstellen, die API liefert SBOMs, Netzwerk-Traces und Provenienzdaten, und CRACI übermittelt CRA-Schwachstellenmeldungen in Ihrem Namen.

Der Cyber Resilience Act ist die bekannteste Vorschrift dahinter, aber nicht die einzige. Über alle Regelwerke hinweg ist die Forderung dieselbe: wissen, was in Ihrer Software steckt, und einen Prozess haben, um ihre Schwachstellen zu finden und zu behandeln.

  • EU Cyber Resilience Act: eine SBOM und Schwachstellenbehandlung für Produkte mit digitalen Elementen, die in der EU verkauft werden, mit Meldepflichten ab September 2026.
  • NIS2: Lieferkettensicherheit sowie Behandlung und Offenlegung von Schwachstellen für wesentliche und wichtige Einrichtungen.
  • ISO/IEC 27001: nennt SBOMs nicht, aber die Controls in Anhang A fordern ein Inventar der Assets (5.9), Sicherheit in der IKT-Lieferkette (5.21) und das Management technischer Schwachstellen (8.8). Build-Time-SBOMs und kontinuierliche Überwachung sind Nachweise für alle drei.
  • US FDA: eine SBOM in Zulassungsanträgen für vernetzte Medizinprodukte, dazu ein Plan, Schwachstellen nach dem Release zu überwachen und zu beheben.
  • US Executive Order 14028: SBOMs für jedes Produkt und ein Prozess zur Offenlegung von Schwachstellen in den Vorgaben zur Software-Lieferkette für Anbieter, die an die US-Bundesregierung verkaufen.

CRACI liefert Ihnen die SBOMs und die kontinuierliche Schwachstellenüberwachung, die diese Regelwerke erwarten, und die Nachweise hinter Ihren Compliance-Aussagen. Die Erfüllung jedes Regelwerks bleibt Ihr Prozess; CRACI automatisiert den Nachweisteil.

8. Deployment: Staging und Produktion

Was in Staging und Produktion ankommt, wurde unter Ihrer Netzwerkrichtlinie gebaut, mit einer SBOM, die während des Builds aufgezeichnet und nach dem Release auf neue Schwachstellen überwacht wird.

Weiterführend

Sehen Sie CRACI in Ihrer eigenen Pipeline

Buchen Sie eine Demo, und wir gehen gemeinsam Ihre Builds, Ihre SBOMs und Ihre Compliance-Nachweise durch.

Demo buchen