Zwei getrennte Regelsätze, nicht einer
Das ist das Detail, das die meisten Vergleiche auslassen: Dockerfile-Hygiene und CI/CD-Pipeline-Sicherheit sind zwei unterschiedliche Regelkategorien mit unterschiedlichem Standardzustand. Das falsch zu verstehen bedeutet entweder, eine Abdeckung zu verpassen, die man für gegeben hielt, oder überrascht zu sein, dass ein Scan etwas nicht gemeldet hat.
Dockerfile-Hygiene — standardmäßig aktiv
Allgemeine Dockerfile-Regeln liegen unter der Kategorie SECURITY, in jedem Scan ohne Konfiguration aktiviert:
| Regel | Schweregrad | Was erkannt wird |
|---|---|---|
| dockerfile_root_user | HIGH | Keine USER-Direktive — der Container läuft standardmäßig als Root. |
| dockerfile_copy_all | MEDIUM | COPY . . zieht den gesamten Build-Kontext ins Image, einschließlich .env, Credentials, SSH-Schlüssel. |
| dockerfile_unpinned_base | MEDIUM | Basis-Image nicht auf eine bestimmte Version fixiert. |
CI/CD-Pipeline-Regeln — optional, standardmäßig aus
Das ist der Punkt, den man präzise formulieren sollte: die 38 Regeln, die den Inhalt von .github/workflows/*.yml und .gitlab-ci.yml prüfen — Expression-Injection, Berechtigungs-Scoping, nicht fixierte Actions, und die Regel unten — sind unter einer separaten CICD-Kategorie gruppiert, die standardmäßig deaktiviert ist, genau wie das Dependency-Scanning --with-deps benötigt. Dafür gibt es kein CLI-Flag; es ist eine Konfigurationseinstellung.
Aktivieren in audit.config.json:
"categories": {
"cicd": { "enabled": true, "weight": 2 }
}Vor dem ersten Scan eines Projekts setzen (oder den Regel-Cache mit --no-cache einmal leeren, wenn Sie es bei einem bereits gescannten Projekt umschalten) — dann normal ausführen.
| Regel | Schweregrad | Was erkannt wird |
|---|---|---|
| pull_request_target_checkout | HIGH | pull_request_target kombiniert mit einem Checkout des Fork-Heads — erlaubt einem geforkten PR, Code mit Schreibzugriff und Secrets-Zugang auszuführen. |
| unpinned_action_version | MEDIUM | Eine Action, referenziert über Branch oder Tag (@main, @v4) statt eines vollständigen Commit-SHA. |
| gha_missing_permissions | LOW | Workflow hat keinen expliziten permissions:-Block, fällt auf breiteren Zugriff als nötig zurück. |
| docker_latest_tag | LOW | Ein image:-Schlüssel in CI-YAML, fixiert auf :latest — Hinweis: dies erfasst den YAML-Schlüssel image:/from:, nicht eine Dockerfile-FROM-Zeile (das ist eine andere, Dockerfile-Sprach-Regel, aktuell nicht enthalten). |
| workflow_not_in_codeowners | LOW | Workflow-Dateien nicht durch einen CODEOWNERS-Eintrag abgedeckt, sodass Änderungen an der CI-Logik keinen bestimmten Reviewer erfordern. |
Insgesamt 38 Regeln in dieser Kategorie — die Tabelle oben ist eine Stichprobe, nicht die vollständige Liste.
Ein reales Beispiel, von Anfang bis Ende
on: pull_request_target
jobs:
build:
steps:
- uses: actions/checkout@v4
with:
ref: ${{ github.event.pull_request.head.sha }}on: pull_request
jobs:
build:
steps:
- uses: actions/checkout@v4Die Behebung hier ist keine Parameteranpassung — sie ist ein Wechsel des auslösenden Events. pull_request_target läuft mit den Berechtigungen und Secrets des Basis-Repos, auch für geforkte PRs; pull_request nicht. Falls nach Prüfung tatsächlich privilegierte Operationen nötig sind, lautet die eigene Empfehlung der Regel, sie in einen separaten workflow_run-Job auszulagern, statt dem pull_request_target-Job einen Checkout-Schritt hinzuzufügen.
Häufig gestellte Fragen
Warum ist CI/CD-Scanning optional statt standardmäßig aktiv?
Derselbe Grund, warum Dependency-Scanning --with-deps benötigt: nicht jedes Projekt hat überhaupt ein .github/workflows oder .gitlab-ci.yml, und YAML-/Pipeline-Dateien standardmäßig bei jedem Projekt zu scannen würde bei denen, die gar kein CI/CD nutzen, null Funde melden (und Scan-Zeit kosten). Die optionale Aktivierung hält den Standard-Scan auf den Anwendungs-Quellcode fokussiert.
Erfasst docker_latest_tag die FROM-Zeile eines Dockerfiles?
Nein — das Muster erfasst einen YAML-Schlüssel image: oder from: (die Syntax innerhalb von .gitlab-ci.yml-Job-Definitionen), nicht die FROM node:latest-Zeile eines Dockerfiles, die keinen Doppelpunkt nach der Anweisung hat. Das ist ein realer, verifizierter Unterschied, keine der Form halber hinzugefügte Einschränkung — die beiden Syntaxen unterscheiden sich ausreichend, dass ein einziges Muster nicht beide abdeckt.
Ändert das Aktivieren von CICD auch das Scannen von Dockerfiles?
Nein — Dockerfile-Hygiene-Regeln (Root-User, COPY . ., nicht fixiertes Basis-Image) liegen in der immer aktiven Kategorie SECURITY, unabhängig von der CICD-Einstellung. Das Aktivieren von CICD fügt nur die Pipeline-YAML-spezifischen Regeln zusätzlich hinzu.
Ist das dieselbe Erkennung wie GitHubs eigenes Workflow-Linting?
Nein — GitHubs eigenes Tooling prüft die syntaktische Gültigkeit des Workflows. Diese Regeln prüfen auf spezifische, bekannt gefährliche Muster (Privilege Escalation via pull_request_target, Supply-Chain-Risiko durch nicht fixierte Actions), die ein syntaktisch gültiger Workflow trotzdem enthalten kann.
An einer echten Pipeline sehen
Öffnen Sie den Live-Demo-Bericht — keine Installation, keine Anmeldung — oder aktivieren Sie die CICD-Kategorie in Ihrem eigenen Projekt und scannen Sie es.
Live-Bericht öffnen CLI-Referenz ansehen