DevSecOps für Verteidigungsprogramme: Sicherheit in jedem Sprint

DevSecOps — die Integration von Sicherheitspraktiken in jeden Schritt des Software-Entwicklungszyklus — ist die Antwort von Verteidigungsprogrammen auf die Erkenntnis, dass traditionelle Sicherheitsansätze mit End-of-Line-Testing nicht mit modernen Software-Liefergeschwindigkeiten Schritt halten. Wenn Sicherheitstests erst kurz vor der Veröffentlichung stattfinden, ist die Behebung von Schwachstellen kostspielig und verzögert die Lieferung; wenn sie in die CI/CD-Pipeline integriert sind, werden Schwachstellen nahe an ihrem Einführungsort entdeckt, während der Kontext frisch und die Behebung relativ kostengünstig ist.

Verteidigungsprogramme haben zusätzliche Anforderungen im Vergleich zu kommerziellem DevSecOps: STIG-Konformität (Security Technical Implementation Guides), Audit-Trails für Akkreditierungsstellen, Secret-Management für klassifizierte Systeme und strenge Anforderungen an die Lieferketten-Integrität für Code-Artefakte, die in kritischen Systemen eingesetzt werden. Diese Anforderungen ändern die Konfiguration und Prioritäten der DevSecOps-Pipeline, aber nicht die grundlegende Architektur. BSI und BMVg haben beide Rahmenwerke für sichere Softwareentwicklung veröffentlicht, die DevSecOps-Ansätze als Best Practice für Verteidigungssoftware bestätigen.

Statische Code-Analyse: Semgrep und SAST-Tools

SAST (Static Application Security Testing) analysiert Quellcode oder Bytecode, ohne ihn auszuführen, und erkennt potenzielle Schwachstellen durch Datenflussanalyse, Konfigurationsprüfung und Mustererkennung. Semgrep ist der De-facto-Standard für leichtgewichtiges SAST in DevSecOps-Pipelines: Es unterstützt über 30 Programmiersprachen, läuft innerhalb von Sekunden auf typischen Code-Basen und kann auf spezifische Sicherheitsmuster zugeschnitten werden, die für Verteidigungsprogramme relevant sind — hartcodierte Geheimnisse, unsichere kryptografische Primitive, unsichere Deserialisierung.

Semgrep ermöglicht Regeldefinitionen mit einfacher YAML-Syntax, was Sicherheitsteams ermöglicht, domänenspezifische Sicherheitsmuster zu kodifizieren. Für Verteidigungsprogramme umfasst dies domänenspezifische Regeln: Verifizierung der Verschlüsselung klassifizierter Daten, Erkennung unsicherer Netzwerkverbindungen im Kontext klassifizierter Systeme und Erkennung von Datenzugriffsmuster, die obligatorische Zugriffskontrollregeln (MAC) verletzen.

Dynamisches Testen: OWASP ZAP und DAST in der Pipeline

DAST (Dynamic Application Security Testing) testet laufende Anwendungen, indem schädliche Eingaben gesendet und das Verhalten beobachtet wird — Schwachstellen werden entdeckt, die aus Wechselwirkungen zwischen Komponenten entstehen, nicht aus isoliertem Quellcode. OWASP ZAP (Zed Attack Proxy) ist das Standard-Open-Source-DAST-Tool für die CI/CD-Pipeline-Integration. ZAP im Daemon-Modus bietet eine REST-API, die Pipelines ermöglicht, automatisierte Scans durchzuführen, Berichte abzurufen und mit einem Nicht-Null-Code für Funde, die Schwellenwerte überschreiten, zu beenden.

Für Verteidigungsanwendungen müssen DAST-Scans verteidigungsspezifische Angriffsvektoren abdecken: Authentifizierungsschwachstellen in Systemen mit obligatorischer Zugriffskontrolle, SQL-Injection in Datenbanken mit operativen Daten, Session-Management-Schwachstellen in Systemen mit mehreren Klassifizierungsstufen.

Komponentenanalyse: SCA und Schwachstellenerkennung

SCA (Software Composition Analysis) identifiziert bekannte Schwachstellen in Drittanbieter-Abhängigkeiten. Grype und Trivy sind Standard-SCA-Tools in DevSecOps-Pipelines: Sie scannen Abhängigkeitspakete (Maven, npm, pip, Go-Module) und Container-Images gegen Schwachstellen-Datenbanken (NVD, GitHub Advisory Database, Distributions-Advisory-Datenbanken).

Für Verteidigungsprogramme ist SCA aus zwei Gründen besonders wichtig: Drittanbieterkomponenten sind die häufigste Quelle von Schwachstellen in ausgereiften Code-Basen, und die Anforderungen an die Lieferkette von Verteidigungsprogrammen erfordern eine vollständige Inventarisierung und Dokumentation von Drittanbieterkomponenten.

Secret-Erkennung: Gitleaks und Pre-Commit-Schutz

Geheimnisse — API-Schlüssel, Passwörter, Zertifikate, Token — die in Quellcode-Repositorys gelangen, sind eine der häufigsten und folgenreichsten Sicherheitsverletzungen. Gitleaks und detect-secrets sind Standard-Secret-Scanning-Tools in DevSecOps-Pipelines: Sie analysieren Git-Repositorys (einschließlich Git-History) auf Muster, die bekannten Secret-Formaten entsprechen. Pre-Commit-Hooks, die Gitleaks ausführen, bieten die erste Schutzbarriere, die Commits mit erkannten Geheimnissen verhindert.

Container-Sicherheit: Image-Signierung und Registry

Container-Images, die in Verteidigungssystemen eingesetzt werden, müssen auf Integrität verifiziert werden. Cosign (vom Sigstore-Projekt) bietet Container-Image-Signierung und -Verifizierung: Die Build-Pipeline signiert das Image mit einem kryptografischen Schlüssel nach erfolgreichem Durchlaufen aller Sicherheitsprüfungen; ein Kubernetes-Admission-Webhook verifiziert die Signatur vor dem Deployment. Harbor ist die Standard-Container-Registry für gesicherte und Air-Gap-Verteidigungsdeployments: Es bietet Zugriffskontrolle, Audit-Logs, eingebautes Schwachstellen-Scanning (über Trivy) und Unterstützung für Content-Signierung.

STIG-Konformität: Automatisierung der Verifizierung

STIGs (Security Technical Implementation Guides), veröffentlicht von DISA, definieren spezifische technische Anforderungen an Sicherheitskonfigurationen für DoD-Systeme. OpenSCAP bietet automatisierte STIG-Konformitätsprüfung: Es vergleicht Systemkonfigurationen mit STIG-Spezifikationen (im XCCDF/OVAL-Format) und generiert Konformitätsberichte, die Kategorie-I- (kritische), Kategorie-II- (mittlere) und Kategorie-III-Befunde (niedrige) identifizieren. Für CI/CD-Pipelines können STIG-Konformitätsprüfungen als Teil des Container-Image-Builds automatisiert werden: nach dem Erstellen des Basis-Images, aber vor dem Push in die Registry, führt OpenSCAP das entsprechende STIG-Profil gegen das Image aus.