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 Devs 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.

Bevor du irgendein Tool installierst, definiere was du 'kritisch' nennst. Ohne diese Definition werden Semgrep, Snyk und CodeQL um die Wette alarmieren. Nimm das Threat Model des Services als Basis: falls du noch keins hast, starte mit STRIDE Threat Modeling im Sprint: Vollstaendiges Beispiel an einem Microservice und teile Assets in drei Tiers. Fuer einen Tier-1-Microservice der PII verarbeitet, sollte jede via SAST gefundene CWE-89 oder CWE-78 den Build 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.

SAST allein loest nichts. Kombiniere Semgrep (custom YAML-Regeln, guenstig in der Wartung) mit CodeQL fuer tiefere Datenfluesse in Java und C#. Starte 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 '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. Fuer Web-Injection-Klassen erganze die Einfuehrung mit Praxis aus SQL Injection in der Praxis: Ausnutzen, Erkennen und Mitigieren im Kontrollierten Lab und Modernes XSS: DOM, Stored und Reflected mit Beispielen aus dem Testlabor, damit Devs verstehen worueber der Linter eigentlich schreit.

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. Nutze Endor Labs, Socket oder osv-scanner mit Flag --experimental-call-analysis um CVEs in nicht aufgerufenen Funktionen zu filtern. Kombiniere mit signiertem SBOM und Quarantaene-Policy, wie in Supply Chain Security: Sigstore-Signatur und echte SBOMs in CI/CD beschrieben. Und vergiss Typosquatting und Namespace Hijacking nicht: ein interner Proxy (Artifactory, Nexus) mit Allowlist loest 90 Prozent des Problems, und Dependency Confusion und Typosquatting: Praktische Abwehr fuer Dev-Teams beschreibt die Fallen die trotzdem durchrutschen.

Secrets Scanning ist der schnelle Sieg den die meisten verbocken. Gitleaks und Trufflehog im Pre-Commit fangen das Leak vor dem Push, aber du brauchst einen zweiten Scanner serverseitig (GitHub Advanced Security oder Gitleaks via Action) um Bypass des lokalen Hooks abzudecken. Kritischer Punkt: wird ein Secret in einem bereits gepushten Commit entdeckt, betrachte es als veroeffentlicht. Erzwinge Rotation, schreibe nicht die History um. In 2025 sahen wir 3 Incidents wo Teams Stunden an git filter-repo verbrannten, waehrend der AWS-Key bereits missbraucht wurde. Halte ein automatisiertes Runbook bereit das die Credential in unter 5 Minuten widerruft und ein Post-Mortem-Ticket oeffnet.

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. Erganze monatliche Purple-Team-Sessions zu echten Flows, abgestimmt mit Purple Team in der Praxis: Aufbau eines Red-Blue-Feedback-Zyklus, um zu validieren dass SAST-Findings dem entsprechen was das Red Team tatsaechlich ausnutzt.

Das praktische Takeaway ist simpel: schalte nicht alles am ersten Tag auf Blocking. Starte mit Warnings, definiere Kritikalitaet nach Kontext, 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.