CI/CD-Sicherheitstools: Runner und Builds im Vergleich

Jeder Vergleich zeigt, was das andere Produkt gut macht, wo CRACI sich unterscheidet und wann Sie beide einsetzen würden. Alle Kategorien finden Sie unter alle Vergleiche.

Warum die Pipeline eigene Sicherheitstools braucht

Eine CI/CD-Pipeline enthält Zugangsdaten, lädt Code aus dem Internet und erzeugt die Artefakte, die Ihre Kunden ausführen. Das macht sie zu einem eigenständigen Angriffsziel. Ein Angreifer, der ändern kann, was ein Build herunterlädt oder was er erzeugt, muss Ihren Quellcode gar nicht anfassen. Dafür wurden Code-Scanner nicht gebaut, denn sie lesen das Repository, nicht den Build.

CI/CD-Sicherheitstools schließen diese Lücke aus verschiedenen Richtungen. Manche prüfen, wie die Pipeline konfiguriert ist, manche beobachten, was auf dem Runner passiert, während ein Job läuft, und manche kontrollieren den Runner selbst. Zu wissen, zu welcher Gruppe ein Tool gehört, sagt mehr aus als seine Funktionsliste, denn das entscheidet, was das Tool sehen und was es stoppen kann.

Arten von CI/CD-Sicherheitstools

Scanner, die Ihren Code lesen

Statische Analyse (SAST), Secret Scanning und Software Composition Analysis (SCA) lesen das Repository: Quelldateien, Manifeste und Lockfiles. GitHub Advanced Security etwa kombiniert CodeQL Code Scanning mit Secret Scanning und Push Protection sowie Dependabot-Warnungen aus der GitHub Advisory Database. Diese Tools finden Probleme, bevor ein Build läuft. Was der Build tatsächlich geladen hat oder womit er sich verbunden hat, sehen sie nicht.

Tools, die die Pipeline rund um den Build härten

Posture- und Governance-Tools prüfen die Konfiguration der Pipeline. Cycode überwacht CI/CD-Sicherheitsrichtlinien, Konfigurationen und Governance. StepSecurity führt ein Inventar der von Ihnen genutzten Drittanbieter-Actions, mit Freigabe-Workflows für neue, und öffnet Pull Requests, die Actions auf Commit-SHAs pinnen und GITHUB_TOKEN-Berechtigungen nach dem Prinzip der geringsten Rechte setzen. Diese Tools erschweren den Missbrauch der Pipeline, arbeiten aber an der Definition des Builds statt am laufenden Build.

Agenten, die den Runner überwachen

Runtime-Agenten laufen innerhalb des Jobs auf Runnern, die Sie behalten. StepSecurity Harden-Runner überwacht ausgehende Verbindungen, Prozesse und Dateischreibvorgänge, ordnet jeden dem verursachenden Workflow-Schritt zu und kann Egress außerhalb einer Allowlist blockieren. Cimon von Cycode überwacht Prozessausführung, Netzwerk-Egress und Dateizugriffe auf Kernel-Ebene mit eBPF, erzeugt eine zur Laufzeit beobachtete SBOM und signiert SLSA-Provenienz. Agenten funktionieren über viele CI-Systeme hinweg und auf gehosteten Runnern, weil sie zu bestehender Infrastruktur hinzugefügt werden.

Runner, die den Build kontrollieren und aufzeichnen

CRACI verfolgt den letzten Ansatz: Es ersetzt den Runner. Jobs laufen mit runs-on: craci auf CRACI, und die Läufe erscheinen weiterhin in GitHub. Die Egress-Richtlinie ist Teil des Runners, wird vor dem Jobstart validiert und ist fail closed. Ein paketbewusster Proxy zeichnet jedes Paket auf, das der Job geladen hat, einschließlich der aus CI-Caches wiederhergestellten Pakete, sodass jeder Job eine SBOM mit Vollständigkeitsstatus, einen Netzwerk-Trace und Provenienzdaten erzeugt.

Direkter Vergleich

CI/CD-Sicherheitstools im Vergleich, Stand September 2026
Funktion	CRACI	StepSecurity Harden-Runner	Cycode (Cimon)	GitHub Advanced Security
Wo es läuft	Es ist der Runner	Agent auf Runnern, die Sie behalten	Agent in Ihrem bestehenden CI	Scannt Repositories auf GitHub
Egress-Kontrolle im Build	Standardmäßig Deny oder Allow, blockiert im Zweifel	Allowlist im Block-Modus	Prevent-Modus mit erlaubten Hosts
Audit-Modus vor dem Blockieren	Monitor- oder Dry-Run-Modus	Baselines pro Job	Detect-Modus	Keine Egress-Kontrolle
Prozess- und Dateiüberwachung			eBPF	Keine Angabe
SBOM aus dem Build aufgezeichnet	Pro Job, mit Vollständigkeitsstatus	Zeichnet Ziele, Prozesse und Dateien auf	Zur Laufzeit beobachtete SBOM	Graph aus Manifesten plus übermittelte Build-Daten
Signierte Build-Provenienz	Keine signierte Provenienz	Keine Angabe	SLSA Provenance v1.0	Artefakt-Attestierungen
SAST		Keine Angabe		CodeQL
Secret Scanning		Keine Angabe		Secret Protection
CI-Abdeckung	Heute GitHub Actions; GitLab CI und Jenkins auf der Roadmap	GitHub Actions, GitLab CI, Azure DevOps	GitHub Actions, Azure Pipelines, Jenkins, GitLab CI, Buildkite, Harness	GitHub, und Azure DevOps als separater Kauf

Enthalten
Teilweise
Nicht enthalten
Auf der Roadmap

„Keine Angabe“ bedeutet, dass wir es auf den öffentlichen Seiten des Anbieters nicht bestätigen konnten. Die Details hinter jeder Spalte finden Sie unter CRACI vs. StepSecurity, CRACI vs. Cycode und CRACI vs. GitHub Advanced Security.

Welches Tool welches CI/CD-Risiko abdeckt

Die OWASP Top 10 CI/CD Security Risks sind die am weitesten verbreitete Liste dessen, was in einer Pipeline schiefgehen kann. Ihre zehn Risiken lauten:

CICD-SEC-1: Insufficient Flow Control Mechanisms
CICD-SEC-2: Inadequate Identity and Access Management
CICD-SEC-3: Dependency Chain Abuse
CICD-SEC-4: Poisoned Pipeline Execution (PPE)
CICD-SEC-5: Insufficient PBAC (Pipeline-Based Access Controls)
CICD-SEC-6: Insufficient Credential Hygiene
CICD-SEC-7: Insecure System Configuration
CICD-SEC-8: Ungoverned Usage of 3rd Party Services
CICD-SEC-9: Improper Artifact Integrity Validation
CICD-SEC-10: Insufficient Logging and Visibility

Kein einzelnes Tool deckt alle zehn ab. Dies sind die vier, bei denen die Kontrollen von CRACI greifen:

OWASP-CI/CD-Risiken, die CRACI adressiert
Funktion	Worum es bei dem Risiko geht	Was CRACI tut
CICD-SEC-3: Dependency Chain Abuse	Ein Build lädt ein bösartiges oder unerwartetes Paket	Die Egress-Richtlinie begrenzt die Quellen, aus denen ein Job laden kann, und die SBOM des Jobs zeichnet jedes geladene Paket auf
CICD-SEC-7: Insecure System Configuration	Schwache Einstellungen in den Systemen, die die Pipeline ausführen	Jobs laufen in isolierten virtuellen Maschinen, und eine Richtlinie, die sich nicht anwenden lässt, ist fail closed
CICD-SEC-9: Improper Artifact Integrity Validation	Ein manipuliertes Artefakt durchläuft die Pipeline, als wäre es legitim	Keine signierte Provenienz; die API liefert Provenienzdaten für jeden Build
CICD-SEC-10: Insufficient Logging and Visibility	Angriffe in der Pipeline bleiben unbemerkt und lassen sich nicht untersuchen	Ein Netzwerk-Trace für jeden Job, Warnungen bei Richtlinienverstößen und eine API, die SBOMs, Netzwerk-Traces und Provenienz liefert

Bei CICD-SEC-7 deckt CRACI den Runner ab. Die Konfiguration Ihrer Repositories und Ihrer GitHub-Organisation bleibt bei Ihnen. Klar gesagt zum Rest: CRACI adressiert weder Identitäts- und Zugriffsmanagement (CICD-SEC-2) noch Credential-Hygiene (CICD-SEC-6) und steuert weder Flow Control noch Pipeline-Berechtigungen oder Drittanbieterdienste (CICD-SEC-1, 5 und 8). Dafür sind Secret Scanning, etwa Secret Protection von GitHub oder die Secrets-Erkennung von Cycode, und die oben genannten Posture-Tools gebaut.

So wählen Sie ein CI/CD-Sicherheitstool

Runner ersetzen oder behalten. Wenn Sie GitHub-gehostete Runner, selbst gehostete Runner oder ein anderes CI-System behalten möchten, sind Runtime-Kontrollen über einen Agenten der richtige Weg. Wenn Sie offen dafür sind, den Runner zu wechseln, bringt ein Runner wie CRACI Egress-Kontrolle und eine Aufzeichnung des Builds mit, ohne dass ein Agent ausgerollt werden muss.
Audit-Modus heute. Harden-Runner und Cimon können den Datenverkehr beobachten, bevor sie etwas blockieren. CRACIs Monitor- oder Dry-Run-Modus steht auf der Roadmap.
Forensik auf Prozessebene. Wenn Sie bei einem Vorfall wissen müssen, welcher Prozess welche Datei geschrieben hat, deckt das ein Agent ab, der Prozesse und Dateien überwacht. CRACI überwacht weder Prozesse noch Dateischreibvorgänge.
SBOM und CRA-Nachweise. Wenn Sie eine SBOM auf Paketebene für jeden Build, Provenienz und Nachweise für den Cyber Resilience Act brauchen, prüfen Sie, was jedes Tool aufzeichnet und ob es das Ausgelieferte weiter überwacht. CRACI zeichnet die SBOM auf, während der Build läuft, bewertet überwachte SBOMs neu, sobald neue Schwachstellen auftauchen, und exportiert SBOMs als CycloneDX oder SPDX.
CI-Plattformen und Betriebssysteme. CRACI unterstützt heute GitHub Actions (GitLab CI und Jenkins sind auf der Roadmap) und läuft auf Linux mit x86-64 und ARM64 (Windows und macOS sind auf der Roadmap). Wenn Sie auf anderen CI-Systemen bauen oder jetzt Windows- oder macOS-Runner brauchen, prüfen Sie zuerst die Agenten-Abdeckung.
Code und Secrets. Scanner für Quellcode und Secrets decken Bereiche ab, die kein Runner abdeckt. CRACI bietet weder SAST noch Secret Scanning, planen Sie diese also separat ein.

Ein Agent auf dem Runner oder selbst der Runner

Ein Agent wird zu einer Infrastruktur hinzugefügt, die jemand anderes entworfen hat. Auf GitHub-gehosteten Runnern wird er durch einen Schritt am Anfang jedes Jobs installiert, und seine Reichweite hängt davon ab, was diese Infrastruktur erlaubt. Dadurch können Agenten gehostete Runner, selbst gehostete Flotten und mehrere CI-Systeme gleichzeitig abdecken, und das ist ein echter Vorteil, wenn Ihre Builds über all diese verteilt sind.

Ein Runner, der Richtlinien selbst durchsetzt, funktioniert umgekehrt. Bei CRACI wird die Egress-Richtlinie vor dem Jobstart validiert, lehnt unbekannte Felder ab und ist fail closed, sodass eine Richtlinie, die sich nicht anwenden lässt, keinen ungeschützten Lauf erzeugt. Ihre Quellen sind nach Ökosystem typisiert, mit 24 integrierten Presets für Softwarequellen und benutzerdefinierten Quellen für npm, PyPI, apt, apk, den Go-Proxy, Nix, Cargo, OCI-Registries und Git, die Aufzeichnung erfasst also Pakete, nicht nur Hosts. Bei Jobs, die auf CRACI laufen, ersetzt es Runtime-Agenten, statt neben ihnen zu laufen. Lesen Sie mehr über CI/CD-Integration und SBOM-Generierung während des Builds, oder buchen Sie eine Demo, um einen GitHub-Actions-Job unter einer Egress-Richtlinie zu sehen.

CRACI im Vergleich mit jedem Tool

CRACI vs. StepSecurity Ein Agent auf Ihrem Runner vs. der Runner selbst.

Im direkten Vergleich

Mehrere Tools auf einer Seite, wenn Sie eine Kategorie wählen und nicht ein einzelnes Produkt.

Tools für Software-Lieferkettensicherheit im Vergleich Apiiro, Cycode, OX, Legit, Socket, Chainguard, StepSecurity und weitere.

CI/CD-Sicherheitstools: Antworten

Was sind CI/CD-Sicherheitstools?

CI/CD-Sicherheitstools schützen die Pipeline, die aus Quellcode ausgelieferte Software macht. Sie lassen sich in vier Gruppen einteilen: Scanner, die Ihren Code und Ihre Abhängigkeiten lesen (SAST, Secret Scanning, SCA), Tools, die die Pipeline-Konfiguration rund um den Build härten, Agenten, die den Runner überwachen, während ein Job läuft, und Runner, die den Build selbst kontrollieren und aufzeichnen. Die OWASP Top 10 CI/CD Security Risks sind ein gängiger Weg, um zu prüfen, welche Risiken ein Tool adressiert.

Was ist der Unterschied zwischen CI/CD-Sicherheit und SCA?

Software Composition Analysis (SCA) liest Ihre Manifeste und Lockfiles und sagt Ihnen, welche deklarierten Abhängigkeiten bekannte Schwachstellen haben. CI/CD-Sicherheit schützt die Pipeline selbst: wer sie ändern kann, was ein Build erreichen kann und ob das Artefakt, das Sie ausliefern, dasjenige ist, das gebaut wurde. CRACI arbeitet vom Build aus: Es zeichnet die Pakete auf, die jeder Job tatsächlich geladen hat, einschließlich der aus CI-Caches wiederhergestellten Pakete, und überwacht sie nach dem Release weiter auf neue Schwachstellen.

Brauche ich einen Runtime-Agenten, wenn ich CRACI nutze?

Nicht für die Egress-Kontrolle oder eine Aufzeichnung des Builds. Bei CRACI ist die Egress-Richtlinie Teil des Runners, wird vor dem Jobstart validiert und ist fail closed, sodass CRACI Agenten wie Harden-Runner und Cimon bei den Jobs ersetzt, die darauf laufen. Was Sie aufgeben, sind die Prozess- und Dateiüberwachung, die CRACI nicht bietet, und der Audit-Modus, der auf CRACIs Roadmap steht. Wenn Forensik auf Prozessebene eine harte Anforderung ist, deckt ein Runner-Agent auf Runnern, die Sie behalten, das heute ab.

Können CI/CD-Sicherheitstools bösartige Pakete blockieren?

Manche können es, auf unterschiedliche Weise. Egress-Kontrolle hindert einen Build daran, Quellen außerhalb einer Richtlinie zu erreichen, ein Download von einem unerwarteten Host schlägt also fehl. Paket-Blocklists und Registry-Kontrollen verhindern, dass eine bekannte schädliche Version überhaupt installiert wird. CRACI setzt heute eine Egress-Richtlinie pro Job durch, mit nach Ökosystem typisierten Quellen; organisationsweite Paket-Blocklists stehen auf CRACIs Roadmap.

Welche CI/CD-Sicherheitstools funktionieren über GitHub Actions hinaus?

Stand September 2026 listet StepSecurity neben GitHub Actions auch GitLab CI und Azure DevOps, und Cimon von Cycode läuft außerdem auf Azure Pipelines, Jenkins, GitLab CI, Buildkite und Harness. GitHub Advanced Security wird auch für Azure DevOps verkauft. CRACI unterstützt heute GitHub Actions; GitLab CI und Jenkins sind auf der Roadmap.

CI/CD-Sicherheitstools im Vergleich