Tools und Plattformen für Software-Lieferkettensicherheit (2026)

Für wen diese Seite gedacht ist

Sie haben den Auftrag „Sichert unsere Software-Lieferkette ab“ und müssen entscheiden, wohin das Budget fließt. Die Tools unten arbeiten an unterschiedlichen Stellen: über Ihre Repositories und Pipelines hinweg, auf dem Build-Runner, an der Paket-Registry oder am fertigen Artefakt. Wir bauen CRACI, das in dieser Kategorie direkt im Wettbewerb steht, berücksichtigen Sie das also. Wir beschreiben jedes Tool anhand seiner eigenen Dokumentation und sagen, wo ein anderes Tool besser passt.

Was ist Software-Lieferkettensicherheit?

Den vollständigen Leitfaden finden Sie unter Was ist Software-Lieferkettensicherheit, dazu die Checkliste mit Best Practices.

Ihre Software besteht aus Ihrem eigenen Code und allem, wovon er abhängt: Open-Source-Pakete, Basis-Images, Build-Tools, CI-Actions von Drittanbietern und die Pipeline, die daraus ein Release macht. Software-Lieferkettensicherheit bedeutet zu wissen, was diese Teile sind, zu steuern, woher sie kommen, und zu belegen, was in jedes Release eingeflossen ist. Anwendungssicherheit sucht nach Fehlern in dem Code, den Sie schreiben; Lieferkettensicherheit deckt ab, was ihn umgibt.

Angreifer nehmen jedes Glied ins Visier. Drei aktuelle Vorfälle zeigen, wo:

• Eine Abhängigkeit. Im März 2024 wurde bösartiger Code in den Versionen 5.6.0 und 5.6.1 von xz utils gefunden, einer Kompressionsbibliothek, die in Linux-Distributionen ausgeliefert wird (CVE-2024-3094).
• Die CI-Pipeline. Im März 2025 wurde die GitHub Action tj-actions/changed-files kompromittiert (CVE-2025-30066), wodurch Secrets wie Access Keys, GitHub Personal Access Tokens und npm-Tokens aus den Workflows offengelegt wurden, die sie nutzten.
• Die Paket-Registry. Im September 2025 kompromittierte der sich selbst replizierende Wurm Shai-Hulud mehr als 500 npm-Pakete. Er stahl Zugangsdaten von Entwicklern, darunter GitHub-Tokens und Cloud-Schlüssel, und nutzte sie, um weitere infizierte Pakete zu veröffentlichen.

1:53

Welche Arten von Tools für Software-Lieferkettensicherheit gibt es?

Kein einzelnes Produkt deckt jedes Glied ab, und die Anbieter unten meinen mit „Lieferkettensicherheit“ Unterschiedliches. Die meisten Lösungen fallen in eine von sieben Arten, definiert danach, wo sie arbeiten.

Wie wählen Sie eine Plattform für Software-Lieferkettensicherheit?

Beginnen Sie mit der Frage, die Sie heute nicht beantworten können, und wählen Sie dann das Tool, das dort arbeitet, wo die Antwort liegt. Sechs Fragen grenzen die Optionen schnell ein.

• Brauchen Sie Breite oder Tiefe? Eine Plattform für Application Security Posture Management (ASPM) verbindet sich mit Ihren Repositories, Pipelines und Scannern und priorisiert Risiken über alle hinweg. Ein Tool auf Build-Ebene geht an einem Punkt tiefer: was geschah, während die Software gebaut wurde.
• Möchten Sie Ihre Runner behalten? Agenten wie StepSecurity Harden-Runner und Cimon von Cycode ergänzen Runner, die Sie bereits nutzen, um Überwachung. CRACI ersetzt den Runner für GitHub Actions.
• Liegt das Risiko in Ihren Eingaben? Wenn Sie sich vor allem um bösartige Pakete oder Basis-Images voller CVEs sorgen, gehen Tools, die Eingaben prüfen oder härten, das direkt an.
• Liefern Sie Software aus, die Sie nicht gebaut haben? Nur die Binäranalyse kann in ein Paket hineinsehen, ohne dessen Build zu haben.
• Welche CI-Systeme nutzen Sie? Die meisten Tools hier decken mehrere ab. CRACI unterstützt heute nur GitHub Actions; GitLab CI und Jenkins sind auf der Roadmap.
• Was müssen Sie belegen, und wem gegenüber? Kunden, Auditoren und Regulierungen wie der EU Cyber Resilience Act verlangen zunehmend eine SBOM pro Release und eine Aufzeichnung darüber, wie Schwachstellen behandelt wurden. Ein Dashboard voller Befunde ist nicht dasselbe wie ein Nachweis dessen, was ausgeliefert wurde.

Stellen Sie dann jedem Anbieter auf Ihrer Shortlist dieselben Fragen:

• Woher stammt Ihre Komponentenliste: aus Manifesten, Quellcodeanalyse, dem Build oder dem fertigen Binary?
• Sagt mir die SBOM, wann sie unvollständig ist, und lässt sie sich als CycloneDX oder SPDX exportieren?
• Können Sie verhindern, dass ein Build einen unerwarteten Host erreicht, oder melden Sie es nur im Nachhinein?
• Kann ich später prüfen, ob das Artefakt, das ich deploye, das gebaute ist?
• Welche Quellcodeverwaltungs- und CI-Systeme unterstützen Sie heute, und welche sind auf der Roadmap?
• Wonach wird abgerechnet: nach Entwicklern, Contributors, Images, Builds oder individuellem Angebot?

Wie schneiden die Tools im Vergleich ab?

Die Tools fallen in zwei Gruppen, deshalb gibt es zwei Tabellen. Die erste vergleicht Plattformen und Build-Sicherheitstools danach, wie sie die Pipeline sehen und kontrollieren. Die zweite vergleicht Tools, die an Eingaben und Ausgaben arbeiten. „Keine Angabe“ bedeutet, dass die von uns zitierten Herstellerseiten dazu nichts sagen.

Plattformen und Build-Sicherheit

Eingaben und Ausgaben

Was kosten Tools für Software-Lieferkettensicherheit?

Fünf der neun Tools unten rechnen pro Entwickler ab, und die meisten verkaufen ihre kostenpflichtigen Pläne über den Vertrieb. CRACI berechnet stattdessen nur Build-Minuten, die Kosten richten sich also danach, wie viel Sie bauen, nicht danach, wie viele Personen committen. Die Preise entsprechen dem, was die Anbieter im September 2026 veröffentlicht haben; Apiiro und Legit Security fehlen, weil ihre Seiten keine Preise nennen.

Preise pro Entwickler wachsen mit Ihrem Team, Preise nach Build-Minuten mit Ihren Pipelines. Der Preis von CRACI enthält die Runner-Minuten, die das ersetzen, was Sie für GitHub-gehostete Runner bezahlen. Siehe CRACI-Preise und Runner-Preise im Vergleich. Diagramme der veröffentlichten Preise nach Teamgröße, inklusive Runner, finden Sie unter Preise für Software-Lieferkettensicherheit im Vergleich.

CRACI

CRACI ist ein Runner für GitHub Actions. Sie ändern runs-on auf craci, und während jeder Job läuft, zeichnet ein paketbewusster Proxy auf, was er geladen hat, einschließlich der aus CI-Caches wiederhergestellten Pakete. Jede SBOM trägt einen Vollständigkeitsstatus pro Job und pro Cache, eine Egress-Richtlinie wird vor dem Start des Jobs validiert und blockiert im Zweifel (fail closed), und CRACI bewertet die SBOMs des Ausgelieferten laufend neu. Ideal für Teams, die Software ausliefern und zeigen müssen, was in jedes Release eingeflossen ist. Zu beachten: kein SAST, kein Secrets- oder IaC-Scanning, keine Posture-Prüfungen, keine Binäranalyse und heute nur GitHub Actions (GitLab CI und Jenkins sind auf der Roadmap). SBOM-Generierung während des Builds

Plattformen und ASPM

Apiiro

Apiiro ist eine ASPM-Plattform. Deep Code Analysis bildet Ihre Architektur vom Code bis zur Laufzeit ab, und der Risk Graph korreliert Befunde aus Apiiros eigenen Scannern und Tools von Drittanbietern zu „toxic combinations“. Sein Lieferketten-Modul inventarisiert Repositories und Pipelines, einschließlich Schatten-Pipelines, und kennzeichnet schwachen Branch-Schutz und auffällige Commits. Es verbindet sich über APIs und braucht keine CI-Änderungen. Ideal für große AppSec-Programme, die Architekturkontext über viele Quellcodeverwaltungssysteme hinweg möchten. Zu beachten: Sein Inventar stammt aus der Codeanalyse, nicht aus der Beobachtung von Builds, und es kontrolliert nicht, was ein Build erreichen kann. CRACI vs. Apiiro

Cycode

Cycode ist eine ASPM-Plattform mit SAST, SCA, Secrets-, Container- und IaC-Scanning, CI/CD-Posture und mehr als 100 Konnektoren. Sein Build-Baustein Cimon ist ein eBPF-Agent, der in Ihren CI-Jobs läuft. Er überwacht Prozesse, Netzwerk-Egress und Dateizugriffe, lernt das normale Verhalten einer Pipeline, bevor er es durchsetzt, erzeugt eine zur Laufzeit beobachtete SBOM und signiert SLSA-Provenienz. Laut Cycode ist Cimon kostenlos und Open Source. Ideal für eine Plattform für Code und viele CI-Systeme, mit Laufzeitschutz für Builds auf Runnern, die Sie behalten. Zu beachten: Cimon ist ein Agent, der Ihren Runnern hinzugefügt wird, nicht der Runner selbst. CRACI vs. Cycode

OX Security

OX Security ist eine ASPM-Plattform mit eigenen Scannern, der Zusammenführung von Befunden aus Tools wie Checkmarx, Snyk und Black Duck sowie CI/CD-Posture-Policies, die ungepinnte Actions, übermäßige Workflow-Berechtigungen und riskante Webhooks kennzeichnen. Seine Pipeline Bill of Materials (PBOM) ist eine signierte Aufzeichnung pro Build mit Pipeline-Definitionen, Runner-Identität, Build-Argumenten und Artefakt-Signaturen. Ideal für Posture-Policies und Gates für Pull Requests über GitHub Actions, GitLab, Jenkins, Azure Pipelines und CircleCI hinweg. Zu beachten: Seine SBOM wird aus angebundenen Quellen gesammelt, und seine Policies prüfen die Pipeline-Konfiguration, statt zu begrenzen, was ein laufender Job erreichen kann. CRACI vs. OX Security und OX-Security-Alternativen

Legit Security

Legit Security bildet Ihren gesamten Entwicklungslebenszyklus ab: ein laufend aktualisiertes Inventar der SDLC-Systeme, Pipelines und der Sicherheitskontrollen darauf, mit Hunderten von Policies über Quellcodeverwaltung, CI und Registries hinweg. Es orchestriert Scanner wie Snyk, Checkmarx und GitHub Advanced Security, ergänzt natives SAST und SCA, findet Secrets in Build-Logs, Slack und Confluence ebenso wie im Code und erstellt SBOMs und signierte Attestierungen. Ideal für ein Sicherheitsteam, das viele Repositories und mehrere CI-Systeme geerbt hat und eine Governance-Schicht braucht. Zu beachten: Es liest Konfiguration und Scanner-Ausgaben über APIs, sieht also nicht den Netzwerkverkehr eines laufenden Jobs. CRACI vs. Legit Security und Legit-Security-Alternativen

Kusari

Kusari stammt von dem Team, das GUAC mitentwickelt hat, den OpenSSF-Graphen für Lieferketten-Metadaten. Seine Plattform baut einen Wissensgraphen aus Ihren SBOMs, VEX-Dokumenten und Scanner-Ausgaben, zeigt den Wirkungsradius einer neuen Schwachstelle, analysiert die Erreichbarkeit und öffnet AutoFix-Pull-Requests, die es zuvor validiert. Kusari Inspector prüft Pull Requests auf bösartige Pakete, Secrets und unsichere Workflows, und laut Kusari ist die Installation kostenlos. Ideal für einen Graphen über viele SBOM-Quellen und Scanner hinweg. Zu beachten: Ein Graph spiegelt die SBOMs wider, mit denen er gefüttert wird, und die von Kusari stammen aus einem Generator (dem Toolkit waybill oder Ihrem eigenen Tool), nicht aus dem Build. CRACI vs. Kusari und Kusari-Alternativen

Endor Labs

Endor Labs ist auf Erreichbarkeit auf Funktionsebene ausgerichtet: Statische Programmanalyse verfolgt, ob Ihr Code eine verwundbare Funktion in einer direkten oder transitiven Abhängigkeit aufrufen kann, was laut Endor Labs SCA-Befunde um 92 % reduziert. Upgrade-Impact-Analyse, automatisierte Pull Requests und Endor Patches, die Fixes auf die von Ihnen genutzte Version zurückportieren, übernehmen die Behebung. Es deckt außerdem AI SAST, Secrets, Container, eine Package Firewall vor Ihren Registries und einen SBOM Hub mit erreichbarkeitsbasiertem VEX ab. Ideal für Teams, deren Hauptproblem die Menge an Warnungen ist. Zu beachten: Sein Inventar stammt aus der Analyse von Quellcode, und es führt Ihre Builds weder aus noch beschränkt es sie. CRACI vs. Endor Labs

Build- und Runner-Sicherheit

StepSecurity

StepSecurity Harden-Runner ist die größte Überschneidung von CRACI mit einem Sicherheitsanbieter. Es ist ein Agent auf den GitHub-Actions-Runnern, die Sie bereits nutzen, auch auf GitHub-gehosteten, und es ordnet jede ausgehende Verbindung, jeden Prozess und jeden Schreibzugriff auf Dateien dem Workflow-Schritt zu, der ihn verursacht hat. Es kann zuerst auditieren, pro Job eine Baseline erstellen und dann Egress zu allem blockieren, was nicht auf einer Allowlist steht. StepSecurity verkauft außerdem Secure Registry, Pull Requests zur Repository-Härtung und Dev Machine Guard. Ideal für Teams, die GitHub-gehostete oder selbst gehostete Runner behalten möchten oder GitLab CI oder Azure DevOps nutzen. Zu beachten: Seine Allowlist ist eine Liste von Endpunkten, und es zeichnet Ziele auf statt einer SBOM auf Paketebene. CRACI vs. StepSecurity

Paket- und Eingabesicherheit

Socket

Socket analysiert das Verhalten von Open-Source-Paketen: Install-Skripte, Netzwerk- und Dateisystemzugriffe, verschleierten Code, bekannte Malware und Typosquats. Es kennzeichnet riskante Neuzugänge in Pull Requests, und Socket Firewall blockiert bösartige Pakete bei der Installation, mit einer kostenlosen Version für npm, yarn, pnpm, pip, uv und cargo. Es bietet außerdem Erreichbarkeitsanalyse. Ideal für das Stoppen schädlicher Pakete, bevor sie ankommen, auch solcher, für die es noch kein Advisory gibt. Zu beachten: Es liest die Manifeste und Lockfiles, die ein Projekt deklariert, und seine Firewall filtert Paketinstallationen, nicht den übrigen Netzwerkverkehr eines Jobs. CRACI vs. Socket

Chainguard

Chainguard baut Open-Source-Software aus dem Quellcode und liefert sie gehärtet aus: Container-Images, die es als Zero-CVE bezeichnet, aus verifiziertem Quellcode neu gebaute Java-, Python- und JavaScript-Bibliotheken, VM-Images und gehärtete GitHub Actions, jeweils mit signierter SBOM und SLSA-Provenienz. Kunden mit einem Auftrag sagt es zu, kritische CVEs innerhalb von 7 Tagen und andere Schweregrade innerhalb von 14 Tagen nach einem qualifizierenden Patch zu beheben. Ideal für Teams, deren Scanner immer wieder CVEs in Basis-Images melden. Zu beachten: Seine SBOMs und Provenienz beschreiben die Artefakte von Chainguard. Ihr eigener Build braucht weiterhin eine eigene Aufzeichnung, deshalb passt es gut zu einem Tool auf Build-Ebene. CRACI und Chainguard

Binäranalyse

ReversingLabs

ReversingLabs Spectra Assure analysiert fertige Softwarepakete ohne Quellcode, mit statischer Binäranalyse, 16 Engines zur Malware-Erkennung und differenzieller Analyse, die verdächtige Änderungen zwischen Versionen kennzeichnet. Es exportiert CycloneDX- und SPDX-SBOMs aus dem Binary und kann kommerzielle Software und Software von Drittanbietern bewerten, bevor Sie sie deployen. Ideal für ein Release-Gate gegen Malware und Manipulation und für Software, die Sie nicht gebaut haben. Zu beachten: Es arbeitet rückwärts vom Ergebnis aus, sieht also keine Build-Tools oder Test-Abhängigkeiten, die der Build geladen, aber nicht ausgeliefert hat. CRACI vs. ReversingLabs

Frameworks und Regulierung hinter der Kategorie

Ein Großteil der Nachfrage nach diesen Tools stammt aus Frameworks und Vorschriften, die ein Komponenteninventar, eine Aufzeichnung darüber, wie Software gebaut wurde, und einen Prozess für den Umgang mit Schwachstellen verlangen.

• SLSA (Supply-chain Levels for Software Artifacts) ist ein Satz schrittweise einführbarer Richtlinien, gepflegt als branchenübergreifende Zusammenarbeit unter dem Dach der Linux Foundation. Sein Build-Track bewertet, wie vertrauenswürdig die Provenienz eines Builds ist.
• NIST SSDF (SP 800-218, Version 1.1, Februar 2022) legt Praktiken für sichere Softwareentwicklung fest, um Schwachstellen in veröffentlichter Software zu verringern.
• US Executive Order 14028, Abschnitt 4(e), ordnete Leitlinien zur Software-Lieferkette an, die auch die Bereitstellung einer SBOM für jedes Produkt an den Käufer umfassen. Sie prägt Leitlinien für die Beschaffung auf Bundesebene, statt jeden Anbieter direkt zu binden.
• CISA, NSA und ODNI veröffentlichten 2023 „Securing the Software Supply Chain: Recommended Practices Guide for Customers“, das Beschaffung, Tests, Deployment, Patching und SBOMs behandelt.
• Der EU Cyber Resilience Act (Verordnung (EU) 2024/2847) setzt seine Meldepflichten am 11. September 2026 in Kraft und gilt vollständig ab dem 11. Dezember 2027.
• NIS2 Artikel 21 Absatz 2 nennt die Sicherheit der Lieferkette und den Umgang mit Schwachstellen unter den Maßnahmen, die sie verlangt, und die US FDA verlangt von Herstellern von Cyber Devices eine SBOM.

Keines dieser Frameworks nennt eine Produktkategorie. Gemeinsam ist ihnen der Nachweis: eine genaue Komponentenliste pro Release, eine Aufzeichnung darüber, wie es gebaut wurde, und der Beleg, dass Schwachstellen verfolgt wurden.

Wo setzt CRACI an?

CRACI ist ein Runner für GitHub Actions. Sie ändern runs-on auf craci, und während jeder Job läuft, zeichnet ein paketbewusster Proxy auf, was er geladen hat, einschließlich der aus CI-Caches wiederhergestellten Pakete. Jede SBOM trägt einen Vollständigkeitsstatus pro Job und pro Cache. Eine Egress-Richtlinie, standardmäßig blockierend oder standardmäßig erlaubend, wird vor dem Start des Jobs validiert und blockiert im Zweifel (fail closed). CRACI bewertet die SBOMs des Ausgelieferten laufend neu. Die Inventaransicht von CRACI zeigt genau, welche Softwareversionen in welchen Produkten im Einsatz sind, weltweit. Das Ergebnis ist eine SBOM pro Build, eine Aufzeichnung dessen, was jeder Build erreicht hat, und Provenienzdaten aus der API, was einen erheblichen Teil der Transparenz und der Nachweise zur Lieferkette automatisiert, die Ihr CRA-Prozess braucht.

CRACI ist nicht die richtige Wahl, wenn Sie SAST, Secrets- oder IaC-Scanning, Posture-Prüfungen über Ihre Repositories hinweg, einen Audit-Modus vor dem Blockieren, Paket-Blocklists (auf der Roadmap), Binäranalyse oder heute andere CI-Systeme als GitHub Actions brauchen (GitLab CI und Jenkins sind auf der Roadmap). Viele Teams kombinieren es mit einem der oben genannten Tools: eine ASPM-Plattform für Code und Posture, Socket oder Chainguard für Eingaben, ReversingLabs für das Ergebnis. Lesen Sie mehr über SBOM-Generierung während des Builds, CI/CD-Integration und Preise, oder buchen Sie eine Demo, um einen aufgezeichneten Build von Anfang bis Ende zu sehen.

Tools für jeden Teil der Lieferkette vergleichen

Diese Seite ist der Überblick. Jeder Bereich hat eigene, tiefere Vergleiche und Leitfäden.

• SBOMs: SBOM-Tools im Vergleich, SBOM-Generierung während des Builds, warum SBOMs zur Build-Zeit und wie Sie in GitHub Actions eine SBOM erzeugen.
• Runner und CI/CD-Sicherheit: Anbieter von GitHub-Actions-Runnern, Tools für Runner-Sicherheit, Checkliste für CI/CD-Pipeline-Sicherheit und Egress-Richtlinie für GitHub Actions.
• Abhängigkeiten: SCA-Tools im Vergleich, transitive Abhängigkeiten erklärt und was Software Composition Analysis ist.
• Regulierung: Tools für CRA-Compliance.
• Warum der Build: warum Lieferkettensicherheit ins CI gehört, Software-Lieferkettensicherheit mit CRACI und warum auch interne Software und Software mit geringem Risiko sie braucht.

CRACI im Vergleich mit jedem Tool

• CRACI vs. Apiiro Risikograph aus dem Code vs. Nachweise aus dem Build.
• CRACI vs. Cycode ASPM plus Build-Agent vs. der Build-Runner selbst.
• CRACI vs. OX Security PBOM aus angebundenen Tools vs. eine Aufzeichnung aus dem Runner.
• CRACI vs. Legit Security Den SDLC absichern vs. den Build aufzeichnen.
• CRACI vs. Kusari Lieferketten-Graph vs. Build-SBOMs mit Überwachung.
• CRACI vs. ReversingLabs Binäranalyse des Ergebnisses vs. Nachweise aus dem Build.
• CRACI vs. Socket Analyse des Paketverhaltens vs. Beobachtung des Builds.
• CRACI vs. Chainguard Sichere Eingaben vs. ein sicherer, aufgezeichneter Build.
• CRACI vs. Xygeni AppSec-Plattform mit Build-Attestierungen vs. der Build-Runner selbst.
• CRACI vs. Wiz Befunde zur Workflow-Konfiguration vs. Durchsetzung im Job.
• CRACI vs. Safeguard Scans und KI-Autofix vs. Aufzeichnung des Builds selbst.

Software-Lieferkettensicherheit: FAQ

Kurze Antworten auf die häufigsten Fragen von Käufern

Was sind Lösungen für Software-Lieferkettensicherheit?

Tools, die alles schützen, was zwischen dem ersten Commit und dem Release in Ihre Software einfließt: Open-Source-Abhängigkeiten, Basis-Images, Build-Tools, CI-Pipelines und die Artefakte, die Sie ausliefern. Die wichtigsten Arten sind ASPM-Plattformen, die Risiken über den Entwicklungslebenszyklus abbilden, Software Composition Analysis für Abhängigkeiten, Build- und Runner-Sicherheit, Paket-Firewalls, gehärtete Images, Binäranalyse sowie SBOM- und Provenienz-Tools.

Was ist die beste Plattform für Software-Lieferkettensicherheit?

Die eine beste Plattform gibt es nicht, weil jede ein anderes Glied abdeckt. ASPM-Plattformen wie Apiiro, Cycode, OX Security und Legit Security sind am stärksten in der Breite über Repositories und CI-Systeme hinweg. Endor Labs konzentriert sich auf Erreichbarkeit bei Befunden zu Abhängigkeiten, Socket auf bösartige Pakete, Chainguard auf gehärtete Eingaben und ReversingLabs auf fertige Binaries. CRACI ist die Wahl, wenn Sie eine Aufzeichnung dessen brauchen, was jeder GitHub-Actions-Build tatsächlich geladen hat, mit Egress-Kontrolle und Provenienzdaten.

Worin unterscheidet sich Software-Lieferkettensicherheit von Anwendungssicherheit?

Anwendungssicherheit sucht mit Tools wie SAST und DAST nach Fehlern in dem Code, den Ihr Team schreibt. Software-Lieferkettensicherheit deckt ab, was diesen Code umgibt: Komponenten von Drittanbietern, das Build-System, die CI-Pipeline und den Weg vom Build zum Release. Die Hintertür in xz utils, die Kompromittierung von tj-actions/changed-files und der npm-Wurm Shai-Hulud kamen alle über die Lieferkette, nicht über einen Fehler im eigenen Code der Opfer.

Mit welchem Tool für Software-Lieferkettensicherheit sollte ich anfangen?

Beginnen Sie mit der Frage, die Sie heute nicht beantworten können. Wenn Sie nicht wissen, welche verwundbaren Abhängigkeiten Sie ausliefern, beginnen Sie mit SCA. Wenn bösartige Pakete Ihre größte Sorge sind, sehen Sie sich eine Paket-Firewall an. Wenn Sie belegen müssen, was in jedes Release eingeflossen ist, für Kunden oder für den EU Cyber Resilience Act, brauchen Sie eine während des Builds erstellte Aufzeichnung. Große Programme mit vielen Repositories und CI-Systemen ergänzen oft eine ASPM-Plattform.

Brauche ich für Software-Lieferkettensicherheit eine SBOM?

Zunehmend ja. Der EU Cyber Resilience Act verlangt von Herstellern, die Komponenten ihrer Produkte zu ermitteln, unter anderem durch Erstellung einer SBOM, und deren Schwachstellen zu behandeln. Die US-amerikanische FDA verlangt eine SBOM für Cyber Devices, und die US Executive Order 14028 prägte Leitlinien auf Bundesebene, die von Lieferanten eine SBOM fordern. Eine SBOM ist nur so nützlich, wie sie vollständig ist. Fragen Sie daher jeden Anbieter, woher seine Komponentenliste stammt und ob er Ihnen sagt, wann die Liste unvollständig ist.

Worin unterscheidet sich CRACI von einem Scanner für Lieferkettensicherheit?

Scanner lesen Dateien im Nachhinein: ein Manifest, ein Lockfile, Quellcode oder ein fertiges Binary. CRACI ist ein Rekorder. Es ist der Runner für Ihre GitHub-Actions-Jobs und zeichnet während jedes Jobs die Pakete auf, die der Job tatsächlich geladen hat, einschließlich der aus CI-Caches wiederhergestellten Pakete. Jede SBOM gibt ihre eigene Vollständigkeit an, eine Egress-Richtlinie steuert, was der Build erreichen kann, und die API liefert SBOMs, Netzwerk-Traces und Provenienz.

Welche CI-Systeme unterstützt CRACI?

Heute GitHub Actions; weitere CI-Systeme sind auf der Roadmap, darunter GitLab CI und Jenkins. Die Runner laufen unter Linux auf x86-64 und ARM64, Windows und macOS sind auf der Roadmap. Die meisten Plattformen auf dieser Seite decken mehrere CI-Systeme ab. Berücksichtigen Sie das, wenn Sie auch Jenkins oder Azure Pipelines nutzen.

Was kosten Tools für Software-Lieferkettensicherheit?

Die meisten rechnen pro Entwickler ab. Stand September 2026 kostet StepSecurity Enterprise $16 pro beitragendem Entwickler und Monat und Socket Team $25 pro Entwickler und Monat, während Cycode, OX Security und Endor Labs kostenpflichtige Pläne über den Vertrieb verkaufen. ReversingLabs Community+ kostet pauschal $500 pro Monat, Chainguard bietet bis zu fünf Images kostenlos an, und CRACI berechnet nur Build-Minuten, $0.002 pro vCPU-Minute ($0.004 für einen Standard-Runner mit 2 vCPU), ohne Monatsgebühr.