Das Buchungsportal der Nordlicht Reisen GmbH liegt zum Teil bei GitHub, zum Teil in Azure Repos. Die Sicherheitsprüfung besteht bisher aus einem Dokument, das jeder einmal im Jahr liest. Vergangenen Monat lief ein veraltetes Paket mit bekannter Schwachstelle drei Wochen in der Produktion, bevor es jemand bemerkte. Sie sollen die Prüfungen in die Pipelines legen, die Ergebnisse an einer Stelle zusammenführen und entscheiden, welche Funde das Zusammenführen eines Pull Requests blockieren.
Die Prüfung nennt das: eine Prüfstrategie (Abhängigkeiten, Quellcode, Geheimnisse, Lizenzen) entwerfen, Microsoft Defender for Cloud DevOps Security einsetzen, GitHub Advanced Security für GitHub und für Azure DevOps nutzen, Container prüfen und Dependabot einsetzen.
Vorwissen: Defender for Cloud als Werkzeug zum Lesen von Empfehlungen und die Lieferkette (NuGet Audit, SBOM, Paketquellen, Signaturen) stehen in K3, Lektionen 3.3.5 und 3.3.8; Secret Scanning und Push Protection bei GitHub in 3.3.3; Abhängigkeits- und Geheimnisprüfung in der Pipeline in 3.7.7. Neu sind hier der Entwurf der Strategie, die Azure-DevOps-Seite und die Lizenzfragen.
Eine Prüfstrategie
| Prüfung | Findet | Läuft sinnvoll | Blockiert? |
|---|---|---|---|
| Geheimnisse (Secret Scanning) | Schlüssel und Kennwörter in Code und Verlauf | beim Push (Push Protection) und über das ganze Repository | ja, schon beim Push |
| Abhängigkeiten (Dependency Scanning, Dependabot) | bekannte Schwachstellen in direkten und indirekten Paketen | im Pull Request, auf dem Hauptzweig, nach Zeitplan | hohe und kritische Funde |
| Quellcode (Code Scanning, CodeQL) | Schwachstellen im eigenen Code | im Pull Request und nach Zeitplan | neue hohe und kritische Funde |
| Lizenzen | unerwünschte Lizenzen neuer Abhängigkeiten | im Pull Request | ja, nach Richtlinie |
| Container-Images | Schwachstellen im gebauten Image | in der Pipeline nach dem Bauen, vor der Auslieferung | nach Richtlinie |
| Infrastruktur als Code | Fehlkonfigurationen in Vorlagen | im Pull Request | nach Richtlinie |
Die Regel dahinter: früh und billig prüfen, was sich früh prüfen lässt (Geheimnisse, Abhängigkeiten), gründlich nach Zeitplan (Quellcode-Analyse auf jedem Zweig ist teuer) und nur blockieren, was Sie beheben können. Microsoft beschreibt in seinem eigenen Vorgehen (Securing source code with GitHub Advanced Security), mit den kritischen Repositories zu beginnen und die Prüfungen schrittweise einzuführen.