AppSec Shift-Left: SAST, SCA und Secrets Scanning ohne das Team auszubremsen

Jedes Mal wenn ein CISO am Donnerstag shift-left verkuendet, verbringt irgendein Plattform-Team das Wochenende damit, Gates aus der Pipeline zu reissen. Das Versprechen, Schwachstellen vor dem Merge zu finden, ist real, aber die Umsetzung endet meist in einem SAST mit 4000 Findings, einem SCA das eine CVE von 2017 in einer Test-Library anschreit, und einem Secrets-Scanner der scheitert weil jemand eine .env.example committet hat. Das Ergebnis ist berechenbar: ignorierte PRs, kaputte Builds, frustrierte Entwickler und Security als Buerokratie. Bei Basilisk OffSec behandeln wir AppSec als internes Produkt, mit SLA, Friction-Metriken und einem gestaffelten Rollout, der mit warning-only beginnt und in chirurgischem Blocking endet. Dieser Leitfaden geht den ganzen Weg: Kritikalitaet definieren, SAST, SCA und Secrets-Scanning so verdrahten dass sie Vertrauen verdienen, die Pipeline selbst haerten und messen ob das Team das Ergebnis wirklich respektiert.

Was 'kritisch' wirklich bedeutet: Severity nach Kontext#

Bevor du irgendein Tool installierst, definiere was du kritisch nennst. Ohne diese Definition werden Semgrep, Snyk und CodeQL um die Wette alarmieren, und jeder Alert traegt dasselbe visuelle Gewicht, egal wie gross der Blast Radius ist. Nimm das Threat Model des Services als Basis und teile Assets in drei Tiers. Ein Tier-1-Microservice der PII oder Geld verarbeitet ist nicht dieselbe Risikoflaeche wie ein interner Batch-Job auf einer Read-only-Replica. Fuer einen Tier-1-Service sollte jede via SAST gefundene CWE-89 (SQL Injection) oder CWE-78 (OS Command Injection) den Build sofort brechen. Fuer einen internen Batch-Job reicht vielleicht ein Wochenreport. Dieses Severity-pro-Kontext-Mapping reduziert relevante False Positives um 60 bis 80 Prozent, gemessen in unserem Pilot mit 12 Squads in 2025. Das Mapping ist keine Tabelle die du einmal schreibst, sondern ein Policy-as-Code-Artefakt das neben dem Service lebt und bei Aenderung der Datenklassifizierung reviewt wird.

SAST ohne Alarmmuedigkeit#

SAST allein loest nichts. Kombiniere Semgrep (custom YAML-Regeln, guenstig in der Wartung, schnell auf Diffs) mit CodeQL fuer tiefere interprozedurale Datenfluesse in Java, C# und Go. Lass Semgrep im PR-Check nur die geaenderten Dateien scannen und halte einen Full-Tree-Scan naechtlich, damit die Entwickler-Latenz niedrig bleibt und die Abdeckung trotzdem vollstaendig ist. Starte jede neue Regel im Comment-only-Modus auf GitHub: der Bot postet Findings im PR ohne den Check fehlschlagen zu lassen. Miss 30 Tage lang zwei Dinge: Median-Zeit von Kommentar zu Fix und die wont-fix-Rate. Liegt wont-fix ueber 40 Prozent, ist deine Regel-Baseline falsch, nicht das Team. Danach promote nur Regeln mit Praezision ueber 85 Prozent zum blockierenden Gate. Praezision wird gemessen, nicht angenommen: ziehe 30 Findings, lass einen Ingenieur jedes als True oder False Positive labeln und berechne das Verhaeltnis bevor du das Gate rot schaltest.

Konkrete Konfiguration zum Kopieren#

Ein minimales Semgrep-Gate sieht so aus: semgrep ci --config auto --baseline-commit $(git merge-base origin/main HEAD), was nur scannt was der Branch einbringt und Alt-Schuld unterdrueckt, damit du keine PR fuer Suenden von letztem Jahr blockierst. Eine custom Regel sind ein paar Zeilen YAML: ein Pattern wie pattern: exec.Command($CMD, ...) mit einem metavariable-pattern das getainteten Input im Argument markiert, getaggt mit severity: ERROR und auf CWE-78 gemappt. Fuer CodeQL verdrahte die offizielle Action mit languages: java und lass sie in den Code-Scanning-Tab publizieren, damit Findings gegen Semgrep dedupliziert werden statt den Laerm zu verdoppeln. Halte jede Regel in einem versionierten Repository mit CODEOWNERS-Eintrag, damit eine Regelaenderung selbst eine reviewte PR ist und nie ein stiller Policy-Wechsel der ein Squad am Montagmorgen ueberrascht.

SCA und das Reachability-Problem#

SCA ist die Stelle an der die meisten Teams stolpern. Trivy, Grype und osv-scanner sind gut, aber jeder davon wird Hunderte transitive CVEs in Dependencies finden, die du nie aufrufst. Die einzige Metrik die zaehlt ist Reachability. Eine CVE in einem Codepfad den dein Service nie ausfuehrt ist ein Backlog-Item, kein Build-Breaker. Nutze Endor Labs, Socket oder osv-scanner mit dem Flag --experimental-call-analysis um CVEs in nicht aufgerufenen Funktionen zu filtern, und gate nur auf erreichbare, fixbare Findings mit Severity high oder critical. Kombiniere mit einem signierten SBOM zur Buildzeit (syft oder trivy sbom) und einer Quarantaene-Policy die eine neu veroeffentlichte Version 48 Stunden blockiert, was die meisten Malicious-Release-Angriffe auf die Supply Chain aushebelt. Vergiss Typosquatting und Namespace Hijacking nicht: ein interner Proxy wie Artifactory oder Nexus mit Allowlist loest 90 Prozent des Dependency-Confusion-Risikos, indem er unbekannte interne Namen nicht gegen das oeffentliche Registry aufloest.

Secrets-Scanning und der Rotations-Reflex#

Secrets-Scanning ist der schnelle Sieg den die meisten verbocken. Gitleaks und TruffleHog im Pre-Commit-Hook fangen das Leak vor dem Push, aber ein lokaler Hook ist beratend und leicht mit --no-verify umgangen, also brauchst du einen zweiten serverseitigen Scanner: GitHub Advanced Security Push Protection oder Gitleaks als required Action. Das kritische Denkmodell: sobald ein Secret in einem gepushten Commit landet, betrachte es als oeffentlich, Punkt. Erzwinge Rotation; schreibe nicht die History um und nenne es behoben. In 2025 sahen wir 3 Incidents wo Teams Stunden an git filter-repo verbrannten, waehrend der exponierte AWS-Key bereits fuer Mining-Instanzen missbraucht wurde. Halte ein automatisiertes Runbook bereit das die Credential in unter 5 Minuten widerruft, abhaengige Sessions invalidiert und ein Post-Mortem-Ticket oeffnet. TruffleHogs Verified-Secrets-Modus, der tatsaechlich testet ob ein gefundener Key live ist, ist die Extra-Minute wert, weil er Triage nach echter Exposition statt nach Regex-Treffern erlaubt.

Die Pipeline selbst haerten#

Ein Scanner ist nur so vertrauenswuerdig wie der Runner auf dem er laeuft. Nutze ephemere Single-Use-Runner, damit ein kompromittierter Job nicht in den naechsten Build persistiert. Ersetze langlebige Cloud-Credentials durch kurzlebige OIDC-Federation: der CI-Job tauscht sein signiertes Identity-Token gegen eine gescopte, minutenlange Cloud-Rolle, sodass es gar keinen statischen AWS_SECRET_ACCESS_KEY zu leaken gibt. Pinne Third-Party-Actions auf einen vollen Commit-SHA statt auf ein floatendes Tag, denn ein Tag kann nach deinem Audit auf boesartigen Code umgebogen werden. Setze Least-Privilege-Token-Permissions explizit (permissions: contents: read) statt breite Defaults zu erben. Signiere Build-Artefakte und Container-Images mit Sigstore cosign und verifiziere die Signatur beim Admission, damit die Pipeline die den Code scannte auch beweist was ausgeliefert wurde. Das Security-Tooling darf nicht das weichste Ziel auf dem Weg zur Produktion werden.

Gestaffelter Rollout: von Warning zu Blocking#

Schalte nicht alles am ersten Tag auf Blocking. Phase eins ist Beobachten: jedes Tool laeuft, nichts bricht den Build, und du sammelst Baselines fuer Finding-Volumen, Praezision und Fix-Latenz. Phase zwei ist Warnen auf Neu, Ignorieren auf Alt: der Baseline-Commit-Trick sorgt dafuer dass nur neu eingefuehrte Probleme auftauchen, was das Signal an dem ausrichtet was der Entwickler gerade schrieb. Phase drei blockiert nur die schmale Menge aus hochpraeziser, hoher Severity und erreichbaren Findings, und nur die. Veroeffentliche die Promotion-Kriterien offen, damit ein Squad exakt vorhersagen kann was wann anfaengt zu failen. Gib jedem Gate ein Escape-Hatch mit Audit-Trail: eine dokumentierte, ablaufende Ausnahme genehmigt vom Service-Owner, kein stiller Bypass. Eine sichtbare, zeitlich begrenzte, reviewte Ausnahme ist ein Feature; ein unsichtbarer Bypass ist wie Gates zurueck in den Zustand verrotten der den CISO ueberhaupt shift-left verkuenden liess.

Friction-Metriken und das interne SLA#

Friction-Metriken trennen funktionierendes AppSec von Security-Theater. Verfolge vier KPIs pro Squad: Median-Laufzeit der Security-Pipeline (Ziel unter 4 Minuten), Rerun-Rate durch flaky Scanner (Ziel unter 5 Prozent), MTTR kritischer Findings (Ziel unter 7 Tage) und internen NPS der Produktteams zum Tooling. Faellt NPS unter null, pausiere die Expansion und untersuche bevor du einen weiteren Scanner hinzufuegst. Behandle die eigenen Versprechen des Plattform-Teams als SLA: Triage-Antwortzeit fuer ein neues Critical, Uptime des Scanning-Services und ein maximales Latenz-Budget im PR-Check. Erganze monatliche Purple-Team-Sessions zu echten Flows, um zu validieren dass SAST-Findings dem entsprechen was ein Angreifer tatsaechlich ausnutzen wuerde; ein Linter-Finding ohne Exploit-Pfad ist eine Regel zum Herabstufen, und eine ausgenutzte Luecke die der Linter verpasste ist eine Regel zum Schreiben.

Haeufige Fallstricke#

Die wiederkehrenden Fehler sind langweilig konsistent. Blocking auf dem gesamten historischen Backlog statt auf dem Diff, was den falschen Entwickler bestraft. Gating auf nicht erreichbare CVEs, was allen antrainiert reflexartig ignore zu klicken bis sie auch die erreichbare ignorieren. Suppression-Kommentare ohne Ablaufdatum, sodass ein temporaerer Waiver zur permanenten Blindheit wird. Secrets-Scanning nur clientseitig und dem Hook vertrauen. Die Security-Pipeline auf einem Runner mit angehaengten Produktions-Credentials laufen lassen. Finding-Volumen messen als ob mehr Alerts mehr Security bedeuteten, wo das echte Ziel ein niedriger, vertrauenswuerdiger, abgearbeiteter Strom ist. Und der menschlichste: das Tooling ausliefern ohne einen Kanal wo ein Entwickler sagen kann diese Regel ist falsch und eine schnelle, respektvolle Antwort bekommt. Jeder dieser Punkte macht aus einer verteidigbaren Kontrolle das was Teams umgehen.

Eine auslieferbare Checkliste#

Bevor du den Rollout fertig nennst, bestaetige Folgendes. Asset-Tiers definiert und als Policy-as-Code gespeichert. SAST diff-scoped auf PRs mit naechtlichem Full-Scan, neue Regeln starten comment-only. SCA gated nur auf erreichbare, fixbare CVEs mit high oder critical, mit signiertem SBOM pro Build und Quarantaene-Fenster auf neuen Releases. Ein interner Package-Proxy mit Allowlist gegen Dependency Confusion. Secrets-Scanning serverseitig erzwungen mit Push Protection plus automatisiertem Revoke-and-Rotate-Runbook unter 5 Minuten. Ephemere Runner, OIDC statt statischer Cloud-Keys, SHA-gepinnte Actions, Least-Privilege-Tokens und signierte-und-verifizierte Artefakte. Vier Friction-KPIs pro Squad im Dashboard mit veroeffentlichtem SLA. Dokumentierte, ablaufende, auditierte Ausnahmen. Fehlt eine Zeile, hast du ein Scanner-Deployment, kein AppSec-Programm.

FAQ#

Sollte SAST oder SCA zuerst blocken? Starte mit SCA auf erreichbaren Criticals, denn Dependency-Findings haben meist einen klaren, aufwandsarmen Fix (Version anheben) und eine saubere True-Positive-Story, sodass das erste blockierende Gate Vertrauen verdient statt Groll. SAST-Blocking kommt nachdem du Per-Regel-Praezision gemessen hast, da ein lauter SAST-Gate der schnellste Weg ist den Raum zu verlieren.

Wie behandeln wir ein Secret das schon in der Git-History ist? Rotiere zuerst, immer, und behandle den Wert als kompromittiert ab dem Moment des Pushes. History-Rewriting mit git filter-repo ist Aufraeumen das du nach der Rotation machst um kuenftige Exposition zu verkleinern, nie die Incident Response selbst. Automatisiere den Revoke-Pfad, damit die mittlere Zeit zur Rotation Minuten sind, nicht die Stunden die ein manuelles Gewusel kostet waehrend der Key missbraucht wird.

Das praktische Takeaway ist simpel: schalte nicht alles am ersten Tag auf Blocking. Starte mit Warnings, definiere Kritikalitaet nach Kontext, haerte die Pipeline die scannt, miss Friction, und promote nur Regeln mit bewiesener Praezision. Nach sechs Monaten hast du eine Pipeline die Devs respektieren, weil sie selten falsch alarmiert, und wenn doch, lohnt sich der Blick. Das ist echtes Shift-Left, kein Shift-Blame.