Shift Left Security

• IDE-Plugins: Dein Editor (VS Code) unterstreicht unsicheren Code sofort rot ("SonarLint").
• Pre-Commit Hooks: Git verweigert den Upload, wenn du Passwörter im Code hast (gitleaks).
• CI-Tests: Jeder Pull Request wird automatisch gescannt.

1. Kostenkurve (Boehm's Curve)

Barry Boehm bewies: Ein Bug zu fixen kostet exponentiell mehr, je später man ihn findet.

• Requirements: 1x Kosten.
• Coding: 10x Kosten.
• Testing: 100x Kosten.
• Production: 1000x Kosten (plus Image-Schaden). Shift Left ist also reine Ökonomie.

2. Cultural Shift

Das Schwierigste ist nicht das Tooling, sondern die Kultur. Entwickler fühlen sich oft ausgebremst ("Der Security-Check nervt!"). Man muss Security "enablen", nicht "blocken". "Hier ist ein Tool, das dir hilft, sicherere Apps zu bauen", statt "Hier ist eine Liste von Verboten".

1. SAST vs. DAST in der Pipeline

Um Shift Left technisch umzusetzen, nutzt man zwei Arten von Scannern:

• SAST (Static Application Security Testing): Scannt den Quellcode, ohne ihn auszuführen (White-Box). Das passiert direkt beim "Git Push". Es findet SQL-Injections oder Hardcoded Secrets sofort. Problem: Es meldet oft "False Positives" (Alarme, die gar keine sind).
• DAST (Dynamic Application Security Testing): Greift die laufende App von außen an (Black-Box), wie ein Hacker. Das passiert meist in der "Staging"-Phase. Es findet Konfigurationsfehler, die im Code gar nicht sichtbar waren (z.B. falsche SSL-Zertifikate). Ein echtes Shift-Left-System kombiniert beides, priorisiert aber SAST, da es dem Entwickler direkt die Zeilennummer im Code zeigen kann.

2. Software Composition Analysis (SCA)

Da 80% des modernen Codes aus Open-Source-Bibliotheken bestehen, bringt es nichts, nur den eigenen Code zu prüfen. Shift Left bedeutet auch: SCA. Bei jedem Build wird die "Bill of Materials" (SBOM) gegen Datenbanken mit bekannten Schwachstellen (CVE) abgeglichen. Wenn du ein npm install machst und eine Bibliothek eine kritische Lücke hat, bricht die Pipeline sofort ab. Das verhindert die "Supply Chain Attacks", bei denen Hacker nicht dich direkt, sondern deine Zulieferer (Libraries) angreifen.

3. Threat Modeling im Design

Das ultimative "Links-Schieben" passiert vor der ersten Codezeile. Anstatt Security als Ticket nach dem Sprint zu sehen, machen Teams Threat Modeling während der Architektur-Planung (z.B. mit der STRIDE-Methode). Man fragt: "Welche Daten fließen hier? Wo könnte ein Angreifer ansetzen? Haben wir Logins geschützt?". Studien zeigen, dass Architekturfehler, die im Design gefunden werden, nur 1% dessen kosten, was ein Fix in der Produktion kosten würde. Shift Left fängt also im Kopf der Architekten an, nicht nur im Jenkins-Server.