DevSecOps und Supply Chain Security
In den letzten Kapiteln hast du gesehen, welche Sicherheitsprüfungen es gibt und wie sie funktionieren. Die entscheidende Frage ist jetzt: Wann laufen diese Prüfungen?
Um beim Beispiel zu bleiben, wenn die Entwickler für NovaHealth das Laborergebnis-Modul mehrmals pro Woche aktualisieren, kann nicht jedes Mal jemand manuell daran denken, alle Sicherheitschecks zu starten. Genau dafür gibt es DevSecOps.
„Wenn wir Sicherheitsprüfungen erst kurz vor dem Release machen, finden wir Probleme viel zu spät. Eigentlich müssten sie automatisch mitlaufen, sobald Code geändert wird.“
„Genau das ist DevSecOps. Sicherheit wird nicht als extra Kontrolltermin am Ende verstanden, sondern als fester Teil der Pipeline.“
Bevor wir über DevSecOps sprechen, kurz zu DevOps: DevOps verbindet Entwicklung und Betrieb enger miteinander. Ziel ist, Software schneller, stabiler und automatisierter zu bauen, zu testen und auszuliefern. Konkret heißt DevOps zum Beispiel folgende Pipeline:
- Entwickler pushen Code in ein Repository
- Eine Pipeline baut die Anwendung automatisch
- Tests laufen automatisch und prüfen ob alles funktioniert
- Ein erfolgreicher Build wird in eine Testumgebung ausgerollt.
Der Betrieb stellt dafür standardisierte Umgebungen, Monitoring und Deployment-Prozesse bereit. Bei NovaHealth könnte so jede Änderung am Laborergebnis-Modul automatisch gebaut, getestet und nach Staging ausgeliefert werden. Typische DevOps-Werkzeuge sind GitHub Actions, GitLab CI/CD und Jenkins.
DevSecOps erweitert DevOps um (wer hätte es gedacht) Security. Während DevOps die Pipeline automatisiert, sorgt DevSecOps dafür, dass diese Pipeline nicht nur funktional prüft, sondern auch Sicherheitsrisiken erkennt. Sicherheit wird so als fester Bestandteil der Entwicklung eingeplant.
Die bestehende DevOps-Pipeline wird zum Beispiel um folgende Security-Schritte ergänzt:
- Entwickler pushen Code in ein Repository.
- Secret Detection prüft früh, ob Zugangsdaten oder private Schlüssel versehentlich eingecheckt wurden.
- SAST prüft den Quellcode auf typische Sicherheitsprobleme.
- SCA prüft Drittanbieter-Bibliotheken auf bekannte Schwachstellen.
- Die Pipeline baut die Anwendung automatisch.
- Tests laufen und prüfen ob alles fachlich funktioniert
- Falls Container genutzt werden, prüft Container-Scanning das erzeugte Image.
- Die Anwendung wird in eine Staging-Umgebung ausgerollt.
- DAST testet die laufende Anwendung in Staging von außen.
- Ein Security Gate bewertet die Ergebnisse und blockiert den Release bei kritischen Findings.
Wichtig ist die Balance. Wenn jede kleine Warnung den Release stoppt, werden die Entwickler irgendwann versuchen die Regeln zu umgehen. Wenn gar nichts stoppt, ist das es für die Security ebenfalls sinnlos. NovaHealth sollte deshalb klare Regeln definieren: Kritische Schwachstellen in produktivem Code blockieren. Mittlere Findings brauchen eine gezielte Risiko-Bewertung. Niedrige Findings werden dokumentiert und können potenziell bis zum nächsten Release warten.
Supply Chain Security
Eine Anwendung besteht heutzutage so gut wie nie nur aus eigens entwickeltem Code. Das NovaHealth-Labormodul zum Beipsiel nutzt Frameworks, Bibliotheken, Build-Tools, Container-Images und CI/CD-Actions. All das ist Teil der Software Supply Chain, also der Software-Lieferkette.
Software Supply Chain Security bedeutet daher, diese gesamte Lieferkette abzusichern. Wenn eine externe Bibliothek verwundbar ist oder ein Container-Image aus einer unsicheren Quelle stammt, kann die Anwendung trotz Einhaltung aller hier gelernten Sicherheiten kompromittiert werden.
Das macht Supply-Chain-Angriffe wirklich gefährlich: Sie nutzen Vertrauen aus. Entwickler installieren ein Paket, übernehmen ein Update oder starten ein signiertes Artefakt und gehen davon aus, dass es sauber ist. Ein besonders eindrückliches Beispiel ist der Fall XZ Utils aus dem Jahr 2024.
XZ Utils ist ein weit verbreitetes Kompressionswerkzeug unter Linux. Viele Systeme nutzen es direkt oder indirekt, oft ohne dass ein Administrator es bewusst wahrnimmt. Es ist also sehr tief in der Lieferkette verankert. Beim XZ-Fall wurde versucht, Schadcode in das XZ Open-Source-Projekt einzuschleusen, das später von vielen Linux-Distributionen übernommen werden sollte. Der Angreifer baute über längere Zeit Vertrauen im Projektumfeld auf, beteiligte sich an Diskussionen und brachte schließlich manipulierte Bestandteile in veröffentlichte Pakete ein.
Abhängigkeiten prüfen
Der erste praktische Schritt ist daher sauberes Dependency Management, also das Verwalten aller Abhängigkeiten wie z.B. benötigte Bibliotheken.
Hier kommt SCA (Software Composition Analysis) ins Spiel. SCA prüft, welche externen Komponenten eine Anwendung verwendet und ob dafür bekannte Schwachstellen existieren.
Bei NovaHealth könnte SCA zum Beispiel feststellen, dass die Anwendung eine veraltete JSON-Bibliothek verwendet, für die bereits eine kritische Schwachstelle veröffentlicht wurde. Das bedeutet nicht automatisch, dass NovaHealth ausgenutzt wurde. Es bedeutet aber: Das Team muss prüfen, ob die verwundbare Funktion genutzt wird, ob ein Update verfügbar ist und wie schnell die Abhängigkeit aktualisiert werden muss.
Bekannte SCA-Tools sind zum Beispiel OWASP Dependency-Check und Trivy als frei verfügbare Werkzeuge, sowie Snyk Open Source oder Black Duck SCA als kommerzielle Plattformen. Auf GitHub kann Dependabot relativ einfach eingebunden werden und automatisch vor bekannten verwundbaren oder inzwischen als bösartig bekannten Abhängigkeiten warnen.
Achtung: bei einem Update von Drittanbieter-Software sollten immer auch funktionale Tests laufen, da Updates potenziell die Kompatibilität beeinträchtigen.
Wenn morgen eine kritische Lücke in einer vielgenutzten Bibliothek bekannt wird, ist es nützlich eine sogenannte SBOM (Software Bill of Material) zu haben. Das ist im Grunde eine Liste, die aufzählt welche Komponenten in welcher Version in welcher Software enthalten sind. Ohne diese Liste beginnt erstmal eine aufwändige Suche, welche Projekte überhaupt diese Bibliothek nutzen und in welcher Version in welchem Container und so weiter.
Für SBOMs existieren verbreitete Formate wie CycloneDX, ein Standard für Bill-of-Materials-Daten mit starkem Fokus auf Supply-Chain-Sicherheit und SPDX, ein offener Standard der Linux Foundation für SBOM-Informationen, Lizenzdaten und weitere Software-Lieferketteninformationen.
Vereinfacht gesagt: DevSecOps automatisiert Sicherheit. Supply Chain Security sorgt dafür, dass die Automatisierung selbst nicht zum Einfallstor wird.