Ein dedizierter CI/CD-Security-Scanner. Statische Analyse auf den Workflow-Dateien in deinem Repo: Workflow Injection, ungepinnte Actions, überprivilegierte Tokens, OIDC-Drift. Gefangen, bevor irgendein Runner den Job aufnimmt.
Unsere Scanner parsen deine Pipeline-Configs in einen AST und einen Datenfluss-Graphen, dann fahren proprietäre Rule Packs, gespeist von OpenSSF Secure Workflows, StepSecurity-Playbooks und unserer eigenen Research zu echten Poisoning-Incidents. Findings fließen ins vereinheitlichte Dashboard neben SAST, SCA, IaC, Secrets und Container.
Jedes Mal, wenn du ${{ github.event.* }}, Branch-Namen, PR-Titel oder Issue-Bodies in einen `run:`-Block interpolierst, injizierst du Shell in deine eigene Pipeline. Der Scanner taintet jeden untrusted Input und folgt ihm durch jeden Step bis zum Shell, auch über Composite Actions hinweg.
@v3, @main, @latest, jede floating Ref ist ein zukünftiger Supply-Chain-Incident. Der Scanner markiert jede Action, die nicht auf einen vollen SHA gepinnt ist, jede Action von einem unverifizierten Publisher und gleicht sie mit dem Malicious-Action-Feed ab.
Default-GITHUB_TOKEN-Scopes sind `write` auf fast alles. Wir erkennen ungesetzte `permissions:`, breite Scopes, die du nicht nutzt, und empfehlen das minimale Set pro Job.
AWS-, Azure- und GCP-Federated-Identity aus GitHub, GitLab und CircleCI. Wir fangen zu breite `sub`-Patterns, fehlende Audience-Checks und Trust Policies, die jeder Fork annehmen kann.
`echo $SECRET`, Secrets als Positional Args, Secrets in Artefakte geloggt, Secrets in Container-Layer eingebacken. Statisch erkannt, bevor der Runner eine einzige Zeile ausgibt.
Untrusted PRs, die in Caches schreiben, aus denen Protected Branches lesen. Self-hosted Runner-Reuse ohne Isolation. Artefakt-Uploads aus untrusted Contexts. Die ganze Klasse von Cache-Poisoning-CVEs nach 2024.
Die meisten Pipeline-Incidents sind im YAML sichtbar. Wir lesen es, wie ein Angreifer es liest, statisch, mit vollem Datenfluss-Kontext, damit das Finding im PR-Review landet und nicht im Post-Incident-Retro.
Workflow-Dateien bekommen dieselbe Genauigkeit wie dein Application-Code: AST-Parsing, Taint-Propagation, Source-to-Sink-Analyse. Das Threat-Model ist Pipeline-spezifisch: untrusted Trigger, Action-Quellen, Token-Scopes, OIDC-Trust, Runner-Isolation.
First-Class-Parser für die CI-Dialekte, die heute die meisten Pipelines shippen, inklusive Reusable Workflows, GitLab-`include:`-Ketten und Jenkinsfile (deklarativ und scripted Groovy). Neue Dialekte shippen auf Anfrage.
Jedes Finding landet als Inline-Kommentar auf der betroffenen YAML-Zeile, dieselbe Oberfläche wie SAST. Kein neues Dashboard zu lernen, keine separate Triage-Queue, kein privilegierter Runner-Step zu installieren.
Verbinde GitHub oder GitLab. Unsere Scanner ziehen die Pipeline-Dateien und laufen bei jedem Push (oder auf Anfrage). Nichts in deinem CI zu installieren, kein privilegierter Runner-Step. Findings fließen ins vereinheitlichte Dashboard und in dein PR-Review.
Alle Integrationen ansehenRichtig. Verbinde das Repo einmal. Unsere Scanner lesen .github/workflows, .gitlab-ci.yml, Jenkinsfile und den Rest direkt, dann melden sie Findings als Inline-Kommentare auf der betroffenen Zeile und im vereinheitlichten Dashboard. Kein Step in deine Pipeline einzubauen, kein privilegierter Runner zu installieren.
GitHub-Actions-Workflows (inklusive Composite und Reusable Workflows), GitLab-CI-YAML (inklusive `include:`-Ketten) und Jenkinsfile (deklarativ und scripted Groovy). Action-Definitions (action.yml plus Dockerfile-Action-Wrapper) werden ebenfalls gelesen, sodass cross-action Taint-Flows getrackt werden. Weitere Dialekte kommen auf Kundenwunsch dazu.
Wir brauchen das Payload nicht. Wir tainten jeden Wert, der aus `github.event.*`, `inputs.*`, `head_ref`, `pull_request.title/body`, Branch- und Tag-Refs aus einem Fork kommt, und folgen ihm über `env:`, `with:`, Output-Werte und Composite-Action-Grenzen hinweg. Wenn der getaintete Wert einen `run:`-Block, ein `eval` in JavaScript-Actions oder ein Shell-substituiertes Kommando erreicht, ist das ein Finding, egal ob du schon ausgenutzt wurdest oder nicht.
Ja. Jeder `uses:`-Eintrag wird gegen den OpenSSF-Malicious-Action-Feed, die Verified-Publisher-Liste und unsere eigenen Typo-Squat-Heuristiken auf Action-Namen abgeglichen. Ungepinnte Tags markieren separat, denn selbst eine legitime Action wird zum Supply-Chain-Risiko, wenn du nicht auf einen SHA pinnst.
Alles, was den Entropy- und Provider-Patterns aus unserem Secret-Detection-Rule-Pack entspricht, wird auch in CI/CD-Dateien markiert. Wir erkennen außerdem Secrets, die als Positional-CLI-Args übergeben werden (sichtbar in `ps`), Secrets, die per `echo` geloggt werden, und Secrets, die in Reusable-Workflow-Inputs eingebacken sind. Findings dedupen sich mit dem Secrets-Scanner, damit du sie nicht doppelt bekommst.
Ja. Wir parsen `runs-on:`-Direktiven, erkennen Runner mit geteiltem Filesystem-State über untrusted PRs hinweg, markieren fehlende `actions/cleanup`-artige Guards und warnen bei Jobs, die zu Root eskalieren oder den Docker-Socket mounten.
Keine Kreditkarte. Kein Setup-Call. Wähle deinen Agent, kopiere den Befehl, und Cybe setzt deine Regeln ab dem nächsten Prompt durch.
claude mcp add cybedefend --transport http https://mcp-eu.cybedefend.com/mcpGehostetes MCP, keine Installation. Einfach die URL bei deinem Agent registrieren.