Ein dedizierter CI/CD-Security-Scanner. Statische Analyse auf den Workflow-Dateien in Ihrem Repo: Workflow Injection, ungepinnte Actions, überprivilegierte Tokens, OIDC-Drift. Erkannt, bevor irgendein Runner den Job aufnimmt.
Unsere Scanner parsen Ihre 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 Sie ${{ github.event.* }}, Branch-Namen, PR-Titel oder Issue-Bodies in einen `run:`-Block interpolieren, schleusen Sie Shell-Code in Ihre eigene Pipeline ein. Der Scanner markiert jeden nicht vertrauenswürdigen Input und folgt ihm durch jeden Step bis in die Shell, auch über Composite Actions hinweg.
@v3, @main, @latest, jede lose Ref ist ein kü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.
Standardmäßig hat das GITHUB_TOKEN `write`-Rechte auf fast alles. Wir erkennen nicht gesetzte `permissions:`, zu breite Scopes, die Sie gar nicht nutzen, 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, in Artefakte geloggte Secrets, in Container-Layer eingebackene Secrets. Statisch erkannt, bevor der Runner auch nur eine Zeile ausgibt.
Nicht vertrauenswürdige PRs, die in Caches schreiben, aus denen Protected Branches lesen. Wiederverwendung von Self-hosted Runnern ohne Isolation. Artefakt-Uploads aus nicht vertrauenswürdigen Kontexten. Die gesamte Klasse der Cache-Poisoning-CVEs der Jahre ab 2024.
Die meisten Pipeline-Incidents sind im YAML sichtbar. Wir lesen es so, wie ein Angreifer es liest, statisch und mit vollem Datenfluss-Kontext, damit das Finding im PR-Review landet und nicht im Post-Incident-Retro.
Workflow-Dateien bekommen dieselbe Sorgfalt wie Ihr Application-Code: AST-Parsing, Taint-Propagation, Source-to-Sink-Analyse. Das Bedrohungsmodell ist pipeline-spezifisch: nicht vertrauenswürdige Trigger, Action-Quellen, Token-Scopes, OIDC-Trust, Runner-Isolation.
First-Class-Parser für die CI-Dialekte, die heute die meisten Pipelines antreiben, inklusive Reusable Workflows, GitLab-`include:`-Ketten und Jenkinsfile (deklarativ und scripted Groovy). Neue Dialekte kommen auf Anfrage dazu.
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.
Verbinden Sie GitHub oder GitLab. Unsere Scanner ziehen die Pipeline-Dateien und laufen bei jedem Push (oder auf Anfrage). Nichts in Ihrem CI zu installieren, kein privilegierter Runner-Step. Findings fließen ins vereinheitlichte Dashboard und in Ihr PR-Review.
Alle Integrationen ansehenRichtig. Verbinden Sie das Repo ein einziges Mal. Unsere Scanner lesen .github/workflows, .gitlab-ci.yml, Jenkinsfile und den Rest direkt aus und melden Findings als Inline-Kommentare auf der betroffenen Zeile sowie im vereinheitlichten Dashboard. Kein Step, den Sie in Ihre Pipeline einbauen müssten, 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 gar nicht. Wir markieren jeden Wert, der aus `github.event.*`, `inputs.*`, `head_ref`, `pull_request.title/body` sowie Branch- und Tag-Refs aus einem Fork stammt, und folgen ihm über `env:`, `with:`, Output-Werte und Composite-Action-Grenzen hinweg. Erreicht der markierte Wert einen `run:`-Block, ein `eval` in JavaScript-Actions oder ein per Shell substituiertes Kommando, ist das ein Finding, ganz gleich, ob Sie bereits ausgenutzt wurden 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 werden separat markiert, denn selbst eine legitime Action wird zum Supply-Chain-Risiko, wenn Sie nicht auf einen SHA pinnen.
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 (in `ps` sichtbar), per `echo` geloggte Secrets und Secrets, die in Reusable-Workflow-Inputs eingebacken sind. Findings werden mit dem Secrets-Scanner dedupliziert, damit Sie sie nicht doppelt bekommen.
Ja. Wir parsen `runs-on:`-Direktiven, erkennen Runner mit geteiltem Filesystem-State über nicht vertrauenswürdige PRs hinweg, markieren fehlende Guards vom Typ `actions/cleanup` und warnen bei Jobs, die zu Root eskalieren oder den Docker-Socket einbinden.
Ein Befehl verdrahtet jeden Coding-Agenten auf Ihrem Rechner mit CybeDefend: Ihre Business Rules, Ihre Compliance-Frameworks und Guards, die destruktive Aufrufe blockieren, bevor sie ausgelöst werden.
npx -y @cybedefend/vibedefend@latest install
Claude Code
Cursor
OpenAI Codex
Windsurf
VS Code Copilot