Open-Source-Software in der Verteidigung: Richtlinien, Sicherheitsrisiken und Best Practices

Die Frage, ob Open-Source-Software (OSS) in Verteidigungssystemen geeignet ist, wurde in den 2000er und 2010er Jahren weitgehend geklärt: Die Antwort lautet ja, mit angemessenem Management. Das Policy-Memo des US-Verteidigungsministeriums von 2009 zur Open-Source-Software war eine der ersten formalen Erklärungen, dass OSS nach denselben Kriterien wie proprietäre Software bewertet werden muss. Diese permissive, aber verwaltete Haltung ist nun unter Verteidigungsbeschaffungsrahmen in demokratischen Nationen faktisch universell.

Die aktuelle Herausforderung besteht nicht darin, ob OSS verwendet werden soll, sondern wie es rigoros verwaltet werden kann. Der XZ Utils-Backdoor-Vorfall von 2024, bei dem ein böswilliger Akteur zwei Jahre damit verbrachte, Glaubwürdigkeit in einem Open-Source-Projekt aufzubauen, bevor er einen ausgeklügelten Backdoor einfügte, demonstrierte, dass OSS-Supply-Chain-Risiken nicht theoretisch sind.

Die aktuelle permissiv-verwaltete Haltung gegenüber OSS

Die aktuelle Position des US-DoD zu OSS ist in mehreren Richtliniendokumenten festgehalten. Der konsistente Faden: OSS ist weder von Natur aus sicherer noch unsicherer als proprietäre Software — Sicherheit hängt von der spezifischen Komponente, den Entwicklungspraktiken ihrer Gemeinschaft und dem Governance ab, das von der konsumierenden Organisation angewendet wird. DoD-Programme dürfen OSS im Allgemeinen verwenden, vorbehaltlich Lizenzprüfung, Schwachstellenbewertung und kontinuierlichem Monitoring. Alliierte Verteidigungsorganisationen spiegeln diesen Ansatz generell wider.

Supply-Chain-Risiken: Typosquatting, bösartige Updates und verlassene Bibliotheken

Typosquatting. Angreifer registrieren Paketnamen, die ähnlich wie beliebte legitime Pakete sind. Ein Entwickler, der einen Paketnamen falsch eingibt, installiert statt der beabsichtigten Bibliothek bösartigen Code. Abhilfe erfordert Paketnamensverifizierung zum Zeitpunkt der Installation und Lockfiles, die genaue Paketnamen und -versionen pinnen.

Bösartige Updates. Ein legitimes, weit verbreitetes Paket kann zum Vehikel für Malware werden, wenn seine Betreuer kompromittiert oder durch feindliche Akteure ersetzt werden. Der XZ Utils-Vorfall ist das ausgefeilteste Beispiel. Abhilfe erfordert das Pinnen spezifischer Versionen statt automatischer Akzeptanz von Neuversions-Updates und Monitoring auf anomale Verhaltensänderungen zwischen Versionen.

Verlassene Bibliotheken. Open-Source-Projekte werden häufig von einzelnen Freiwilligen oder kleinen Gruppen gepflegt. Wenn Betreuer die aktive Entwicklung einstellen, kann das Projekt weiterhin von nachgelagerten Programmen genutzt werden, während es ungepatchte Schwachstellen ansammelt. Abhilfe erfordert das Tracking des Wartungsstatus von Abhängigkeiten und eine Richtlinie für den Ersatz oder Fork nicht gewarteter Komponenten.

Lizenz-Compliance. Open-Source-Lizenzen legen Verbrauchern Verpflichtungen auf. Copyleft-Lizenzen (GPL, AGPL) können die Offenlegung abgeleiteten Quellcodes erfordern — was rechtliche und Sicherheitsrisiken für Verteidigungsprogramme schafft, die Quellcode aufgrund von Klassifizierung nicht offenlegen können.

OSS-Genehmigungsprozess: Lizenzprüfung, Schwachstellen-Scanning und Provenienz

Lizenzprüfung bestimmt, ob die Lizenz der Komponente mit dem geplanten Verwendungszweck des Programms kompatibel ist. Programme, die Komponenten mit inkompatiblen Lizenzen verwenden, entdecken das Problem bei der Vertragslieferung oder der rechtlichen Prüfung.

Schwachstellen-Scanning bewertet die spezifische Version der zur Aufnahme betrachteten Komponente gegen bekannte Schwachstellendatenbanken. Die Bewertung sollte nicht nur die Komponente selbst, sondern auch ihre transitiven Abhängigkeiten abdecken. Schwachstellen-Scanning zum Aufnahmezeitpunkt ist notwendig, aber nicht ausreichend; es muss kontinuierlich wiederholt werden.

Provenienzbewertung beurteilt die Vertrauenswürdigkeit der Entwicklungs- und Verteilungsprozesse der Komponente: Identität und Erfolgsbilanz der Betreuer; ob das Projekt einen Sicherheits-Offenlegungsprozess hat; ob Releases signiert sind; ob die Entwicklungspraktiken des Projekts angemessene Qualitätsgewissheit bieten.

SBOM als OSS-Abhängigkeitsverwaltungswerkzeug

Eine Software Bill of Materials (SBOM) ist ein formales, maschinenlesbares Inventar aller Softwarekomponenten in einem System — einschließlich Open-Source-Bibliotheken, kommerziell-fertige Komponenten und intern entwickelte Module — mit ihren Versionen, Lizenzen und Abhängigkeitsbeziehungen. SBOM wird zunehmend für Verteidigungssoftware vorgeschrieben.

Für das OSS-Management bietet SBOM zwei Fähigkeiten, die sonst schwer im Maßstab zu erreichen sind. Erstens ermöglicht es automatisierte Schwachstellenkorrelation: Wenn eine neue Schwachstelle offenbart wird, kann sie automatisch gegen das SBOM korreliert werden, um alle Programme zu identifizieren, die die betroffene Version enthalten. Zweitens ermöglicht SBOM die Lizenz-Compliance-Überwachung im gesamten Abhängigkeitsbaum. Effektive SBOM-Programme integrieren die SBOM-Generierung in die CI/CD-Pipeline, sodass das SBOM stets mit dem tatsächlich eingesetzten Code übereinstimmt.