Live-Webinar auf EnglischWebinar mit Jason Lee, Mi., 14. Okt.Your newest insider is an AI agent.Jason LeeFormer CISO, Zoom & SplunkAnmelden

Ihre Pipelines sind Code. Also lesen wir sie.

Ihre Workflow-Dateien, gelesen wie Code: Injection, ungepinnte Actions, Tokens und Vertrauen, jeweils mit Fix.

Cloud testenVibeDefend ansehen
checkout-apiCI/CDDemo-Projekt
  • KritischWorkflow-Injectionrelease.yml:24

    Der Pull-Request-Titel erreicht run: in der Shell.

    run: echo "${{ github.event.pull_request.title }}"env:  TITLE: ${{ github.event.pull_request.title }}run: echo "$TITLE"

    Fix bereitDer Titel wandert in eine Umgebungsvariable, raus aus der Shell.

Pipeline-Schwachstellen, in der Datei gefunden.

  • Workflow-Injection

    • ${{ github.event.pull_request.title }}

  • Ungepinnte Actions

    • actions/checkout@v3
    • actions/setup-node@main

  • Überprivilegierte Tokens

    • permissions: write-all

  • OIDC-Vertrauen

    • "sub": "repo:acme/*"

Die Injection, im Workflow behoben.

Wie geschrieben

run: echo "${{ github.event.pull_request.title }}"

Der Pull-Request-Titel erreicht run: in der Shell.

Mit dem Fix

env:  TITLE: ${{ github.event.pull_request.title }}run: echo "$TITLE"

Der Titel wandert in eine Umgebungsvariable, raus aus der Shell.

Von Ihrem Agenten behoben, in der Sitzung.

Ihr Agent liest diese Funde beim Schreiben und behebt sie in derselben Sitzung.

VibeDefend ansehen
  1. CI/CDScannt das Repository bei jedem Push.Gefunden
  2. VibeDefendGibt das Finding an Ihren Coding-Agenten.Bereitgestellt
  3. Ihr AgentBehebt es in der Sitzung.Behoben
  4. CommitGeht ohne die Lücke rein.Sauber
  • Claude Code
  • Cursor
  • Windsurf
  • GitHub Copilot
  • OpenAI Codex

Beginnen Sie mit einem Repository.

Verbinden Sie GitHub, GitLab, Bitbucket oder Azure DevOps, wählen Sie ein Repository, und der erste Scan startet.

Cloud testenDemo buchen

Im Detail

Sechs Pipeline-Lücken, in der Datei gefunden.

  • Workflow-Injection

    Event-Daten, Branch-Namen oder Pull-Request-Titel, die einen run:-Block erreichen.

    CWE-77, CWE-78

  • Ungepinnte Actions

    @v3, @main, @latest: Jede bewegliche Referenz ist ein künftiger Supply-Chain-Vorfall.

  • Überprivilegierte Tokens

    Kein permissions:-Block oder Schreibrechte, die ein Job nie nutzt.

  • OIDC-Vertrauen

    Föderierte Identität von GitHub, GitLab oder CircleCI zu AWS, Azure und GCP, zu weit gefasst.

  • Secret-Lecks

    echo $SECRET, Secrets als Argumente, liegen gelassen in Artefakten oder Image-Schichten.

  • Cache- und Artefakt-Vergiftung

    Nicht vertrauenswürdige Pull Requests schreiben in Caches, die geschützte Branches lesen.

Alles, was er prüft

Misconfig abfangen, bevor der Runner läuft.

Die meisten Pipeline-Vorfälle stehen schon im YAML. Wir lesen es so, wie ein Angreifer es liest.

  • Pipelines als vollwertiges Asset

    Workflow-Dateien werden so gründlich geprüft wie Ihr Anwendungscode: AST-Parsing, Taint-Propagation, Source-to-Sink-Analyse.

  • GitHub Actions, GitLab CI, Jenkinsfile

    Vollwertige Parser für die CI-Dialekte, in denen heute die meisten Pipelines laufen, inklusive Reusable Workflows, include:-Ketten in GitLab und Jenkinsfiles (deklaratives und geskriptetes Groovy).

  • Findings direkt im PR

    Jedes Finding erscheint als Inline-Kommentar an der betroffenen YAML-Zeile, genau wie bei SAST.

Sechs Fehler, direkt in der Datei.

Wir überführen Ihre Workflows in einen AST und einen Datenflussgraphen und wenden dann unsere eigenen Regelpakete an.

  • Workflow Injection (CWE-77 / 78)

    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.

  • Ungepinnte und ungeprüfte Actions

    @v3, @main, @latest: Jede nicht fixierte Referenz ist ein künftiger Supply-Chain-Vorfall.

  • Überprivilegierte Tokens

    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.

  • Fehlkonfigurierter OIDC-Trust

    Föderierte Identitäten für AWS, Azure und GCP aus GitHub, GitLab und CircleCI.

  • Muster für Secret-Lecks

    echo $SECRET, Secrets als Positionsargumente, in Artefakte geloggte Secrets, in Container-Layer eingebaute Secrets.

  • Cache- und Artefakt-Poisoning

    Nicht vertrauenswürdige PRs, die in Caches schreiben, aus denen geschützte Branches lesen. Selbst gehostete Runner, die ohne Isolation wiederverwendet werden.

Vom YAML zur Korrektur

  • Das YAML ist unsicher.

    Unsicherer Trigger, Schreibrechte, Action ungepinnt.

  • Beurteilt vor dem Lauf.

    Statisch, direkt in der Datei, ohne Pipeline.

  • Gepinnt und begrenzt.

    SHA gepinnt, nur Leserechte, Eingaben isoliert.

Repo verbinden, der Rest läuft automatisch.

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.

Sechs CI-Dialekte speisen einen Parser: GitHub Actions, GitLab CI, Bitbucket, Azure DevOps, Jenkins, CircleCI.

Commit a3f9c2e ändert release.yml. Der Build startet zwei Runs: #4821 und #4822.

Am Gate wird release.yml so gelesen, wie ein Angreifer es lesen würde: Trigger, Permissions, jedes uses: und run:.

#4821 ist blockiert: pull_request_target mit contents: write und eine ungepinnte Action erreichen den Deploy-Job nie.

#4822 geht nach prod-eu: gepinnter SHA, Read-only-Token, der PR-Titel bleibt außerhalb der Shell.

Häufige Fragen zum CI/CD-Scanner.

Scannt CybeDefend meine Pipeline-Dateien von außen, ohne eigenen Step in der Pipeline?
Richtig. 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. Sie müssen weder einen Step in Ihre Pipeline einbauen noch einen privilegierten Runner installieren.
Welche Pipeline-Formate kann CybeDefend lesen?
GitHub-Actions-Workflows (inklusive Composite und Reusable Workflows), GitLab-CI-YAML (inklusive `include:`-Ketten) und Jenkinsfiles (deklaratives und geskriptetes Groovy). Auch Action-Definitionen (action.yml und Dockerfile-basierte Actions) werden gelesen, damit Taint-Flows über Action-Grenzen hinweg verfolgt werden. Weitere Dialekte kommen auf Kundenwunsch dazu.
Wie erkennt CybeDefend eine Workflow Injection, die nur bei bestimmten Event-Payloads auslöst?
Den Payload brauchen wir gar nicht. Wir markieren jeden Wert, der aus `github.event.*`, `inputs.*`, `head_ref`, `pull_request.title/body` sowie aus Branch- und Tag-Refs eines Forks stammt, und folgen ihm über `env:`, `with:`, Output-Werte und Grenzen von Composite Actions hinweg. Erreicht der markierte Wert einen `run:`-Block, ein `eval` in einer JavaScript-Action oder einen Befehl mit Shell-Substitution, ist das ein Finding, ganz gleich, ob die Lücke schon ausgenutzt wurde.
Erkennt CybeDefend schädliche GitHub Actions oder Typosquatting?
Ja. Jeder `uses:`-Eintrag wird mit dem OpenSSF-Feed schädlicher Actions, der Liste verifizierter Publisher und unseren eigenen Typosquatting-Heuristiken für Action-Namen abgeglichen. Ungepinnte Tags werden separat markiert, denn selbst eine legitime Action wird zum Supply-Chain-Risiko, wenn Sie sie nicht auf einen SHA pinnen.
Was ist mit Secrets in Workflow-Dateien?
Alles, was den Entropie- und Provider-Mustern unseres Secret-Detection-Regelpakets entspricht, wird auch in CI/CD-Dateien markiert. Außerdem erkennen wir Secrets, die als Positionsargumente an die CLI übergeben werden (in `ps` sichtbar), per `echo` geloggte Secrets und Secrets, die fest in Inputs von Reusable Workflows stehen. Die Findings werden mit dem Secrets-Scanner abgeglichen, damit Sie sie nicht doppelt sehen.
Scannt CybeDefend auch Konfigurationen selbst gehosteter Runner?
Ja. Wir werten `runs-on:`-Direktiven aus, erkennen Runner, deren Dateisystem zwischen nicht vertrauenswürdigen PRs geteilt wird, markieren fehlende Schutzmaßnahmen wie `actions/cleanup` und warnen bei Jobs, die Root-Rechte erlangen oder den Docker-Socket einbinden.