Code-to-Cloud-Versicherung.

VibeDefend

Lernt die Regeln Ihres Projekts, prüft jeden Prompt und sorgt dafür, dass der Agent von Anfang an sicheren Code schreibt.

VibeDefend entdecken

KI-Agenten

Scanner

Governance

Vollständige Plattform ansehen

Entwickler

Ressourcen

Forschung

Ihre Pipelines sind Code. Also lesen wir sie.

Statische Analyse Ihrer Workflow-Dateien. Injection, ungepinnte Actions, überprivilegierte Tokens, OIDC-Drift.

30-Minuten-Demo buchen

Commita3f9c2e · release.yml

Build#4821 · #4822

CybeDefend-Gaterelease.yml read

Deployprod-eu

blockiertpull_request_target · contents: writeausgerolltuses: @7a3c…e4f · contents: read

Commita3f9c2e · release.yml

Build#4821 · #4822

CybeDefend-Gaterelease.yml read

Deployprod-eu

blockiertpull_request_target · contents: writeausgerolltuses: @7a3c…e4f · contents: read

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.

Sechs Fehler,
direkt in der Datei.

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

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.

permissions: write-all

permissions:

contents: read

id-token: write

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

runs-on: self-hosted

runs-on: ubuntu-24.04

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

uses: actions/checkout@v3

uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2

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

role/deploy › trust policy › sub

repo:acme/*

repo:acme/api:environment:production

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.

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

env:

TITLE: ${{ github.event.pull_request.title }}

run: echo "$TITLE"

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

run: ./publish.sh ${{ secrets.NPM_TOKEN }}

env:

NPM_TOKEN: ${{ secrets.NPM_TOKEN }}

run: ./publish.sh

Zeigen Sie auf eine markierte Zeile, um den Fix zu sehen.Tippen Sie auf eine Notiz, um den Fix zu sehen.

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.

.github/workflows/release.yml:12source
message: ${{ github.event.pull_request.title }}
.github/workflows/notify.yml:4hop
message: { type: string }
.github/workflows/notify.yml:10sink
run: echo "${{ inputs.message }}"

cybedefendcommented onnotify.yml:10

pull_request.title reaches run: through inputs.message.

run: echo "${{ inputs.message }}"

env: { MSG: "${{ inputs.message }}" }

run: echo "$MSG"

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

Repo verbinden,
der Rest läuft automatisch.

Verbinden Sie GitHub oder GitLab. Ihre Pipeline-Dateien werden bei jedem Push oder auf Abruf gelesen.

.github/workflows/ci.yml

on: pushjobs:  test:    runs-on: ubuntu-24.04    steps:      - run: npm test