Direkt zum Seiteninhalt springen

Eine Achillesferse moderner Streitkräfte

Risiken der Software-Lieferkette und Schutzmöglichkeiten

SWP-Studie 2025/S 14, 21.10.2025, 39 Seiten

doi:10.18449/2025S14

Forschungsgebiete

Dr. Alexandra Paulus ist Wissenschaftlerin in der Forschungsgruppe Sicherheitspolitik und Ko‑Koordinierende Leiterin des Forschungsclusters Cybersicherheit und Digitalpolitik.

  • Moderne Streitkräfte sind enorm abhängig von Softwareprodukten. Diese sind das Ergebnis komplexer Geflechte aus Software-Anbietern, Dienstleistern, Softwarekomponenten und weiteren Unternehmen, die zu­sammen die Software-Lieferkette bilden.

  • Bei »herkömmlichen« Cybersicherheitsvorfällen verschaffen sich Bedro­hungsakteur:innen in der Regel direkt Zugang zu ihrem Ziel. Im Gegensatz dazu haben Risiken der Software-Lieferkette ihren Ursprung an einer vorgelagerten Stelle der Lieferkette und erzeugen dann an anderer Stelle einen Effekt – häufig bei den Endnutzer:innen.

  • Streitkräfte sind besonders anfällig für diese Risiken. Vorfälle im militäri­schen Bereich, bei denen die Software-Lieferkette eine Rolle spielte, haben militärische Betriebsabläufe unterbrochen oder böswilligen Akteuren Wirtschaftsspionage, politische Spionage und Sabotage ermöglicht.

  • Der Bundespolitik und der Bundeswehr stehen mehrere Maßnahmen zur Verfügung, um die Streitkräfte vor den Auswirkungen der Risiken der Soft­ware-Lieferkette zu schützen. Dabei müssen Entscheidungsträger:in­nen zunächst für unterschiedliche Einsatzbereiche von Software ein an­gemessenes Schutzniveau festlegen, um die Balance zu wahren zwischen dem Schutz vor den Risiken auf der einen und Funktionalität, Kosten und Einsatzgeschwindigkeit auf der anderen Seite.

  • Die Bundesregierung und die Bundeswehr sollten einerseits Maßnahmen ergreifen, um einen bewussten Umgang der Streitkräfte mit den Risiken der Software-Lieferkette zu ermöglichen und sich selbst zu schützen; andererseits sollten sie Software-Anbieter dazu bringen, die Angreifbarkeit ihrer Produkte zu reduzieren. Durch die Kombination beider Ansätze kann diese mögliche Bedrohung in Schach gehalten werden.

Inhaltsverzeichnis

1 Problemstellung und Empfehlungen

2 Einleitung

3 Die Software-Lieferkette

4 Risiken der Software‑Lieferkette

4.1 Lieferketten-Angriffe von Dritten

4.2 Angriffe von Innentäter:innen

4.3 Unbeabsichtigte Fehler

4.4 Fehlender Software-Support

5 Die besondere Bedrohung von Streitkräften

5.1 Bedeutung von Software für Streitkräfte

5.1.1 Die Abhängigkeit wird weiter zunehmen

5.2 Verschärfte Bedrohung durch militärische Besonderheiten

5.3 Die Auswirkungen vergangener Software-Lieferketten-Vorfälle auf Streitkräfte

5.3.1 Beeinträchtigung von Betriebsabläufen

5.3.2 Wirtschaftsspionage, politische Spionage und Sabotage

6 Wie sich Streitkräfte selbst vor Risiken der Software-Liefer­kette schützen können

6.1 Festlegung des angemessenen Schutzniveaus

6.2 Handlungsfähigkeit

6.2.1 Schaffung klarer Verantwortlichkeiten

6.2.2 Entwicklung von Leitlinien für den Um­gang mit Software-Lieferketten-Risiken

6.2.3 Entwicklung von Leitlinien für die militärische Nutzung von Open-Source-Software

6.2.4 Einrichtung eines militärischen Open Source Program Office

6.3 Einrichtung interner Prozesse

6.3.1 Sammeln von Informationen

6.3.2 Überwachung des Software-Support-Status

6.4 Aufbau von Fachexpertise

6.5 Red-Teaming-Aktivitäten

6.6 Ausschluss nicht vertrauenswürdiger Hersteller von der Vergabe

7 Wie Politik und Streitkräfte Software-Anbieter zum Risiko­management bewegen können

7.1 Anforderungen an Software-Anbieter

7.2 Bereitstellung von Muster-Vertragsbausteinen

7.3 Anpassung von Anforderungen im Beschaffungsprozess

7.4 Anpassung des Produkthaftungsrechts

7.5 Konformitätsbewertungen

8 Prioritäten für Bundespolitik und Bundeswehr

9 Abkürzungen

Problemstellung und Empfehlungen

Moderne Streitkräfte sind enorm abhängig von Soft­ware – das gilt für Verwaltungsaufgaben und Logistik, aber auch für moderne Waffensysteme wie Panzer, Kriegsschiffe und Kampfflugzeuge. Die betreffenden Softwareprodukte sind das Ergebnis komplexer Geflechte aus Software-Anbietern, Dienstleistern, Softwarekomponenten und weiteren Unternehmen, die zusammen die Software-Lieferkette bilden.

Bei »herkömmlichen« Cybersicherheitsvorfällen verschaffen sich Bedrohungsakteur:innen häufig direkt Zugang zu ihrem Ziel. Im Gegensatz dazu haben Risiken der Software-Lieferkette ihren Ursprung an einer vorgelagerten Stelle der Lieferkette und treten dann an anderer Stelle in Form eines schädlichen Effekts zutage – häufig bei den Endnutzer:innen. Zum Beispiel drangen russische Spione zwischen 2019 und 2020 nicht direkt in die IT-Systeme der US‑Behörde ein, die das US-Atomwaffenarsenal wartet. Stattdessen verschafften sie sich Zugang zum Softwarehersteller SolarWinds, um von dort aus ein Update mit Schadsoftware an die gut ge­sicherte Behörde zu senden und so an ihrem Ziel Daten abzugreifen.

Alle Glieder der Lieferkette sind dabei über Software verbunden – sei es durch das Softwareprodukt selbst, seine Komponenten oder über den Zugang zum Softwareprodukt, der beispielsweise einem Dienst­leister gewährt wird. Entsprechend können alle Glieder in der Lieferkette von Softwareprodukten, die Streitkräfte nutzen, Einfallstore in militärische Systeme darstellen. Dabei sind gerade kleine und mittlere Unternehmen oder kleinere Open-Source-Software-Projekte (OSS-Projekte) oft schlecht geschützt und daher ein leichtes Ziel für Angreifer:innen. Dazu kommt, dass Streitkräfte üblicherweise keinen Über­blick haben über alle Softwareprodukte, die sie nutzen – und erst recht nicht über alle Akteur:innen und Komponenten, die Teil der Lieferketten dieser Produkte sind. Und schließlich haben Streitkräfte keine oder nur sehr begrenzte Kontrolle über große Teile der Lieferkette. Daher sind Software-Lieferketten eine Achillesferse moderner Streitkräfte: Selbst das technologisch fortschrittlichste Militär kann zum Opfer werden von Angriffen, die sich die komplexe Struktur von Software-Lieferketten zunutze machen.

Vorfälle, in denen die Software-Lieferkette eine Rolle spielt, können militärische Betriebsabläufe unterbrechen oder es böswilligen Akteur:innen er­lauben, Wirtschaftsspionage, politische Spionage und Sabotage zu betreiben. So erlangten etwa zwischen 2013 und 2018 Personen aus dem Umfeld des chine­sischen Nachrichtendienstes über Cloud-Anbieter Zugriff zu den Systemen der größten US-Marinewerft. Und 2022, am ersten Tag der russischen Invasion der Ukraine, kaperte der russische Militärgeheimdienst ein Software-Update eines Satellitenkommunikations­anbieters, um die Konnektivität des ukrainischen Militärs auf dem Gefechtsfeld zu unterbrechen. Auch unbeabsichtigte Fehler können großen Schaden bei Endnutzer:innen hervorrufen, wie der »CrowdStrike«-Vorfall aus dem Sommer 2024 zeigt, der weltweit etwa 8,5 Millionen Geräte vorübergehend unbrauchbar machte. Und schließlich kann auch fehlender Software-Support tiefgreifende Folgen haben – so drohten ukrainische Kampfflugzeuge im März 2025 ohne Software-Support durch die USA einsatzunfähig zu werden. Kurz: Entsprechende Vorfälle können die Kriegstüchtigkeit von Streitkräften gefährden.

Vor diesem Hintergrund beantwortet diese Studie die Frage, wie sich Streitkräfte vor Risiken der Soft­ware-Lieferkette schützen können. In den Haupt­kapiteln der Studie werden (1) die Struktur von Soft­ware-Lieferketten und die daraus hervorgehenden Risiken beschrieben; (2) besondere Merkmale von Streitkräften, die ihre Anfälligkeit für diese Risiken verstärken, analysiert und die Auswirkungen wich­tiger entsprechender Vorfälle im militärischen Bereich untersucht; und schließlich wird herausgearbeitet, (3) wie Streitkräfte sich selbst besser vor diesen Risiken schützen können und (4) wie Politik und Streitkräfte Software-Anbieter dazu bewegen können, die Risiken ihrer Produkte zu reduzieren.

Im Ergebnis wird empfohlen, dass die Politik und die Bundeswehr zunächst abwägen, wie das an­zustrebende Schutzniveau von Softwareprodukten je nach Einsatzbereich aussehen sollte. Zudem sollte die Bundeswehr selbst Maßnahmen ergreifen, um sich vor den Risiken der Software-Lieferkette zu schützen:

  • Um handlungsfähig zu werden, sollte einer Stelle die Verantwortung für den Umgang mit diesen Risiken übertragen werden. Aufgabe dieser zuständigen Person wäre es, Leitlinien für den Umgang mit Risiken in der Software-Lieferkette sowie für die militärische Nutzung von Open-Source-Software zu formulieren.

  • Um entsprechende Maßnahmen auch in den operativen Betriebsabläufen der Bundeswehr zu verankern, sollten bundeswehrweit Prozesse zum Umgang mit Risiken der Software-Lieferkette eta­bliert werden – beispielsweise sollte das IT-Fach­personal der Bundeswehr regelmäßig überprüfen, ob eingesetzte Softwareprodukte noch Sicherheits­updates und funktionale Upgrades erhalten.

  • Damit die hier aufgeführten Maßnahmen funktio­nieren, sollte die Bundeswehr mehr Fachexpertise zu diesem Thema aufbauen.

  • Um Angriffsmöglichkeiten schon vorab zu identi­fizieren, sollte die Bundeswehr selbst nach Schwach­stellen in eigenen Systemen und verwendeten Softwareprodukten suchen.

  • Und um Angriffe von Innentäter:innen zu verhin­dern, sollte der Beschaffungsapparat Wege finden, die es ermöglichen, dass nicht vertrauenswürdige Anbieter von der Beschaffung ausgeschlossen werden.

Zudem sollten Politik und Bundeswehr Software-Anbieter dazu bringen, die Risiken ihrer Produkte zu reduzieren:

  • Dafür sollten Politik und Bundeswehr zunächst Maßnahmen identifizieren, die die Anbieter umsetzen müssen. Die Studie macht dazu sechs Vorschläge, darunter die Bereitstellung von Informationen über Softwarekomponenten bzw. über die Ausnutzbarkeit von Schwachstellen in eigenen Produkten.

  • Um die Anbieter zur Umsetzung dieser Schritte zu bewegen, sollte die Politik dem Beschaffungs­personal Musterverträge zur Verfügung stellen und die Beschaffungsanforderungen und das Produkthaftungsrecht anpassen.

  • Zusammengenommen können es diese Maßnahmen der Bundeswehr ermöglichen, Risiken in der Soft­ware-Lieferkette auf ein akzeptables Maß zu re­duzieren, ohne auf die Vorteile militärisch genutz­ter Software verzichten zu müssen.

Einleitung

Streitkräfte sind für die meisten ihrer Aktivitäten auf Software angewiesen, von administrativen Aufgaben und Logistik bis hin zur Kriegsführung: So sind etwa Lagebildplattformen unverzichtbar geworden und kaum ein Panzer, Kriegsschiff oder Kampfflugzeug funktioniert ohne Software. Diese Softwareprodukte sind das Ergebnis komplexer Lieferketten aus Liefe­ranten, Dienstleistern und Softwarekomponenten, die sich der Kontrolle der Streitkräfte entziehen. Folglich hängt die Sicherheit eines Militärs auch von der Sicherheit der zahlreichen Software-Anbieter, Dienst­leister sowie Entwickler:innen und Maintainer:innen1 von Softwarekomponenten ab.

Vorfälle im militärischen Bereich haben gezeigt, dass Software-Liefer­ketten-Risiken die Kriegstüchtigkeit von Streitkräften gefährden können.

Vorfälle im militärischen Bereich haben gezeigt, dass Software-Lieferketten-Risiken die Kriegstüchtigkeit von Streitkräften gefährden können, da sie die Truppe nicht nur zu Unterbrechungen im Betriebs­ablauf zwingen, sondern sie auch Spionage und Sabotage aussetzen können: So griff der chinesische Geheimdienst zwischen 2013 und 2018 auf die Systeme der größten US-Marinewerft zu, um geistiges Eigentum zu stehlen. Russland spionierte zwischen 2019 und 2020 die Behörde aus, die für die Verwaltung des US‑Atomwaffenarsenals zuständig ist. Und 2022, am ersten Tag der russischen Invasion der Ukraine, schaltete der russische Militärgeheimdienst die Satellitenkommunikation aus, auf die die ukrai­nische Armee angewiesen war. In all diesen Fällen nahmen die Angreifer nicht direkt die gut gesicherten Streitkräfte und Rüstungsunternehmen ins Visier, sondern verschafften sich Zugang über die Software-Liefer­kette.2

Kurzum, Software-Lieferketten-Risiken sind eine Achillesferse moderner Streitkräfte und stellen eine strategische Herausforderung dar. Dennoch haben weite Teile der Bundespolitik und der Bundeswehr die Bedeutung des Themas noch nicht erkannt. Im Jahr 2021 veröffentlichte eine Gruppe von Expert:in­nen aus der deutschen Sicherheits- und Verteidigungsindustrie und dem Bundesministerium der Verteidigung (BMVg) ein Papier mit Vorschlägen zur Verbesserung der Sicherheit von IT-Lieferketten,3 doch diese wurden bisher nicht aufgegriffen. Wel­chen Risiken Streitkräfte in diesem Bereich ausgesetzt sind, hängt maßgeblich davon ab, welche Softwareprodukte sie beschaffen (und von welchen Anbietern) und wie sie diese nutzen und verwalten. Darüber ent­scheidet aktuell jedoch üblicherweise Beschaffungs- und IT-Fachpersonal ad hoc. Das muss sich ändern.

Stattdessen sollte die Bundeswehr zu einem strategischen Umgang mit Risiken der Software-Lieferkette kommen. Die Studie skizziert die vier dafür nötigen Schritte. Erstens müssen Entscheidungsträger:innen in Politik und Bundeswehr verstehen, wie Software-Lieferketten aussehen4 und welche Risiken sie ber­gen.5 Zweitens sollten sie sich bewusst werden, dass diese Risiken Streitkräfte besonders betreffen,6 weil Software für militärisches Handeln unverzichtbar geworden ist – gerade in Zeiten, in denen unter dem Stichwort »Software-defined Defense«7 militärisches Gerät immer stärker vernetzt werden soll, was die Angriffsoberfläche dramatisch vergrößert. Dabei sollten Streitkräfte aus vergangenen Vorfällen im militärischen Bereich, in denen die Software-Liefer­kette eine Rolle spielte, lernen.

Darüber hinaus zeigt die Studie – auf der Basis von Einschätzungen der Expert:innen8 und praktischen Beispielen aus verschiedenen Ländern – auf, wie politische Verantwortliche und die Bundeswehr mit Software-Lieferketten-Risiken umgehen sollten. In einem dritten Schritt sollten sie zunächst selbst Maßnahmen ergreifen, um sich vor den Bedrohungen zu schützen.9 Viertens sollten sie Software-Anbieter dazu bewegen, effektiver mit Software-Lieferketten-Risiken umzugehen.10 Mit diesen vier Schritten können Entscheidungsträger:innen in der Politik und in der Bundeswehr diese Achillesferse schützen und die Kriegstüchtigkeit der deutschen Streitkräfte sicherstellen.

Die Software-Lieferkette

Softwareprodukte haben komplexe Lieferketten. Diese umfassen alle Artefakte (wie Programmcode), Prozesse, Technologien und nicht zuletzt Menschen, die an der Herstellung eines bestimmten Softwareprodukts beteiligt sind (siehe Grafik 1, S. 10).11 Die Liefer­kette eines jeden Softwareprodukts beginnt mit seinen »Rohstoffen«, das heißt den Software­komponenten. Dabei handelt es sich um unabhängige Einheiten von Quellcode wie etwa sogenannte Biblio­theken.12 Solche Komponenten machen den Großteil des Codes vieler Softwareprogramme aus, da die Entwickler:innen häufig bereits geschriebene Code­bausteine wiederverwenden.13 Dabei spielen beson­ders die Open-Source-Software(OSS)-Community und kommerziell erhältliche Bibliotheken eine Schlüsselrolle.

Eine Person oder Organisation, die Software ent­wickelt14 (etwa ein Hersteller), kann benötigte Soft­warekomponenten auf drei Wegen beziehen: Erstens kann der Hersteller OSS-Komponenten aus einem Code-Repository wie GitHub verwenden. Dabei geht er keine vertragliche Bindung mit den Entwickler:innen der Komponente ein (und kennt sie in der Regel auch nicht).15 Zweitens kann er eine Komponente von einem anderen Unternehmen kaufen. Und drittens kann er die Komponente selbst entwickeln.

OSS ist der Gegenentwurf zu proprietärer Software, bei der der Quellcode geheim gehalten wird, da er als geistiges Eigentum gilt. Im OSS-Ökosystem hingegen entwickeln und pflegen Einzelpersonen oder Grup­pen Softwareprodukte und -komponenten und stellen sie der Allgemeinheit16 zur Verfügung, die den Quellcode einsehen, bearbeiten und die Software nutzen kann. OSS ist das Fundament des modernen Software-Öko­systems: Fast alle Softwareprodukte enthalten OSS-Komponenten17 und für bestimmte Anwendungsfälle sind OSS-Produkte führend.18 Im Gegensatz dazu können kommerziell erhältliche Bibliotheken, die von Software-Anbietern unterstützt werden, oft nicht geprüft werden und sind darauf angewiesen, dass der Anbieter Schwachstellen ausbessert.

Jede Softwarekomponente hat ihre eigene Lieferkette, da sie sich wiederum auf Bausteine oder zu­mindest auf Hilfsmittel wie etwa Compiler stützt, die für Menschen lesbaren Quellcode in maschinen­lesbaren Binärcode übersetzen. Da Softwareprodukte die Sicherheitsprobleme aller ihrer Bestandteile erben können, ist es zur Bewertung der (Un-)Sicherheit eines bestimmten Softwareprodukts erforderlich, all seine Komponenten und deren Teilkomponenten zu be­trachten.

Grafik 1

Während des Entwicklungsprozesses greifen Soft­warehersteller häufig auf externe Dienstleister zu­rück. So brauchen etwa Software-as-a-Service-An­bieter (SaaS-Anbieter) Dienstleister, die Cloud-Infra­struktur bereitstellen. Solche Dienstleister haben oft Zugang zu den Systemen ihrer Kund:innen, um ihre Dienste erbringen zu können.

Sobald das Softwareprodukt fertiggestellt ist, muss es seinen Weg zu den Endnutzer:innen finden – bei­spielsweise zur Bundeswehr. Welchen Weg es nimmt, hängt zunächst davon ab, ob die Nutzer:innen ein reines Softwareprodukt oder ein Gerät mit eingebetteter Software suchen. Die meisten Geräte mit Infor­mations- und Kommunikationsfunktionen enthalten eingebettete Software und haben daher auch immer eine Software-Lieferkette.

Zu einem reinen Softwareprodukt können End­nutzer:innen auf drei Arten Zugang erlangen: Sie können das Produkt kaufen, eine Lizenz zur Nutzung des Produkts erwerben, oder Zugang zu einer in der Cloud gehosteten Version (SaaS) erwerben. Außerdem unterscheiden sich die Lieferketten darin, ob das Produkt (oder das Nutzungsrecht) direkt vom Soft­warehersteller bezogen wird oder über Zwischen­stellen. Ersteres ist häufig der Fall bei sogenannten Commercial-off-the-Shelf-Softwareprodukten (COTS), also handelsüblichen Lösungen, die nicht speziell an die Bedürfnisse der Endnutzer:innen angepasst werden und häufig direkt von der Website des An­bieters heruntergeladen werden können. Alternativ können auch weitere Unternehmen Teil der Liefer­kette sein, wie Wiederverkäufer oder Distributoren, die das Produkt den Endkund:innen zur Verfügung stellen und oft zusätzliche Dienstleistungen wie etwa Anpassungen anbieten, oder Systemintegratoren, die Produkte verschiedener Anbieter kombinieren und an die Bedürfnisse der Kund:innen anpassen.

Kaufen Endnutzer:innen hingegen ein Gerät mit eingebetteter Software, so kaufen sie das Produkt vom entsprechenden Hersteller oder von den jeweiligen Wiederverkäufern, Distributoren oder Systemintegratoren. Der Gerätehersteller wiederum entwickelt die eingebettete Software entweder selbst oder kauft sie von einem oder mehreren Software-Herstellern ein. Im militärischen Kontext kann es sich bei solchen Geräten mit eingebetteter Software sowohl um ein­fache COTS-Geräte wie Klimaanlagen für Rechen­zentren als auch um komplexe Waffensysteme wie Kampfflugzeuge handeln.

Schließlich endet die Software-Lieferkette nicht zum Zeitpunkt des Kaufs (oder Abschluss des Nut­zungsvertrags). Vielmehr bieten Software-Hersteller üblicherweise Support für ihre Produkte an, das heißt Sicherheitsupdates und – in einigen Fällen – Up­grades, die Funktionalitäten ändern, hinzufügen oder entfernen. Sicherheitsupdates sind unerlässlich, da die meisten Softwareprodukte Schwachstellen ent­halten,19 also »Schwäche[n] in einem IT-System, die von Angreifer:innen für einen erfolgreichen Angriff ausgenutzt werden können«.20 Sobald ein Hersteller von einer Schwachstelle erfährt, kann er eine Abhilfe­maßnahme bereitstellen, etwa ein Sicherheitsupdate oder Empfehlungen für Konfigurationseinstellungen.

Dieses komplexe Geflecht aus Software-Anbietern, ihren Zulieferern, Dienstleistern und Software­komponenten bildet die Lieferkette eines jeden Soft­ware­produkts.

Risiken der Software‑Lieferkette

Software-Lieferketten bergen eine Reihe von Risiken. Diese unterscheiden sich von anderen Cybersicherheitsrisiken in einem wesentlichen Punkt: Bei »her­kömmlichen« Cybersicherheitsvorfällen verschaffen sich Bedrohungsakteur:innen üblicherweise direkt Zugang zu ihrem Ziel und erzielen dort einen Effekt (siehe Grafik 2). So versenden Angreifer:innen bei­spielsweise eine Phishing-E-Mail, um in das IT-System eines Unternehmens einzudringen und dort Ransom­ware zu installieren. Im Gegensatz dazu haben Soft­ware-Lieferketten-Risiken ihren Ursprung bei einer in der Lieferkette vorgelagerten Stelle. So nutzen Angreifer:innen etwa eine Schwachstelle in den IT‑Systemen eines Softwareherstellers aus, um dessen Update-Server unter ihre Kontrolle zu bringen. Daraufhin »kapern« sie den Update-Prozess und fügen Ransomware in das Software-Update ein, das dann auf den Systemen aller Kund:innen des Herstellers installiert wird.21

Es gibt drei Übertragungsmechanismen, mit deren Hilfe Software-Lieferketten-Risiken zu nachgelagerten Stellen in der Lieferkette (oft zu den Endnutzer:innen) wandern (siehe Grafik 2):

  1. Das Softwareprodukt selbst kann manipuliert werden, sei es zum Zeitpunkt der Installation oder durch Updates.

  2. Einzelne Komponenten des Produkts können ver­ändert werden. Im Gegensatz zu 1.) ist hierbei kein Zugriff auf die Systeme des Software-Anbieters nötig, so dass die Übertragung hier noch schwie­riger festzustellen ist.

  3. Der Zugriff auf das Produkt, der etwa Dienst­leistern gewährt wurde, kann missbraucht werden.

Letzteres sehen nicht alle Expert:innen als Problem der Software-Lieferkette an, da das betreffende Soft­ware­produkt oder seine Komponenten in solchen Fällen nicht unbedingt verändert werden; stattdessen stufen sie solche Vorfälle oft als Drittanbieter-Risiko ein. Doch trotz dieses technischen Unterschieds gibt es viele Parallelen zwischen Sicherheitsvorfällen, die sich aus Zugriffsrechten von Dritten ergeben, und solchen, in denen Dritte das Softwareprodukt oder seine Komponenten manipulieren, und vielfach kön­nen dieselben Maßnahmen beide Arten von Risiko begrenzen. Daher werden hier auch missbrauchte Zugriffsrechte als Software-Liefer­ketten-Risiko ein­gestuft.

Aus Sicht der Endnutzer:innen bringen Software-Lieferketten-Risiken vier spezielle Probleme mit sich: Erstens wirken sich entsprechende Ereignisse häufig auf sehr viele Organisationen gleichzeitig aus – zum Beispiel, wenn alle Kund:innen eines bestimmten Software-Anbieters betroffen sind.22 Zweitens gibt es in beinahe allen Software-Lieferketten Stellen mit lückenhaften Cybersicherheitsvorkehrungen, wie etwa kleine und mittlere Unternehmen (KMU) oder kleinere OSS-Projekte, die von wenigen oder nur einer Person als Hobby23 gepflegt werden. Das bedeutet, dass auch Software-Nutzer:innen mit strengen Cyber­sicherheitsmaßnahmen – wie Streitkräfte – mit hoher Wahrscheinlichkeit über die Lieferketten der von ihnen verwendeten Softwareprodukte angreifbar sind. Drittens haben Endnutzer:innen üblicherweise nur einen begrenzten Einblick in die Lieferkette und wissen daher möglicherweise nicht einmal, dass sie einer Cyberbedrohung ausgesetzt sind. Und viertens können häufig weder Endnutzer:innen noch ihre unmittelbaren Zulieferer die Ursachen von Software-Lieferketten-Risiken beheben, da das Problem bei weit vorgelagerten Stellen in der Lieferkette (bei kleineren Software-Anbietern, Dienstleistern oder dem OSS-Öko­system) liegt und nur diese Behebungsmaßnahmen durchführen können.

Grafik 2

Diese Probleme machen den Umgang mit Software-Lieferketten-Risiken zu einem dringenden Anliegen für alle Software-Nutzer:innen, insbesondere aber für solche, die – wie Streitkräfte – Wert auf ein hohes Maß an Sicherheit legen. Dabei lassen sich Software-Lieferketten-Risiken in vier Kategorien einteilen: Lieferketten-Angriffe, Angriffe von Innentäter:innen, unbeabsichtigte Fehler und fehlender Software-Support (siehe Grafik 2).

Lieferketten-Angriffe von Dritten

Bei Angriffen von Dritten auf die Lieferkette ver­schaf­fen sich Angreifer:innen, die selbst nicht Teil der Liefer­kette eines Softwareprodukts sind, Zugang zu einer Stelle in der Lieferkette, um einen Effekt bei einer nachgelagerten Stelle in der Lieferkette zu er­zielen.24

Angriffe von Innentäter:innen

Angriffe von Innentäter:innen gehen von Akteur:in­nen aus, die selbst Teil der Lieferkette eines Softwareprodukts sind. In klassischen Szenarien wenden sich Angestellte gegen ihren Arbeitgeber, sei es aus eigenem Antrieb oder unter dem Einfluss von Dritten wie ausländischen Nachrichtendiensten.25 Auch Ver­änderungen in der Eigentumsstruktur von Unternehmen können Gelegenheiten für Innentäter:innen bieten, zum Beispiel wenn eine staatliche Stelle die Kontrolle über ein Unternehmen erlangt, das Teil einer bestimmten Lieferkette ist. In international arbeitsteiligen Unternehmen können zudem – über Subunternehmer – Bürger:innen aus gegnerischen Staaten Teil der Software-Lieferkette werden, die nationalen Auskunftspflichten unterliegen oder in­strumentalisiert werden können.26

Weitere Szenarien ergeben sich aus der besonderen Struktur des OSS-Ökosystems: Da Softwarehersteller, die OSS-Komponenten verwenden, in der Regel deren Entwickler:innen und Maintainer:innen nicht kennen, haben sie einen blinden Fleck in ihrer Lieferkette, der ein Einfallstor für böswillige Innentäter:innen sein kann. Im Fall der »XZ-Hintertür«27 beispielsweise wurden zwischen 2022 und 2024 eine oder mehrere Unbekannte für die Maintenance der OSS-Kompo­nente »XZ Utils« verantwortlich und fügten eine Hintertür ein.28 Die beliebte Bibliothek wird unter anderem für den Fernzugriff auf Linux-Server ver­wendet. Durch diese Hintertür hätten die Verantwortlichen die Kontrolle über die betroffenen Geräte übernehmen können – darunter die meisten Server weltweit.29 Glücklicherweise wurde der Schadcode dank mehrerer Zufälle zeitnah entdeckt und entfernt, bevor er seine Wirkung entfalten konnte.30 Doch bösartige OSS-Komponenten sind insgesamt ein weit­verbreitetes Problem.31 Solche Komponenten stehen häufig ganz am Anfang vieler Software-Lieferketten, so dass ein Sicherheitsvorfall enorm weitreichende Auswirkungen haben kann.

Unbeabsichtigte Fehler

Software-Lieferketten-Risiken können auch ohne vor­sätzliche Handlungen von Dritten entstehen, etwa durch unbeabsichtigte Fehler von Stellen in der Liefer­kette. OSS-Entwickler:innen und -Main­tainer:innen machen ebenso Fehler wie die Hersteller proprietärer Software. Diese Fehler können zu Schwachstellen im Softwareprodukt führen, die später von böswilligen Akteur:innen ausgenutzt werden können.32

Fehlender Software-Support

Das vierte Risiko, das Software-Lieferketten mit sich bringen, liegt in fehlendem Software-Support durch den Hersteller. Ohne funktionale Upgrades sind manche Produkte mit der Zeit nicht mehr oder nur eingeschränkt nutzbar. Ohne Sicherheitsupdates sammeln sich in Softwareprodukten bekannte, aber nicht behobene Schwachstellen an. Insgesamt wird Software ohne Support also mit der Zeit ein leichtes Angriffsziel. Und wenn SaaS-Anbieter ihre Dienste für alle oder bestimmte Nutzer:innen einstellen, haben diese sogar unmittelbar keinen Zugriff mehr auf die Software.

Der Support für Softwareprodukte kann aus verschiedenen Gründen enden oder fehlen: Weil die Nutzer:innen nicht (mehr) für die Produktwartung zahlen; weil der Hersteller den Support einstellt;33 weil der Hersteller in Konkurs geht oder die (oft einzige34) Person, die ein OSS-Projekt pflegt, die Arbeit daran aufgibt; oder weil der Hersteller den Support für bestimmte End­nutzer:innen abbricht, zum Beispiel als Folge von Sanktionen. Und selbst wenn ein Anbieter ein Produkt noch unterstützt, kann es sein, dass eine eingebettete OSS-Komponente nicht mehr gewartet wird – der Anbieter weiß das aber möglicherweise nicht.

Die besondere Bedrohung von Streitkräften

Die vier Arten von Software-Lieferketten-Risiken können alle Organisationen betreffen, doch Streitkräfte sind besonders verwundbar.

Bedeutung von Software für Streitkräfte

Streitkräfte nutzen ein breites Portfolio verschiedener Softwareprodukte (siehe Grafik 3). Dabei verwenden sie einerseits, wie zivile Organisationen, Software zur Prozessunterstützung und zur Verarbeitung von Informationen. Zu diesen unterstützenden Anwendungen gehören beispielsweise Office-Programme oder Warenwirtschaftssysteme. Andererseits brau­chen Streitkräfte Gefechtsfeldanwendungen wie Lagebildplattformen oder Führungssysteme. Darüber hinaus arbeiten Streitkräfte mit Verschlusssachen und die Systeme, die solche Daten verarbeiten, müssen be­sondere Sicherheitsanforderungen erfüllen. Schließ­lich sind all diese Anwendungen auf eine ganze Reihe anderer Softwaretypen angewiesen, wie etwa Betriebs­systeme und Datenbanken.

Kurz gesagt: Software ist für die meisten militärischen Aktivitäten unverzichtbar. Auch der Großteil militärischen Geräts ist auf Software angewiesen. So ermöglicht Software häufig Funktionserweiterungen, etwa von Waffensystemen wie Kriegsschiffen, deren Lebensdauer dadurch verlängert werden kann. Folg­lich tangieren Software-Lieferketten-Risiken das gesamte Spektrum militärischer Aktivitäten. Die Aus­wirkungen entsprechender Vorfälle hängen dabei von der Art der betroffenen Software ab. Selbst die Kom­promittierung eines COTS-Produkts kann Nach­richtendiensten wertvolle Informationen liefern, aber Sabotageoperationen sind viel gefährlicher, wenn sie auf Gefechtsfeld­anwendungen wie Waffensysteme abzielen.

Die Abhängigkeit wird weiter zunehmen

Software spielt auch heute schon eine wichtige Rolle in Waffensystemen. Allerdings sind diese Großgeräte bisher nur begrenzt vernetzt – miteinander, mit Sen­soren und mit Netzwerken wie dem Internet.35 Zu einem gewissen Grad mindert diese mangelnde Ver­netzung bestehende Software-Lieferketten-Risiken.36

Streitkräfte, die ohne Software ihren Auftrag nicht erfüllen können, wer­den den Risiken der Software-Liefer­kette noch stärker ausgesetzt sein.

Doch viele Streitkräfte, darunter die Bundeswehr, streben danach, ihre Prozesse noch stärker zu digita­lisieren, immer mehr Geräte noch intensiver zu ver­netzen und Software ins Zentrum des Gefechtsfelds zu stellen. Das Konzept »Software-defined Defense« (SDD)37 beschreibt eine Zukunft, in der militärisches Großgerät über eine zentrale Softwareplattform ge­steuert werden kann und die Funktionalität militä­rischer Ausrüstung durch Software-Updates anstelle von Hardware-Modifikationen verändert wird.

Grafik 3

Noch sind die meisten Streitkräfte weit davon ent­fernt, dieses Konzept umzusetzen,38 doch einige haben bereits erste Schritte in diese Richtung unter­nommen.39 Das Konzept erlaubt daher Rückschlüsse auf die Bedeutung von Software für die Streitkräfte von morgen. Streitkräfte, die ohne Software als Rück­grat ihren Auftrag nicht erfüllen können, werden den Risiken der Software-Lieferkette noch stärker aus­gesetzt sein.

Verschärfte Bedrohung durch militärische Besonderheiten

Darüber hinaus erhöhen vier militärische Besonderheiten die Software-Lieferketten-Risiken für Streitkräfte. Erstens ist deren oberste Aufgabe die Kriegsverhütung, basierend auf der Fähigkeit zur wirk­samen Kriegsführung. Dementsprechend können Lieferketten-Angriffe Menschen, Infrastruktur und Ressourcen in Gefahr bringen. Diese Gefährdung kann unmittelbar sein, etwa durch einen Angriff auf Software, die Waffensysteme steuert, aber auch in­direkt, indem beispielsweise gegnerische Nachrichten­dienste Informationen über Stützpunkte sammeln. Da militärische Betriebsabläufe auch unter außer­gewöhnlichen Umständen funktionieren müssen, können auch unbeabsichtigte Fehler – die beispielsweise die Logistiksysteme stören – oder fehlender Software-Support dramatische Folgen haben.

Zweitens sind Streitkräfte häufig von IT-Systemen abhängig, die anderen gehören und von diesen be­trieben werden.40 Bei der Landesverteidigung ist die militärische Logistik oft auf zivile kritische Infrastrukturen angewiesen und steht mit diesen in enger Wechselwirkung,41 und bei der Bündnisverteidigung gilt Ähnliches für die Systeme der Verbündeten. Dem­entsprechend stehen Streitkräfte vor dem Problem, dass sie Teile ihrer Software-Lieferkette weder kennen noch in diesem Bereich selbst Risikomanagement be­treiben können.

Drittens kauft das Militär nicht nur militärisches Gerät, sondern auch Software häufig bei spezialisierten Herstellern ein und ist dann von diesen Anbietern und ihren proprietären Technologien abhängig (»vendor lock-in«).42 Diese Abhängigkeit bringt die Streitkräfte in eine schwache Verhandlungsposition gegenüber ihren Anbietern, wenn es beispielsweise darum geht, striktere Maßnahmen für den Umgang mit Risiken der Software-Lieferkette durchzusetzen. Außerdem haben Streitkräfte oft keine Alternative, wenn kein Software-Support (mehr) bereitgestellt wird.

Viertens müssen Streitkräfte bei der Beschaffung von Software Beschaffungsregeln befolgen (auch auf EU-Ebene).43 Diese Beschaffungsprozesse sind nicht nur langsam und involvieren viele Stellen, sondern sie wurden auch für Hardware – nämlich Waffen­systeme – entwickelt und lassen daher oft die Geschwindigkeit und Flexibilität ver­missen, die für die Beschaffung von Software ent­scheidend sind.

Zusammenfassend lässt sich sagen, dass Software-Lieferketten-Risiken zwar alle Organisationen betref­fen, ihre potentiellen Auswirkungen für das Militär jedoch besonders gravierend sind.

Die Auswirkungen vergangener Software-Lieferketten-Vorfälle auf Streitkräfte

Die Streitkräfte verschiedener Staaten haben bereits die verheerende Wirkung von Software-Lieferketten-Vorfällen zu spüren bekommen (siehe Grafik 4). Da­bei kam es sowohl zu Beeinträchtigungen von Betriebsabläufen als auch zu Angriffen, die der Spio­nage und Sabotage dienten.

Beeinträchtigung von Betriebsabläufen

Selbst unbeabsichtigte Fehler von Softwareherstellern können die Betriebsabläufe von Organisationen welt­weit zum Erliegen bringen: Im Jahr 2024 veröffentlichte das US-amerikanische Software-Unternehmen CrowdStrike, das sich auf Cybersicherheitsanwen­dungen spezialisiert, ein fehlerhaftes automatisches Update für alle Kunden weltweit, die seine Software »Falcon« verwenden.44 Geräte, die das Update erhalten hatten, starteten automatisch neu und erlitten während des Starts einen Systemabsturz, so dass sie vorübergehend nicht mehr funktionsfähig waren. Die schätzungsweise 8,5 Millionen betroffenen Geräte weltweit mussten manuell zurückgesetzt werden, was bei Geräten mit Festplattenverschlüsselung so­gar physischen Zugang zu jedem einzelnen Gerät erforderte.45 Das US-Verteidigungsministerium und

Grafik 4

mehrere Verteidigungsunternehmen nutzten »Falcon«,46 aber es gab »keine Auswirkungen auf den Betrieb des US-Verteidigungsministeriums«.47 Den­noch zeigte der Vorfall, welche Folgen selbst ein versehentlicher Fehler eines Unternehmens in der Software-Liefer­kette haben kann.

Darüber hinaus wird gewisses militärisches Gerät ohne regelmäßige Software-Upgrades unbrauchbar: Das ukrainische Militär verfügt über F-16-Kampf­flugzeuge, deren Modul für elektronischen Kampf Radar-Jamming während des Flugs ermöglicht.48 Diese Fähigkeit verhindert, dass gegnerische Bodenstationen ein Flugzeug ins Visier nehmen, um es mit Raketen abzuschießen. Für eine wirksame Störung des Radars muss die entsprechende Software regel­mäßig auf die – mit der Zeit wechselnden – Radarfrequenzbereiche angepasst werden, die von den gegnerischen Boden­stationen verwendet werden. Ohne diese Up­grades würden die Flugzeuge ihre Abwehrfähigkeit verlieren und müssten mutmaßlich am Boden bleiben.49 Für die ukrainischen F-16 ist bisher nur die US-Luftwaffe in der Lage, diese Software-Updates bereitzustellen.50 Im März 2025 stellte die Trump-Regierung ihre Militär­hilfe für die Ukraine vorübergehend ein, wozu auch der Software-Support für die F-16 gehörte.51 Obwohl die Trump-Administration ihren Kurs zügig wieder änderte,52 zeigt diese Episode, welche Folgen man­gelnder Software-Support für die Einsatzbereitschaft großer Waffensysteme hat.

Wirtschaftsspionage, politische Spionage und Sabotage

Neben diesen Fällen, in denen ganz ohne Angreifer:in­nen große Schäden entstehen können, bietet die Software-Lieferkette auch Einfallstore für böswillige Akteure, die es auf Streitkräfte oder die Rüstungs­industrie abgesehen haben (siehe Grafik 4). Erstens betreiben staatliche Akteur:innen oder private Unternehmen Wirtschaftsspionage. Sie stehlen also geistiges Eigentum. Zwischen mindestens 2013 und 2018 stahlen Personen, die mit dem chinesischen Ministerium für Staatssicherheit in Verbindung stehen, im Rahmen der »Cloud Hopper«-Kampagne geistiges Eigentum von westlichen Unternehmen. Dabei infiltrierten sie Cloud-Anbieter und nutzten deren Zugang zu den Systemen ihrer Kunden aus.53 Zu den Zielen der Kampagne gehörte Huntington Ingalls Industries, die größte Marinewerft der USA, die unter anderem nuklear angetriebene U-Boote für die US Navy baut.54

Zweitens führen Geheimdienste politische Spio­nage durch. Zwischen 2019 und 2020 schleuste der russische Auslandsgeheimdienst SVR im Rahmen der »Sunburst«-Kampagne Schadsoftware in Updates des Unternehmens SolarWinds ein.55 Dessen Software »Orion« dient zur Überwachung und Verwaltung von Infrastrukturen. Über den bösartigen Code, der per Update an die »Orion«-Nutzer:innen verteilt wurde, verschaffte sich der SVR unter anderem Zugang zum US-Verteidigungsministerium und zur National Nuclear Security Administration, die das US-Atom­waffenarsenal verwaltet.56

Drittens nutzen Nachrichtendienste oder Streitkräfte Schwachstellen in Software-Lieferketten zu Sabotagezwecken aus, um Netzwerke, Systeme oder Dienste vorübergehend zu stören oder dauerhaft zu zerstören. So kaperte etwa der russische Militär­geheim­dienst GRU den Update-Mechanismus des Satellitenkommunikationsanbieters Viasat.57 Am 24. Februar 2022 – dem ersten Tag der russischen Vollinvasion der Ukraine – verschickte der GRU per automatischem Update Schadsoftware an die Modems von Viasat-Kund:innen.58 Diese überschrieb wichtige Daten im Speicher der Modems und machte die Geräte dadurch funktionsunfähig.59 Mutmaßliches Ziel dieser Operation waren die ukrainischen Streit­kräfte, die Viasats Dienste für ihre Konnektivität auf dem Gefechtsfeld nutzten. Die genauen Auswirkungen des Angriffs sind unklar, unter anderem, weil die ukrainischen Streitkräfte auch Zugang zu den Satel­litenkommunikationsdiensten des Unternehmens Starlink hatte.60

Zudem ist denkbar, dass Cyberkriminelle militärische Ziele anvisieren, um einen finanziellen Vorteil zu erzielen. Bisher wurden allerdings keine finanziell motivierten Software-Lieferketten-Angriffe auf mili­tärische Ziele öffentlich bekannt. Das mag daran liegen, dass diese in der Regel besser gesichert sind als andere Sektoren und Regierungsstellen oft nicht mit Kriminellen verhandeln (etwa über Ransomware-Zahlungen). Außerdem werden solche Angriffe auf militärische Ziele häufig nicht publik gemacht. Daher ist davon auszugehen, dass viele Vorfälle schlicht nicht veröffentlicht sind – und möglicherweise auch bekannte Vorfälle eine nicht öffentlich bekannte militärische Dimension hatten.

Schließlich ist der Weg über die Software-Liefer­kette für Angriffe auf militärische Ziele nicht immer das Mittel der Wahl. Für Spionage- oder Sabotage­operationen kann es einfacher sein, Innentäter:innen schlicht durch Bezahlung oder Erpressung zu gewin­nen. Und um militärische Ziele in einem bewaffneten Konflikt zu erreichen, ist es oft günstiger und schnel­ler, gegnerische Stellungen mit kinetischen Mitteln auszuschalten als durch Cyber­operationen.61

Wie sich Streitkräfte selbst vor Risiken der Software-Liefer­kette schützen können

Vergangene Vorfälle zeigen, dass Risiken der Soft­ware-Lieferkette die Kriegstüchtigkeit der Bundeswehr beeinträchtigen können. Angesichts dessen sollte die Bundeswehr die Risiken erkennen und Handlungsmöglichkeiten identifizieren und bewerten.

Die in diesem und dem folgenden Kapitel dar­gestellten Maßnahmen sind das Ergebnis einer Analyse, die in drei Schritten erfolgt. Zunächst wird auf Basis der zuvor herausgearbeiteten Risiken und unter Berücksichtigung der besonderen Bedrohung von Streitkräften festgestellt, welche Sicherheits­probleme bestehen. Anschließend wird, sofern mög­lich, durch einen internationalen Vergleich geprüft, mit welchen Maßnahmen andere Streitkräfte bereits Erfahrungen gesammelt haben. Zumeist liegen solche Erfahrungswerte nicht vor; in dem Fall wird zurückgegriffen auf die Empfehlungen internationaler Ex­pert:innen, die in mehr als 65 Interviews und einem Workshop eingeholt wurden.62 Und schließlich werden vor dem Hintergrund der internationalen Erfahrungen und der Meinungen von Expert:innen Empfehlungen ausgesprochen, welche Maßnahmen BMVg und Bundeswehr umsetzen sollten.

Die Maßnahmen setzen dabei an zwei Stellen an. Erstens können Streitkräfte bei ihren eigenen Aktivi­täten beginnen und selbst Maßnahmen ergreifen, um sich zu schützen. Die dazu notwendigen Schritte (siehe Grafik 5) werden in diesem Kapitel skizziert. Zweitens können Politik und Streitkräfte Vorgaben für Software-Anbieter entwickeln, wie diese ihre Produkte weniger anfällig für diese Risiken gestalten und außerdem Streitkräfte bei ihrem Risikomanage­ment unterstützen können. Wie entsprechende Vor­gaben aussehen können und auf welchen Wegen Politik und Streitkräfte die Anbieter dazu bringen können, sie auch umzusetzen, wird im folgenden Kapitel erläutert. Für einen effektiven Umgang mit militärischen Software-Lieferketten-Risiken müssen beide Ansätze – die ohnehin kom­plementär sind – miteinander kombiniert werden.

Die im Folgenden vorgeschlagenen Maßnahmen würden für viele Streitkräfte tiefgreifende Veränderungen mit sich bringen und erhebliche Ressourcen erfordern. Dementsprechend ist es denkbar, dass in einigen Fällen Widerstand aufkommt. In solchen Fällen können die Maßnahmen zunächst im kleinen Maßstab in einer geeigneten militärischen Einheit getestet werden.63

Festlegung des angemessenen Schutzniveaus

Auch wenn die Auswirkungen von Risiken der Soft­ware-Lieferkette verheerend sein können, kann die Antwort der Bundeswehr nicht lauten, gänzlich auf Software zu verzichten oder Abhängigkeiten von Dritten in der Software-Lieferkette vollständig zu vermeiden. Angesichts der Komplexität des Software-Ökosystems wäre ein solcher Ansatz kaum realisierbar und höchst ineffizient. Stattdessen sollte die Bundeswehr zu einem bewussten Umgang mit den Risiken gelangen.

Dabei müssen Politik und Bundeswehr eine grundlegende Güterabwägung vornehmen.64 Einerseits sollte militärisch genutzte Software nur bekannte und akzeptable Sicherheitsrisiken aufweisen; andererseits sollte sie eine bestimmte Funktionalität bereitstellen, zu einem angemessenen Preis erhältlich sein und schnell eingesetzt und aktualisiert werden können. Hier gilt es, Entscheidungen zu treffen, da diese Ziele oft im Konflikt stehen: Viele Maßnahmen, die Soft­ware-Lieferketten-Risiken reduzieren, machen das Produkt teurer, beispielsweise wenn statt einer ver­fügbaren OSS-Komponente eine Funktionalität von Grund auf neu entwickelt wird. Zudem verlangsamen viele Risikomanagement-Maßnahmen den Beschaffungs- und Bereitstellungsprozess. Das ist beispielsweise der Fall, wenn Streitkräfte Sicherheitstests für Updates durchführen, bevor sie sie in der Fläche aus­rollen, oder wenn sie (unter hohem Personalaufwand65) vor der Nutzung eines Produkts Schwachstellen in darin verwendeten OSS-Komponenten schließen.

Grafik 5

In der Bundeswehr gibt es nicht die eine maßgebliche Instanz, die für die Beschaffung und das Management von Software verantwortlich ist.

Es geht also nicht darum, Software-Lieferketten-Risiken um jeden Preis zu senken. Ein Software­produkt mit sehr geringem Risiko ist nutzlos, wenn es nicht die benötigte Funktionalität bietet, zu teuer ist oder schlicht zu spät bereitgestellt oder aktualisiert wird. Stattdessen müssen BMVg und Bundeswehr ge­meinsam festlegen, welches Schutzniveau angestrebt werden soll. Mit Blick auf das diverse militärische Software-Portfolio sollte das anvisierte Schutzniveau je nach Software-Typ differenziert werden. So erfor­dern etwa Produkte, die auf dem Gefechtsfeld genutzt werden oder die der Verarbeitung von Verschluss­sachen dienen, mehr Schutzmaßnahmen. Entsprechend sollten die genannten Maßnahmen zielgerichtet auf Softwareprodukte in bestimmten Einsatz­bereichen angewandt werden.

Handlungsfähigkeit

Der erste Schritt hin zu einem wirkungsvollen Um­gang mit Software-Liefer­ketten-Risiken ist, handlungsfähig zu werden: Verteidigungsministerium und Streitkräfte sollten speziellen Stellen und Personen klare Rollen und Verantwortlichkeiten für das Thema zuweisen und Leitlinien entwickeln, die entsprechende Prioritäten festlegen. Auch wenn sich eine Streit­kraft wohl kaum nur mit Blick auf die Begrenzung der Risiken, die mit Software-Lieferketten verknüpft sind, umstrukturieren wird, sollte die Problematik doch oben auf der Agenda stehen, sobald eine Re­organisation ansteht. Die derzeitige Reorganisation des Bereichs Cyber- und Informationsraum (CIR) der Bundeswehr nach seiner Erhebung zur Teilstreitkraft bieten eine solche Gelegenheit.

Schaffung klarer Verantwortlichkeiten

Für viele der hier vorgeschlagenen Maßnahmen ist es wichtig, dass eine Person die Verantwortung für den Umgang mit Software-Lieferketten-Risiken trägt.66 Eine solch klare Zuweisung von Verantwortlichkeit findet sich etwa im niederländischen Verteidigungsministerium, in dem eine Zentralstelle für die ge­samte IT-Beschaffung und die Verwaltung von Soft­ware während des kompletten Lebenszyklus zuständig ist.67 Diese Abteilung ist dadurch in der Lage, stra­tegisch auf den Umgang mit Risiken der Software-Lieferkette zu blicken. Im Gegensatz dazu gibt es in der Bundeswehr nicht die eine maßgebliche Instanz, die für die Beschaffung und das Lebenszyklusmanage­ment von Software verantwortlich ist, sondern die Zuständigkeit ist auf viele unterschiedliche Stellen verteilt (siehe Infokasten).

Zuständigkeiten für den Umgang mit Software-Lieferketten-Risiken in der Bundeswehr

■ Die Abteilung Innovation und Cyber (IC) im BMVg ist für die politische Steuerung zuständig.

■ Die BWI GmbH, ein IT-Dienstleister im Besitz des BMVg, beschafft und betreibt vor allem administrative IT-Anwendungen.

■ Für Softwareprodukte, die nicht von der BWI beschafft werden, definiert das Zentrum Digitalisierung der Bundeswehr und Fähigkeitsentwicklung Cyber- und Informationsraum (ZDigBw) die Fähigkeitsanforde­rungen. Für Geräte (einschließlich solcher mit ein­gebetteter Software) nimmt das Planungsamt der Bundeswehr diese Aufgabe wahr.

■ Auf der Grundlage dieser Fähigkeitsanforderungen beschaffen die Projektmanager:innen im Bundesamt für Ausrüstung, Informationstechnik und Nutzung der Bundeswehr (BAAINBw) Produkte.

■ Das für Baumaßnahmen zuständige Bundesamt für Infrastruktur, Umweltschutz und Dienstleistungen der Bundeswehr (BAIUDBw) beschafft Soft- und Hardware für die Gebäudetechnik und IT-Infrastruktur.

■ Die Wehrtechnische Dienststelle für Informations­technologie und Elektronik (WTD 81) und eine Ab­teilung im ZDigBw testen und bewerten ausgewählte Softwareprodukte.

■ Das Zentrum für Cyber-Sicherheit der Bundeswehr (ZCSBw) ist für die Erkennung von Cybersicherheits­vorfällen und die Reaktion zuständig. Zu seinen Auf­gaben gehört darüber hinaus das Sammeln und Aus­werten von Informationen über Software-Schwach­stellen und die Akkreditierung von IT-Produkten.

■ In allen Dienststellen ist das IT-Fachpersonal für das Lebenszyklusmanagement der Softwareprodukte in ihrem Portfolio verantwortlich.

Auch die Bundeswehr sollte einem Dienstposten die Verantwortung für alle Facetten von Software-Liefer­ketten-Risiken übertragen. Die entsprechende Person sollte das Thema gegenüber der militärischen Füh­rung ansprechen und die Umsetzung der hier vor­geschlagenen Maßnahmen überwachen. Um den Aufbau zusätzlicher Verwaltungsstrukturen zu vermeiden, sollte die Verantwortung der oder dem Chief Information Security Officer der Bundeswehr (CISOBw) übertragen werden. Diese Position ist bisher verantwortlich für die Informationssicherheit der Bundeswehr und in diesem Bereich weisungsbefugt gegenüber allen Stellen der Bundeswehr. Entscheidend ist, dass der verantwortlichen Person ausreichend Personal zur Verfügung gestellt wird und sie sich gegen andere Leitungspersonen durchsetzen kann, etwa wenn es um die Verteilung von Geldern geht.

Darüber hinaus sollten die für die Software­beschaffung zuständigen Stellen (BAAINBw, BAIUDBw und BWI) Beauftragte einsetzen, deren Hauptaufgabe der Umgang mit Software-Lieferketten-Risiken ist und die das Beschaffungspersonal in die Lage versetzen, die hier formulierten Maßnahmen in die Praxis um­zusetzen. Zudem sollte auch eine Person im BMVg explizit zuständig für das Thema sein.

Entwicklung von Leitlinien für den Um­gang mit Software-Lieferketten-Risiken

Zusätzlich zeigt aus Sicht internationaler Expert:in­nen der Vergleich mit Themenfeldern wie IT-Sicher­heit allgemein, dass Streitkräfte Leitlinien für den Umgang mit Software-Lieferketten-Risiken brauchen. Allerdings hat bisher kein Militär entsprechende um­fassende Leitlinien veröffentlicht.

Deshalb sollten BMVg und Bundeswehr solche Leitlinien entwickeln. Zusätzlich zu spezifischen Punk­ten, die in den folgenden Abschnitten skizziert werden, sollten diese Leitlinien Orientierung bieten für das angestrebte Schutzniveau; für die Bewertung der Kritikalität eines Softwareprodukts, um den Grad des akzeptierten Risikos und der zu investierenden Ressourcen zu bestimmen; und für die Identifizierung von und den Umgang mit Abhängigkeiten von einzelnen Komponenten, Lieferanten68 oder Staa­ten69. Darüber hinaus sollten Streitkräfte möglichst viele der in diesem und dem folgenden Kapitel be­sprochenen Prozesse und Regeln in Dienstvorschriften verankern. Der oder die CISOBw sollte die Leitlinien umsetzen und ihre Wirksamkeit regelmäßig bewerten. Statt eines eigenen Dokuments können diese Leit­linien auch in bestehende Leitlinien zur IT-Sicherheit integriert werden.

Entwicklung von Leitlinien für die militärische Nutzung von Open-Source-Software

Angesichts der entscheidenden Rolle, die OSS bei nahezu allen Softwareprodukten spielt, muss für einen bewussten Umgang mit den Risiken der Soft­ware-Lieferkette auch das OSS-Ökosystem berücksichtigt werden – als Quelle von Bedrohungen wie von Lösungen. Da das OSS-Ökosystem anders funktioniert als das von proprietärer Software, sind eigene Leit­linien für den militärischen Einsatz von OSS nötig.70 Das US-Verteidigungsministerium hat bereits um­fang­reiche entsprechende Dokumente erarbeitet.71

Auch BMVg und Bundeswehr sollten Leitlinien für die militärische Nutzung von OSS entwickeln. Ein solches Dokument sollte Ziele und Maßnahmen definieren, die richtungsweisend sind für die Koordi­nation und – sofern gewünscht – Förderung des Einsatzes von OSS-Produkten durch die Bundeswehr. Am Anfang sollten eine Bestandsaufnahme der ver­wendeten OSS-Produkte und -Komponenten und eine Bewertung ihrer Kritikalität und Sicherheit stehen. Begleitet werden sollte dieser Prozess von einem Dialog mit Herstellern, die in ihren Produkten OSS-Komponenten verwenden. Zudem sollte dem Fach­personal die Beschaffung und Nutzung von OSS-Pro­dukten erleichtert werden, indem OSS-spezifische Beschaffungsanforderungen angepasst und Musterverträge, Nutzungsstrategien und Sicherheitsbewertungen bereitgestellt werden. Darüber hinaus sollte das Dokument spezifizieren, wie die Bundeswehr zur Absicherung kritischer OSS-Komponenten beitragen kann, indem sie entweder andere Organisationen für eine entsprechende Tätigkeit bezahlt72 oder eigenes IT-Fachpersonal selbst an OSS-Projekten mitwirkt.73 Schließlich sollten die Leitlinien im Einklang mit allgemeinen Regierungsgrundsätzen zum Einsatz von OSS stehen.74

Einrichtung eines militärischen Open Source Program Office

Eine neue Struktur kann helfen, die in den Leitlinien gesteckten Ziele zu erreichen – etwa in Form eines Open Source Program Office (OSPO), wie es von vielen Unternehmen und einigen Regierungen75 eingerichtet wurde. Ein OSPO ist eine zentrale Anlaufstelle für Fragen zu OSS-Prozessen und zur OSS-Nutzung inner­halb einer Organisation.76 In vielen Streitkräften nimmt ausgewähltes Personal schon einzelne OSPO-Funktionen wahr, aber bisher hat noch keine Streit­kraft ein eigenes OSPO etabliert.

Wenn sich die Bundeswehr dazu entschließt, ein OSPO einzurichten, sollte sie auf eine schlanke Struk­tur achten, in der das OSPO als zentrale Anlaufstelle für OSS-bezogene Fragen dient – beispielsweise für Beschaffungs- und IT-Fachpersonal –, aber die Ver­antwortung für operative Aufgaben wie die Über­wachung kritischer OSS-Komponenten bei den Dienst­stellen verbleibt. Ein Bundeswehr-OSPO sollte im engen Austausch stehen mit dem sich in Gründung befindlichen OSPO im Bundesamt für Sicherheit in der Informationstechnik (BSI)77 und dem Zentrum für Digitale Souveränität der öffentlichen Verwaltung (ZenDiS),78 das vom Bundesministerium des Innern aufgebaut wurde, um OSS in die Verwaltung zu tragen.79 So kann das Fachwissen dieser Stellen für die Bundeswehr nutzbar gemacht werden. Zudem können »OSPO-Botschafter:innen«80 in den verschiedenen Dienststellen Bedarfe für OSS-Lösungen und Beratung ermitteln und die Arbeit des OSPO in der gesamten Bundeswehr verankern.

Einrichtung interner Prozesse

Neben dem Aufbau dieser Strukturen müssen Orga­nisationen, die sich vor den Risiken der Software-Lieferkette schützen möchten, interne Prozesse auf­bauen, die die Ideen in die Tat umsetzen.81 Für Streit­kräfte sind zwei Prozesse vorrangig: Das Sammeln verschiedener Informationen über die genutzten Softwareprodukte und die Überwachung des Support-Status der verwendeten Softwareprodukte. In beiden Bereichen hat die Bundeswehr bisher keine aus­reichen­den Prozesse etabliert.

Dabei ist jedoch zu beachten, dass die im Folgenden beschriebenen Prozesse nicht starr in der gesam­ten Bundeswehr ausgerollt werden sollten – schließ­lich ist die Bundeswehr, wie die meisten Streitkräfte, dezentral organisiert und die Bedürfnisse der verschie­denen Dienststellen unterscheiden sich voneinander. Vielmehr sollte der oder die CISOBw zusammen mit dem ZCSBw Musterprozesse entwickeln, Anleitungen und Vorlagen bereitstellen, die Umsetzung der Pro­zesse kontrollieren und ihre Wirksamkeit regelmäßig bewerten. Auf dieser Grundlage können dann die verschiedenen Dienststellen selbst Prozesse einrichten, die an ihre Bedürfnisse angepasst sind.

Neben diesen Prozessen, die speziell auf Software-Lieferketten-Risiken ausgerichtet sind, braucht die Bundeswehr solide Prozesse im Bereich Cybersicherheit, wie etwa die Vorfallsbearbeitung und die Ver­arbeitung von Informationen über Software-Schwach­stellen.82 Beides fällt in die Zuständigkeit des ZCSBw, dessen Ausstattung daher entscheidend ist für die Cybersicherheit der Bundeswehr insgesamt – nicht nur, aber auch mit Blick auf Software-Lieferketten-Risiken.

Sammeln von Informationen

Viele Angriffe auf die Software-Lieferkette werden dadurch ermöglicht, dass Softwareprodukte Schwachstellen haben. Die Ausnutzung von Schwachstellen, die dem Software-Anbieter noch unbekannt sind (so­genannte Zero-Days), lässt sich nur mit großem Auf­wand verhindern. Doch Angriffe, die bereits bekannte Schwachstellen ausnutzen, kann die Bundeswehr in vielen Fällen unterbinden – wenn die richtigen Informationen vorliegen. Dazu zählen vor allem:

  1. Ein Inventar aller von der Bundeswehr verwendeten Softwareprodukte,

  2. Informationen über Schwachstellen in Softwarekomponenten,

  3. Sogenannte software composition information, die Aufschluss darüber gibt, aus welchen Komponenten die verwendeten Softwareprodukte bestehen, und

  4. Informationen über die Ausnutzbarkeit von Schwachstellen (vulnerability exploitability informa­tion), die anzeigen, ob eine bestimmte Schwach­stelle in einem bestimmten Softwareprodukt tat­sächlich ein Sicherheitsrisiko darstellt.83

Das IT-Fachpersonal muss nur dann Maßnahmen ergreifen, um eine Schwachstelle zu schließen, wenn es feststellt, dass die Bundeswehr ein Produkt ver­wendet, das auf einer Komponente beruht, in der eine bestimmte Schwachstelle vorhanden und auch ausnutzbar ist.

Bisher hat die Bundeswehr nur für die hier an zweiter Stelle genannte Art von Informationen einen zuverlässigen Prozess etabliert, nämlich um Infor­mationen über Schwachstellen zu erhalten und mit anderen zu teilen. Zu diesem Zweck ist sie Teil ent­sprechender Formate im Rahmen der Nato und natio­naler Cybersicherheitsbehörden wie dem BSI und bilateraler oder multilateraler Arrangements mit mili­tärischen oder zivilen Stellen aus anderen Staaten.

Im Gegensatz dazu müssen für das Sammeln der anderen drei Arten von Informationen erst noch Prozesse aufgebaut und automatisiert werden. Was ein Software-Inventar betrifft, so hat die Bundeswehr – wie viele andere Streitkräfte – keinen vollstän­digen Überblick über alle Softwareprodukte, die sie verwendet, da sie diese (teilweise) dezentral beschafft. Mit Blick auf mögliche Angriffe sollte auch kein zen­trales Register geführt werden. Vielmehr sollte jede Dienststelle ihr Inventar in einem standardisierten Datenformat führen, so dass Daten leicht abgefragt und verglichen werden können.

Ebenso fehlen den meisten Streitkräften – wie auch der Bundeswehr – Informationen über die Zu­sammensetzung der verwendeten Softwareprodukte. Das liegt daran, dass Software in der Regel ohne voll­ständige Informationen über ihre Komponenten bereitgestellt wird.84 Solche Informationen können Anbieter und OSS-Projekte in Form einer sogenannten Software Bill of Materials (SBOM) teilen, also »einer maschinenlesbaren Datei, die Lieferkettenbeziehungen und Details der in einem Softwareprodukt verwendeten Komponenten enthält«.85 Militärs können SBOM-Daten entweder von ihren Lieferanten oder OSS-Projekten erhalten oder kostenpflichtige Tools von Drittanbietern verwenden, um selbst SBOMs zu erstellen.86 Da bisher viele SBOMs keine gute Datenqualität aufweisen,87 sollte der oder die CISOBw Mindestanforderungen für SBOMs fest­legen, an denen sich Software-Anbieter orientieren müssen. Diese Anforderungen sollten sich an einem Rahmendokument88 des BSI orientieren. Der oder die CISOBw sollte zudem sicherstellen, dass alle Dienststellen Prozesse etabliert haben, um Informationen über die Zusammensetzung von Softwareprodukten auswerten zu können, und sich die verschiedenen Dienststellen untereinander austauschen, um erhal­tene Informationen zusammenzuführen.

Was schließlich die Informationen zur Ausnutzbarkeit von Schwachstellen betrifft, so trägt das IT-Fachpersonal der Bundeswehr – wie in vielen ande­ren Streitkräften auch – diese Informationen derzeit manuell zusammen, da Software-Anbieter diese Daten nicht in einem maschinenlesbaren Format bereit­stellen. Streitkräfte sollten also Anbieter dazu ver­anlassen, diese Informationen zur Verfügung zu stellen (wie im folgenden Kapitel dargestellt). Solange die Bundeswehr diese Informationen nicht von den Anbietern bekommt, sollte der oder die CISOBw Hilfs­mittel anbieten und Musterprozesse entwickeln, um das Datensammeln und -verarbeiten zu erleichtern. Sobald einige Anbieter die Daten bereitstellen, sollten ein Musterprozess und konkrete Anleitungen ver­fügbar gemacht werden, damit Dienststellen ent­sprechen­de Prozesse aufsetzen können.

Überwachung des Software-Support-Status

Darüber hinaus sollten Organisationen, die sich vor Risiken der Software-Lieferkette schützen möchten, beobachten, ob die Anbieter der von ihnen verwendeten Softwareprodukte noch Support leisten. Derzeit stellen Anbieter diese Daten nicht in einem stan­dardisierten, maschinenlesbaren Format zur Ver­fügung.89 Stattdessen durchsucht das IT-Fachpersonal der Bundeswehr die Websites der Anbieter manuell nach Hinweisen zum Ende des Supports, sofern es ihre Zeit erlaubt.

Damit die Bundeswehr den Support-Status genutzter Softwareprodukte überwachen kann, sollte der oder die CISOBw zunächst definieren, was »aktiver Support« oder, im Fall von OSS, »aktive Maintenance« bedeutet.90 Diese Definition sollte (etwa durch eine Differenzierung nach Stufen) berücksichtigen, dass Software mit unterschiedlichen Sicherheitsanforderungen auch unterschiedlich engmaschigen Software-Support erfordert. Zudem sollte der oder die CISOBw Anleitungen zur Erleichterung der manuellen Informationssuche und einen Musterprozess für die Verarbeitung dieser Daten bereitstellen. Außerdem sollte die Bundeswehr – wie im folgenden Kapitel skizziert – Anbieter dazu bringen, ihnen entsprechende Daten zur Verfügung zu stellen, damit der Prozess automatisiert werden kann.

Die Bundeswehr sollte dringend die Expertise des Beschaffungs- und IT-Fachpersonals im Umgang mit Risiken der Software-Lieferkette ausbauen.

Vor allem aber muss der oder die CISOBw festlegen, was passiert, wenn ein Produkt keinen aktiven Sup­port mehr erhält. In diesem Fall gibt es zwei Möglichkeiten: Das IT-Fachpersonal kann entweder ein prak­tikables Alternativprodukt identifizieren und ein­führen oder den Support selbst in die Hand nehmen – mit eigenen Ressourcen oder durch die Beauftragung Dritter. Gerade für Streitkräfte ist es häufig schwierig, ein Alternativprodukt einzuführen, weil komplexe militärische Prozesse auf bestimmte Produkte aus­gerichtet sind und das Personal entsprechend geschult ist. Die Leitlinien für den Umgang mit Software-Liefer­ketten-Risiken sollten daher Anhaltspunkte dafür liefern, unter welchen Umständen die Bundeswehr ein Produkt ohne aktiven Support ersetzen sollte.

Aufbau von Fachexpertise

Das Beschaffungs- und IT-Fachpersonal der Bundeswehr ist in der Regel nicht im Umgang mit Risiken der Software-Lieferkette geschult. Die Bundeswehr sollte daher dringend die Fachexpertise der Verantwortlichen weiter aufbauen.

Angesichts des IT-Fachkräftemangels91 und der Schwierigkeiten des öffentlichen Sektors, IT-Talente anzuwerben und zu halten, sollte die Bundeswehr Kenntnisse zum Umgang mit den Risiken der Soft­ware-Lieferkette in ihren Akademien für die zivile und militärische Aus- und Weiterbildung vermitteln. Im Ergebnis sollte das Fachpersonal drei »Sprachen«92 beherrschen: Militär-, IT- und Beschaffungstermino­logie. Darüber hinaus sollten die Streitkräfte die in dieser Studie genannten Stellen mit angemessenen Ressourcen ausstatten, um gut ausgebildetes Personal einstellen zu können.

Red-Teaming-Aktivitäten

Zudem haben Unternehmen wie Regierungsstellen gute Erfahrungen mit sogenannten Red-Teaming-Aktivitäten gemacht. Dabei schlüpft eigenes IT-Fach­personal in die Rolle von Angreifer:innen, um Schwachstellen in den eigenen Systemen und den verwendeten Softwareprodukten zu finden. Üblicher­weise stehen bei diesen Überprüfungen kritische OSS‑Produkte und -Komponenten und proprietäre Soft­ware im Fokus. Wenn die Hersteller proprietärer Software solchen Red Teams Zugang zum Quellcode gewähren, können diese die Produkte gezielter auf bekannte Schwachstellen überprüfen, den Reifegrad integrierter OSS-Komponenten beurteilen und fest­stellen, ob gute Praktiken sicherer Software-Entwick­lung93 eingehalten wurden. Doch auch ohne Zugang zum Quellcode können solche Aktivitäten etwa Schwächen in der Konfiguration von Software auf­decken.

Einige Streitkräfte, darunter die Bundeswehr mit dem ZCSBw, haben bereits Teams, die den Programmcode ausgewählter Produkte untersuchen.94 Das ZCSBw sollte jedoch seine Aktivitäten ausweiten: Erstens sollten die entsprechenden Fachleute auch kritische OSS-Produkte und -Komponenten unter die Lupe nehmen.95 Zweitens sollten sie zusätzlich auf Maßnahmen setzen, die auch ohne Zugriff auf den Quellcode Erkenntnisse liefern können. Um diese Aufgaben erfüllen zu können, sollte das zuständige Team im ZCSBw vergrößert werden. Die Leitlinien für den Umgang mit Software-Lieferketten-Risiken sollten zudem vorgeben, auf welche Softwareprodukte sich entsprechende Bemühungen konzentrieren sollten.

Ausschluss nicht vertrauenswürdiger Hersteller von der Vergabe

Öffentliche Beschaffungsprozesse beruhen in der Regel auf funktionalen Anforderungen an das Produkt und Sicherheitsanforderungen an das Produkt und/oder den Anbieter. Doch es gibt Fälle, in denen ein Pro­dukt, das alle Bedingungen erfüllt, trotzdem von der Vergabe ausgeschlossen werden sollte: Wenn der Hersteller als nicht vertrauenswürdig gilt, etwa wegen der Eigentumsverhältnisse und der Kontrolle und Einflussnahme durch gegnerische Regierungen.96 Letztere können Hersteller etwa dazu bringen, schädliche versteckte Funktionen in ein Produkt einzubauen, sei es von Anfang an oder – etwa durch Updates – zu einem späteren Zeitpunkt.97

Es gibt Fälle, in denen ein Software-Produkt, das alle Bedingungen erfüllt, trotzdem von der Vergabe ausgeschlossen werden sollte.

Viele militärische Beschaffungsprozesse, wie auch der der Bundeswehr, sehen keine Möglichkeit vor, Produkte von der Vergabe auszuschließen, die formal alle Voraussetzungen erfüllen. Erschwerend kommt hinzu, dass die Informationen, die einer Einstufung als nicht vertrauenswürdiger Hersteller zugrunde liegen, oft nicht öffentlich sind. Vor diesem Hintergrund hat häufig das Beschaffungspersonal die Auf­gabe, die funktionalen Anforderungen so anzupassen, dass nicht vertrauenswürdige Anbieter diese nicht erfüllen – eine äußerst ineffiziente Strategie, die sich in einer rechtlichen Grauzone bewegt.

Der Gesetzgeber sollte daher das Vergaberecht und das BMVg entsprechende Verwaltungsvorschriften an­passen, um den Ausschluss nicht vertrauenswürdiger Hersteller zu erleichtern.

Wie Politik und Streitkräfte Software-Anbieter zum Risiko­management bewegen können

Doch Streitkräfte sind nicht allein in der Lage, sich vor den Risiken der Software-Lieferkette schützen. Vielmehr sind sie darauf angewiesen, dass auch die Software-Anbieter98 aktiv werden – indem sie die Risiken ihrer Produkte reduzieren und ihre Kund:in­nen bei deren Risikomanagement unterstützen. Entscheidungsträger:innen in Politik und Bundeswehr stehen mehrere Instrumente zur Verfügung, um die Anbieter zu entsprechenden Schritten zu bewegen (siehe Grafik 6, S. 32).

Anforderungen an Software-Anbieter

Bevor Entscheidungsträger:innen geeignete Politik­instrumente auswählen, müssen sie definieren, welche Maßnahmen sie von Software-Anbietern erwarten. Die Bundeswehr hat zwar ein »Software Engineering Framework«99 entwickelt, doch da es als Verschlusssache eingestuft wurde, ist unklar, welche Anforderungen es enthält. Basierend auf Einschätzungen von Expert:innen können besonders die folgenden sechs Maßnahmen die Lieferketten-Risiken von Softwareprodukten bedeutend reduzieren:

  1. Software-Anbieter sollten gute Praktiken sicherer Software-Entwicklung einhalten.100 Konkret sollten sie ausnutzbare bekannte Schwachstellen in den Komponenten ihrer Produkte beheben,101 Software in speichersicheren Programmiersprachen (neu) schreiben,102 auf einen sicheren Build-Prozess – der für Menschen verständlichen Programmcode in maschinenlesbaren Binärcode umwandelt – bei den von ihnen verwendeten Komponenten103 und eigenen Produkten104 achten und ihren Programmcode signieren.

Grafik 6

2.

Zusätzlich zum oben genannten Red-Teaming der Endprodukte durch die Bundeswehr sollten auch Anbieter entsprechende Tests in ihren eigenen Systemen durchführen (lassen) und ebenso ihre Zulieferer und Dienstleister dazu verpflichten.

3.

Anbieter sollten der Bundeswehr (und idealerweise auch ihren übrigen Kund:innen) Informationen über die Zusammensetzung ihrer Software­produkte zur Verfügung stellen, etwa als SBOMs. Diese Daten sollten dabei einem der etablierten Standards105 entsprechen und langfristig alle Ebenen von Komponenten beinhalten,106 da eine ausnutzbare Schwachstelle tief in der Software-Lieferkette verborgen sein kann.

4.

Anbieter sollten für ihre Produkte Informationen über Schwachstellen und ihre Ausnutzbarkeit in einem standardisierten und maschinenlesbaren Datenformat107 und über einen definierten Ver­teilungsmechanismus bereitstellen.

5.

Anbieter sollten während der gesamten Lebensdauer ihrer Produkte den Maintenance-Status der OSS-Komponenten, die in ihren Produkten integriert sind, im Blick behalten. Zum Entwicklungszeitpunkt sollten sie nur solche Komponenten integrieren, die der Bundeswehr-Definition von »aktiver Maintenance« entsprechen. Sollte eine Komponente, die bereits in ein Produkt integriert wurde, diese Anforderungen irgendwann nicht mehr erfüllen, sollte der Anbieter die Komponente austauschen, das Produkt selbst maintainen oder Dritte damit beauftragen. Anbieter, deren Produkte unter den EU Cyber Resilience Act (CRA) fallen, sind bereits ab 2027 dazu verpflichtet.108 Doch diese Vorschrift findet keine Anwendung auf Produkte, die ausschließlich für militärische Zwecke oder zur Verarbeitung von Verschlusssachen entwickelt wurden.109

6.

Anbieter sollten Informationen zum Support-Status ihrer Produkte in einem standardisierten, maschinenlesbaren Format110 bereitstellen.

Viele dieser Maßnahmen sind unter Software-Anbietern noch nicht weit verbreitet. Daher brauchen entsprechende Vorgaben großzügige Umsetzungs­zeiträume. Zudem sollten Software-Anbieter auch dazu verpflichtet werden, allgemeine Cybersicherheitsmaßnahmen umzusetzen, die nicht spezifisch auf Software-Lieferketten-Risiken ausgerichtet sind, aber dennoch Auswirkungen darauf haben. Dazu zählen etwa Netzwerksegmentierung und eine »Zero trust«-Architektur,111 ein Schwach­stellen-Manage­ment,112 regelmäßiges Einspielen von Software-Up­dates113 und die Detektion und Bearbeitung von Cybersicherheitsvorfällen.114

Wenn diese Anforderungen in Anreizsystemen oder Regulierung politisch verankert werden, muss beachtet werden, dass KMU und kleinere OSS-Projekte in der Regel weniger Möglichkeiten haben, anspruchs­volle Vorschriften umzusetzen. Voraussetzungsreiche Regulierung kann daher unbeabsichtigte Folgen haben: So ist es denkbar, dass KMU oder kleinere OSS‑Projekte ihre Softwareprodukte aufgeben oder Anbieter die OSS-Komponenten, die sie in ihre Pro­dukte integrieren, abschotten.115 Daher sollten Ent­scheidungsträger:innen prüfen, ob Pflichten für KMU und OSS-Projekte reduziert werden und wie diese bei der Umsetzung unterstützt werden können.

Bereitstellung von Muster-Vertragsbausteinen

Wenn die Vorgaben für Anbieter definiert wurden, müssen Politik und Bundeswehr entscheiden, auf welche Weise sie die Adressaten dazu bewegen wollen, diese Maßnahmen umzusetzen. Eine niedrig­schwellige Möglichkeit sind Beschaffungsverträge. Auch ohne zentrale Vorschriften können auf diesem Weg die genannten Vorgaben vereinbart werden. Ein Beispiel aus dem Privatsektor zeigt, dass Software-Anbieter etwa vertraglich dazu verpflichtet werden können, regelmäßig den Support-Status der OSS-Komponenten zu überprüfen, die sie in ihre Produkte integriert haben, und falls nötig Abhilfemaßnahmen zu ergreifen.116 Die Bundeswehr, wie auch die Streit­kräfte anderer Staaten, machen von dieser Möglichkeit allerdings erst wenig Gebrauch.

Der aktuelle Beschaffungsprozess der Bundeswehr berücksichtigt Software-Lieferketten-Risiken nicht.

Um dies zu ändern, sollten dem Beschaffungs­personal der Bundeswehr Muster-Vertragsbausteine zur Verfügung gestellt werden, zum Beispiel in Form von Service Level Agreements.117

Anpassung von Anforderungen im Beschaffungsprozess

Der aktuelle Beschaffungsprozess der Bundeswehr berücksichtigt Software-Lieferketten-Risiken nicht.118 Die USA hingegen nutzen bereits Beschaffungsregeln, um Software-Anbieter dazu zu bewegen, ihre Pro­dukte besser vor Software-Lieferketten-Risiken zu schützen.119 So verpflichtet etwa die US Army ihre Lieferanten zur Bereitstellung von SBOM-Daten.120 Die aktuell laufende Überarbeitung der deutschen zivilen und militärischen Beschaffungsgesetze und die geplante Neufassung der europäischen Beschaffungsvorschriften bieten eine gute Gelegenheit, ent­sprechende Änderungen mit aufzunehmen.121

Konkret sollte die Bundeswehr die Regeln für die militärische Beschaffung in dreierlei Hinsicht an­passen:

  1. Zusammen mit allen für Softwarebeschaffung verantwortlichen Stellen sollte der oder die CISOBw horizontale Mindestanforderungen zum Umgang von Anbietern mit Risiken der Software-Lieferkette erarbeiten. Solche Mindestanforderungen hat die Bundeswehr bereits etwa für Cyber­sicherheit formuliert. Auch diese Vorgaben sollten durch ein Stufensystem auf die Kritikalität des jeweiligen Produkts zugeschnitten werden.

  2. Hindernisse für die Beschaffung von OSS, besonders von Produkten ohne kommerziellen Supportvertrag, sollten beseitigt werden.122

  3. Angesichts des IT-Fachkräftemangels sollten Hürden beseitigt werden, (sicherheitsüberprüfte) Dienstleister mit Cybersicherheitsaufgaben zu betrauen, für die die Ressourcen der Bundeswehr nicht ausreichen, wie zum Beispiel Red-Teaming-Aktivitäten.

Anpassung des Produkthaftungsrechts

Aktuell kann die Bundeswehr – ähnlich wie End­nutzer:innen außerhalb der EU und viele andere Streitkräfte – Software-Anbieter hauptsächlich bei Vertragsbruch, Vorsatz oder grober Fahrlässigkeit haftbar machen. Die Ursachen von Sicherheits­verletzungen, bei denen die Software-Lieferkette eine Rolle spielt, liegen jedoch häufig in (unterlassenen) Maßnahmen der Anbieter jenseits der genannten Kategorien. Produkthaftungsregelungen für Software­produkte, die von Streitkräften verwendet werden, würden es der Bundeswehr erlauben, Anbieter zu belangen, wenn Unzulänglichkeiten im Software­produkt oder im Entwicklungsprozess einen Schaden verursachen, und würden sie etwa zur Zahlung von Schadenersatz verpflichten.123

Das geltende deutsche Produkthaftungsrecht findet keine Anwendung auf Software.124 Und die neue EU-Produkthaftungsrichtlinie ist zwar anwendbar, sieht aber nur Ansprüche natürlicher Personen vor.125 Ab 2027 wird die Bundeswehr Ansprüche gegenüber Software-Anbietern auf der Grundlage des europäischen CRA geltend machen können, doch auf viele von der Bundeswehr genutzte Produkte ist diese Vor­schrift nicht anwendbar.126 Abgesehen vom CRA hat bisher kein Land ein entsprechendes Produkthaftungs­regime entwickelt.

Der Gesetzgeber sollte in Erwägung ziehen, eine Produkthaftungs­regelung für Software einzuführen, die von Streitkräften genutzt wird.

Der Gesetzgeber sollte daher in Erwägung ziehen, eine Produkthaftungsregelung für Software einzuführen, die von Streitkräften genutzt wird, oder für Soft­ware im Allgemeinen. Eine gute Gelegenheit dafür bietet die erwähnte EU-Produkthaftungsrichtlinie, die die Mitgliedstaaten bis 2026 in nationales Recht um­setzen müssen. Da der Gesetzgeber dadurch ohnehin das Produkthaftungsrecht ändern muss, könnte er über die Erfordernisse der EU-Richtlinie hinausgehen und auch juristische Personen wie die Bundeswehr anspruchsberechtigt machen. Dabei könnten die oben genannten Vorgaben für Software-Anbieter als Maß­gabe dafür dienen, unter welchen Bedingungen An­bieter haftbar gemacht werden können.127 Auch die Kriterien des CRA sollten berücksichtigt werden, um die regulatorische Kluft zwischen dem zivilen und dem militärischen Sektor zu verkleinern.

Konformitätsbewertungen

Wenn Politik und Streitkräfte sichergehen wollen, dass Software-Anbieter spezielle Anforderungen erfüllen, können sie auf Konformitätsbewertungen zurückgreifen. Dabei überprüft eine bescheinigende Partei – der Anbieter selbst (Selbstbewertung) oder eine unabhängige, staatlich zugelassene Stelle (Fremd­bewertung) –, ob bestimmte Vorgaben eingehalten werden.128 Diese können etwa in einem technischen Standard definiert sein. Das Ergebnis der Bewertung wird beispielsweise in einer Zertifizierung fest­gehalten.

Das US-Verteidigungsministerium hat ein Konformitätsbewertungssystem entwickelt für den Umgang seiner Lieferanten mit Informationen, die keine Ver­schlusssachen, aber dennoch sensibel sind.129 Der CRA sieht ein Konformitätsbewertungssystem für Softwareprodukte vor, das je nach Kritikalität des Produkts von Selbst- bis zu Fremdbewertungen reicht und produktbezogene mit prozessbezogenen Bewer­tungen kombiniert.130 In Deutschland gibt es solche Systeme für die Anbieter von Software, die Verschluss­sachen verarbeiten. Diese berücksichtigen auch Soft­ware-Lieferketten-Risiken, doch da die Konformitätsbewertungssysteme nicht öffentlich sind, können sie hier nicht beurteilt werden. Darüber hinaus ist das »IT-Sicherheitskennzeichen«131 des BSI ein Konfor­mitätsbewertungssystem für COTS-IT-Produkte.

Solche Konformitätsbewertungssysteme für Software sind für Anbieter und Politik kostspielig, die Beurteilung muss wegen häufiger Software-Updates regelmäßig erneuert werden, und es fehlt – als Grundlage für die Bewertung – häufig an produktbezogenen technischen Standards, die Software-Liefer­ketten-Risiken einbeziehen. Daher sollten politische und militärische Entscheidungsträger:in­nen mit der Einrichtung weiterer Konformitäts­bewertungssysteme zurückhaltend sein. Stattdessen sollte das Beschaffungspersonal der Bundeswehr bei der Produktauswahl die Kriterien des IT-Sicherheits­kennzeichens und des CRA berücksichtigen.

Sollte die Bundeswehr dennoch ein Konformitätsbewertungssystem einführen wollen, sollten die Verantwortlichen:

  1. sich für einen prozessbezogenen Ansatz entscheiden, um sicherzustellen, dass die Bewertungen länger gültig bleiben;

  2. ein abgestuftes System entwickeln, um die Teil­nahme von KMU und des OSS-Ökosystems zu er­leichtern;

  3. eine Harmonisierung mit den CRA-Anforderungen und mit den Bewertungssystemen anderer Nato-Verbündeter anstreben, um gleiche Wettbewerbsbedingungen im gesamten Bündnis zu schaffen; und

  4. zumindest auf der höchsten Sicherheitsstufe Bewertungen durch Dritte fordern, um belastbare Bewertungen zu erhalten.

Prioritäten für Bundespolitik und Bundeswehr

Bereits die in dieser Studie diskutierten Vorfälle, die Streitkräften die Auswirkungen von Unterbrechungen im Betriebsablauf oder von Angriffen über die Software-Lieferkette vor Augen geführt haben, zeich­nen ein düsteres Bild. Dabei stellen diese mutmaßlich nur einen Bruchteil der tatsächlich stattgefundenen Ereignisse dar, denn die meisten werden vermutlich nicht publik.

Trotz der potentiell verheerenden Auswirkungen sollte die Bundeswehr nicht danach streben, die Risiken der Software-Lieferkette um jeden Preis zu minimieren. Stattdessen gilt es, ein angemessenes Schutzniveau zu definieren – je nach Software­produkt. Der Fokus sollte dabei auf denjenigen Pro­dukten liegen, die auf dem Gefechtsfeld zum Einsatz kommen, entscheidend für das Funktionieren des Unterstützungsbereichs sind oder deren Kompro­mittierung gegnerischen Nachrichtendiensten weit­reichende Einblicke erlauben würde.

Besonders mit Blick auf diese Produkte sollten BMVg und Bundeswehr Maßnahmen ergreifen, um die Risiken der Software-Lieferkette auf ein akzep­tables Niveau zu senken. Allerdings sind viele der in dieser Studie diskutierten Maßnahmen komplex und ressourcenintensiv. Angesichts der begrenzten Auf­merksamkeit von Entscheidungsträger:innen in der Politik wie in der Bundeswehr, des Mangels an IT-Fachpersonal und endlicher finanzieller Mittel sollten Bundespolitik und Bundeswehr drei Schritte mit größter Dringlichkeit angehen.

Erstens sollten in der Bundeswehr Strukturen auf­gebaut werden, um den bewussten Umgang mit den Risiken der Software-Lieferkette überhaupt erst zu ermöglichen. Konkret sollte das Portfolio des CISOBw um diesen Aufgabenbereich erweitert werden, um eine zentrale Zuständigkeit für das Thema zu schaf­fen. Dieser Prozess sollte flankiert werden durch die Berufung von Beauftragten bei BAAINBw, BAIUDBw und BWI, die das Beschaffungspersonal dabei unter­stützen, weitere Maßnahmen zu implementieren. Des Weiteren sollten BMVg und die involvierten Stellen bei der Bundeswehr gemeinsam Leitlinien zum Umgang mit Risiken der Software-Lieferkette formulieren, deren Inhalte möglichst auch in Dienst­vorschriften verankert werden sollten. Schließlich sollte die Bundeswehr ihrem Beschaffungs- und IT-Fachpersonal einschlägige Expertise zum Umgang mit den Risiken der Software-Lieferkette vermitteln, etwa über die Akademien der Bundeswehr.

Zweitens sollten Politik und Bundeswehr die Soft­ware-Anbieter dazu bewegen, der Bundeswehr die­jenigen Informationen zur Verfügung zu stellen, die für ein effektives Risikomanagement unabdingbar sind. Dazu zählen Informationen zu Softwarekomponenten, zu Schwachstellen und ihrer Ausnutzbarkeit und zum Support-Status der Produkte. Am unbürokratischsten kann dies über Muster-Vertragsbausteine erreicht werden, welche der oder die CISOBw zentral dem Beschaffungspersonal zur Verfügung stellt – allerdings ist offen, ob diese in den endgültigen Ver­trägen mit den Anbietern auch berücksichtigt werden. Zuverlässiger wäre daher der Weg über horizontale Mindestanforderungen im Beschaffungsprozess.

Drittens sollte die Bundeswehr eigene Prozesse etablieren, um auf Basis der von den Software-Anbietern erhaltenen Informationen die Risiken der Software-Lieferkette im Blick behalten und gegebenen­falls auf Vorfälle reagieren zu können. Dazu zählen die Pflege von Inventaren aller von der Bundeswehr verwendeten Softwareprodukte, die Überwachung des Support-Status dieser Produkte und die konstante Beobachtung, ob darin bekannte Schwachstellen vorhanden und ausnutzbar sind.

Zusammengenommen erlauben es diese drei Schritte der Bundeswehr, handlungsfähig zu werden und die Risiken der Software-Lieferkette im Blick zu behalten und auf Vorfälle reagieren zu können. Wenn die Bundesregierung und die Bundeswehr die Risiken zudem weiter reduzieren möchten, sind zusätzliche Schritte nötig. So sollten die Bundeswehr selbst und ihre Software-Anbieter sowie deren Zulieferer Red-Teaming-Tests durchführen, um Schwachstellen in Produkten und Konfigurationen offen­zulegen. Außer­dem sollten Politik und Bundeswehr die Anbieter dazu bringen, Praktiken sicherer Soft­ware-Entwick­lung einzuhalten. Dazu zählen das Schließen aus­nutzbarer bekannter Schwachstellen in den Kom­ponenten der Produkte, der Wechsel zu speicher­sicheren Programmiersprachen, die Absicherung des Build-Prozesses und das Signieren des Pro­gramm­codes. Des Weiteren sollten Anbieter den Main­tenance-Status der OSS-Komponenten, die Teil ihrer Produkte sind, nicht nur zum Entwicklungszeitpunkt prüfen, sondern auch darüber hinaus überwachen und – wenn keine Maintenance mehr gegeben ist – Abhilfemaßnahmen ergreifen. Auch für diese Maß­nahmen sind angepasste Mindestanforderungen im Beschaffungsprozess eine Möglichkeit, die – im Vergleich zu einer Änderung des Produkthaftungsrechts – vergleichsweise leicht umzusetzen sind.

Entscheidend ist, dass BMVg und Bundeswehr die gewählten Maßnahmen zeitnah implementieren, damit sie Eingang in laufende Reformbemühungen finden können: Die Reorganisation des CIR nach seiner Erhebung zur Teilstreitkraft ist ein guter Zeit­punkt, um neue Strukturen zu schaffen. Und mit der Reform der Schuldenbremse132 stehen die Chancen günstig für Investitionen, die die Sicherheit der Bundeswehr deutlich verbessern. Schließlich befinden sich verschiedene Beschaffungsregelungen derzeit in Überarbeitung und Software-Anbieter müssen sich mit Blick auf das Inkrafttreten des CRA 2027 ohnehin mit der Sicherheit ihrer Produkte befassen.

Um die Kosten der hier vorgeschlagenen Maß­nahmen zu senken, sollten Bundesregierung und Bundeswehr sich mit gleichgesinnten Staaten zu­sammen­tun. Die Bundeswehr kann Software-Anbieter eher davon überzeugen, bestimmte Maßnahmen umzusetzen, wenn es sich um international harmo­nisierte Anforderungen handelt. Ein internationaler Austausch zu diesem Thema könnte neben der Nato auch im Rahmen der Organisation für wirtschaftliche Zusammenarbeit und Entwicklung (OECD) oder der kürzlich eingerichteten G7-Arbeitsgruppe für Cyber­sicherheit stattfinden. Ein internationales Multi-Stakeholder-Forum, das sich mit dem Handling der Risiken (militärischer) Software-Lieferketten befasst, könnte das Bewusstsein für dieses Thema weiter schärfen und die operative Zusammenarbeit fördern.

In jedem Fall wird der Umgang mit Software-Lieferketten-Risiken ein Balanceakt für Politik und Bundeswehr: Einerseits müssen sie in signifikantem Umfang Ressourcen investieren, um potentiell ver­heerende Angriffe oder sonstige Unterbrechungen in militärischen Betriebsabläufen zu verhindern oder deren Auswirkungen zu mindern. Andererseits müs­sen sie die Weichen für »Software-defined Defense« stellen – durch vereinfachte und beschleunigte Beschaffung, den Einsatz und die Aktualisierung von Software und die Förderung eines dynamischen und innovativen Defense-Tech-Ökosystems im eigenen Land.133 Auch wenn sich diese Studie auf Ersteres konzentriert, bleibt auch Letzteres bedeutsam.

Abkürzungen

BAAINBw

Bundesamt für Ausrüstung, Informationstechnik und Nutzung der Bundeswehr

BAIUDBw

Bundesamt für Infrastruktur, Umweltschutz und Dienstleistungen der Bundeswehr

BMVg

Bundesministerium der Verteidigung

BSI

Bundesamt für Sicherheit in der Informationstechnik

CIO

Chief Information Officer

CIR

Cyber- und Informationsraum (Teilstreitkraft der Bundeswehr)

CISA

Cybersecurity and Infrastructure Security Agency (USA)

CISOBw

Chief Information Security Officer der Bundeswehr

COTS

Commercial off-the-shelf

CRA

EU Cyber Resilience Act

DoD

Department of Defense (USA)

GRU

Militärischer Nachrichtendienst (Russland)

IC

Innovation und Cyber (Abteilung im BMVg)

IT

Informationstechnologie

KMU

Kleine und mittlere Unternehmen

NIST

National Institute of Standards and Technology (USA)

NTIA

National Telecommunications and Information Administration (USA)

OECD

Organisation für wirtschaftliche Zusammenarbeit und Entwicklung

OSPO

Open Source Program Office

OSS

Open-Source-Software

PwC

PricewaterhouseCoopers

SaaS

Software as a Service

SBOM

Software Bill of Materials

SDD

Software-defined Defense

SVR

Auslandsgeheimdienst (Russland)

WTD 81

Wehrtechnische Dienststelle für Informations­technologie und Elektronik

ZCSBw

Zentrum für Cyber-Sicherheit der Bundeswehr

ZDigBw

Zentrum Digitalisierung der Bundeswehr und Fähigkeitsentwicklung Cyber- und Informations­raum

ZenDiS

Zentrum für Digitale Souveränität der Öffentlichen Verwaltung

Endnoten

1

 Maintainer:innen kümmern sich um Sicherheitsupdates und funktionale Upgrades von OSS-Komponenten und -Pro­dukten.

2

 Diese Vorfälle werden im Abschnitt »Die Auswirkungen vergangener Software-Lieferketten-Vorfälle auf Streitkräfte«, S. 16, erläutert.

3

 BMVg u.a., Ideenpapier »Etablierung und Aufrechterhaltung sicherer Lieferketten für vertrauenswürdige IT der Bundeswehr«, Berlin, 8.6.2021, <https://www.bmvg.de/resource/blob/ 5103740/9cc683ea3fac46f37290590cc41aa1a6/download-sichere-it-lieferketten-data.pdf>. Sofern nicht anders an­gegeben, wurden alle Websites zuletzt am 17.9.2025 auf­gerufen.

4

 Siehe Kapitel »Die Software-Lieferkette«, S. 9.

5

 Siehe Kapitel »Risiken der Software-Lieferkette«, S. 11.

6

 Siehe Kapitel »Die besondere Bedrohung von Streit­kräften«, S. 14.

7

 Simona Soare u.a., Software-defined Defence: Algorithms at War, London: The International Institute for Strategic Studies, Februar 2023, <https://www.iiss.org/research-paper/2023/02/software-defined-defence/>; Nand Mulchan­dani / John N. Shanahan, Software-Defined Warfare: Architecting the DOD’s Transition to the Digital Age, Washington, D.C.: Center for Strategic & International Studies, September 2022, <https://www.csis.org/analysis/software-defined-warfare-architecting-dods-transition-digital-age>.

8

 Die in der Studie formulierten Politikempfehlungen basieren unter anderem auf mehr als 65 Interviews und einem Workshop mit internationalen Expert:innen.

9

 Siehe Kapitel »Wie sich Streitkräfte selbst vor Risiken der Software-Lieferkette schützen können«, S. 19.

10

 Siehe Kapitel »Wie Politik und Streitkräfte Software-Anbieter zum Risikomanagement bewegen können«, S. 27.

11

 SAFECode, Software Integrity Controls. An Assurance-Based Approach to Minimizing Risks in the Software Supply Chains, Arlington, 14.6.2010, S. 3, <https://safecode.org/publication/ SAFECode_Software_Integrity_Controls0610.pdf>.

12

 Charles W. Krueger, »Software Reuse«, in: ACM Comput­ing Surveys, 24 (1992) 2, S. 131–183 (141); Fang Hou / Slinger Jansen, »A Systematic Literature Review on Trust in the Software Ecosystem«, in: Empirical Software Engineering, 28 (2023) 1, doi: <10.1007/s10664-022-10238-y>.

13

 Krueger, »Software Reuse« [wie Fn. 12].

14

 Dazu zählen auch Einzelpersonen oder gemeinnützige Organisationen wie OSS-Stiftungen; der Anschaulichkeit halber ist hier schlicht von Herstellern die Rede.

15

 SAFECode, Software Integrity Controls [wie Fn. 11], S. 8.

16

 Es ist umstritten, ob OSS per Definition für alle frei nutz­bar ist (Open Source Initiative, »The Open Source Definition«, 16.2.2024, <https://opensource.org/osd>) oder ob OSS-Lizenzen bestimmte Anwendungsfälle wie eine militä­rische Nutzung ausschließen können (Steve Dierker / Volker Roth, »Can Software Licenses Contribute to Cyberarms Control?«, in: Marco Carvalho u.a. (Hg.), Proceedings of the New Security Paradigms Workshop, New York: ACM, 28.8.2018, S. 41–51, doi: 10.1145/3285002.3285009).

17

 Black Duck, Open Source Security & Risk Analysis Report, Burlington 2025, <https://www.blackduck.com/resources/ analyst-reports/open-source-security-risk-analysis.html>; Julius Musseau u.a., »Is Open Source Eating the World’s Software?«, in: David Lo (Hg.), Proceedings of the 19th Inter­national Conference on Mining Software Repositories, New York: Association for Computing Machinery, 2022, S. 561–565, doi: 10.1145/3524842.3528473.

18

 Klint Finley, »Linux Took Over the Web. Now, It’s Tak­ing Over the World«, Wired, 25.8.2016, <www.wired.com/ 2016/08/linux-took-web-now-taking-world/>.

19

 National Cyber Security Centre, A Method to Assess »Forgivable« vs »Unforgivable« Vulnerabilities, London, 28.1.2025, <https://www.ncsc.gov.uk/report/a-method-to-assess-forgivable-vs-unforgivable-vulnerabilities>; Black Duck, Open Source Security & Risk Analysis Report [wie Fn. 17].

20

 National Cyber Security Centre, Vulnerability Management. Advice, Guidance and Other Resources for Managing Vulnerabilities, London, 12.2.2024, <https://www.ncsc.gov.uk/collection/ vulnerability-management/understanding-vulnerabilities>. Bei wörtlichen Zitaten englischsprachiger Quellen handelt es sich um Übersetzungen der Autorin.

21

 Andy Greenberg, »The Untold Story of NotPetya, the Most Devastating Cyberattack in History«, Wired, 21.8.2018, <https://www.wired.com/story/notpetya-cyberattack-ukraine-russia-code-crashed-the-world/>.

22

 Trey Herr u.a., Breaking Trust: Shades of Crisis Across an Insecure Software Supply Chain, Washington, D.C.: Atlantic Council, 26.7.2020, <https://www.atlanticcouncil.org/in-depth-research-reports/report/breaking-trust-shades-of-crisis-across-an-insecure-software-supply-chain/>.

23

 Tidelift, The 2024 Tidelift State of The Open Source Maintainer Report, Boston, 2024, S. 4, <https://4008838.fs1. hubspotusercontent-na1.net/hubfs/4008838/2024-tidelift-state-of-the-open-source-maintainer-report.pdf>.

24

 Alexandra Paulus / Christina Rupp, Government’s Role in Increasing Software Supply Chain Security: A Toolbox for Policy Makers, Berlin: Interface, März 2023, S. 18, <www.interface-eu.org/publications/governments-role-increasing-software-supply-chain-security-toolbox-policy-makers>. Im Abschnitt »Die Auswirkungen vergangener Software-Lieferketten-Vorfälle auf Streitkräfte« in der vorliegenden Studie, S. 16, werden mit der »Cloud Hopper«-Kampagne, der »Sunburst«-Kampagne und dem Viasat-Vorfall Beispiele für solche Angriffe skizziert.

25

 Siehe etwa Codi Starks u.a., »Staying a Step Ahead: Mitigating the DPRK IT Worker Threat«, Google Cloud Blog, 23.9.2024, <https://cloud.google.com/blog/topics/threat-intelligence/mitigating-dprk-it-worker-threat>.

26

 Camilla Turner, »Britain’s Nuclear Submarine Software Built by Belarusian Engineers«, in: The Telegraph, 2.8.2024, <https://www.telegraph.co.uk/news/2024/08/02/britains-nuclear-submarine-software-designed-russia-belarus/>; Renee Dudley, »A Little-Known Microsoft Program Could Expose the Defense Department to Chinese Hackers«, ProPublica, 15.7.2025, <https://www.propublica.org/article/microsoft-digital-escorts-pentagon-defense-department-china-hackers>.

27

 Dieser Vorfall wird im Abschnitt »Die Auswirkungen vergangener Software-Lieferketten-Vorfälle auf Streitkräfte«, S. 16, genauer skizziert.

28

 Evan Boehs, »Everything I Know About the XZ Backdoor«, Evan Boehs (online), 29.3.2024, <https://boehs.org/ node/everything-i-know-about-the-xz-backdoor>.

29

 Thomas Roccia, »The XZ Backdoor Story«, Speaker Deck (online), 8.9.2024, <https://speakerdeck.com/fr0gger/the-xz-backdoor-story>; Sarah Fluchs, »Almost a Master Key to the Internet: The XZ Utils Backdoor«, Industrial Cyber (online), 28.5.2024, <https://industrialcyber.co/news/almost-a-master-key-to-the-internet-the-xz-utils-backdoor/>; Bruce Schneier, »Backdoor in XZ Utils that Almost Happened«, in: Lawfare, 9.4.2024, <https://www.lawfaremedia.org/article/backdoor-in-xz-utils-that-almost-happened>.

30

 Kevin Roose, »Did One Guy Just Stop a Huge Cyber­attack?«, in: The New York Times, 3.4.2024, <https://www.nytimes.com/2024/04/03/technology/prevent-cyberattack-linux.html>.

31

 Sonatype, 2024 State of the Software Supply Chain, Fulton 2024, S. 31ff, <https://www.sonatype.com/state-of-the-software-supply-chain/introduction>.

32

 Mit dem Crowdstrike-Vorfall von 2024 wird im Abschnitt »Die Auswirkungen vergangener Software-Liefer­ketten-Vorfälle auf Streitkräfte«, S. 16, ein Beispiel für einen solchen Vorfall dargestellt.

33

 Anbieter machen manchmal Ausnahmen im Rahmen von bezahlten Servicevereinbarungen oder nach der Ent­deckung extrem kritischer Schwachstellen.

34

 Tidelift, The 2024 Tidelift State of The Open Source Maintainer Report [wie Fn. 23], S. 6.

35

 Christian Brose, The Kill Chain. Defending America in the Future of High-Tech Warfare, New York: Hachette Books, 2020.

36

 Der »Stuxnet«-Vorfall hat jedoch gezeigt, dass auch »Air-gapped«-Systeme anfällig für Angriffe sein können, siehe Kim Zetter, Countdown to Zero Day. Stuxnet and the Launch of the World’s First Digital Weapon, New York: Crown Publishers, 2014.

37

 Mulchandani / Shanahan, Software-Defined Warfare [wie Fn. 7]; Soare u.a., Software-defined Defence [wie Fn. 7]; Software Defined Defence. Positionspapier des BDSV, BDLI, Bitkom und BMVg, Berlin, 31.10.2023, <https://www.bmvg.de/resource/blob/ 5711942/6fb70a45412601fdf03f63aeebf72451/cyber-defined-defence-papier-data.pdf>. Zuvor wurden ähnliche Ideen unter dem Begriff der netzwerkzentrierten Kriegsführung diskutiert, siehe z. B. Arthur K. Cebrowski / John J. Garstka, »Network-Centric Warfare: Its Origin and Future«, in: Proceedings of the Naval Institute, 124 (1998), S. 28–35.

38

 Soare u.a., Software-defined Defence [wie Fn. 7], S. 3f.

39

 Emelia Probasco, Building the Tech Coalition. How Project Maven and the U.S. 18th Airborne Corps Operationalized Software and Artificial Intelligence for the Department of Defense, Washing­ton, D.C.: Center for Security and Emerging Technology (CSET), August 2024, <https://cset.georgetown.edu/ publication/building-the-tech-coalition/>.

40

 Bundeswehr, Operationsplan Deutschland. Eine gesamt­staatliche und gesamtgesellschaftliche Aufgabe, Berlin 2025, <https://www.bundeswehr.de/resource/blob/5920008/5eb62255741addec3f38d49a443d0282/booklet-operationsplan-deutschland-data.pdf>.

41

 Defense Management Institute, Department of Defense Dependencies on Critical Infrastructure, Alexandria, 27.9.2024, <https://www.dmi-ida.org/knowledge-base-detail/Department-of-Defense-Dependencies-on-Critical-Infrastructure-Executive-Summary>; Annie Fixler u.a., Military Mobility Depends on Secure Critical Infrastructure, Washington, D.C.: Cyberspace Solarium Commission 2.0, 27.3.2025, <https://cybersolarium.org/csc-2-0-reports/military-mobility-depends-on-secure-critical-infrastructure/>.

42

 Lai Xu / Sjaak Brinkkemper, »Concepts of Product Soft­ware«, in: European Journal of Information Systems, 16 (2007) 5, S. 531–541.

43

 Dazu zählen BMVg, Projektbezogene Bedarfsdeckung und Nutzung. A-1500/3, Berlin, 23.5.2024, <www.bundeswehr.de/ resource/blob/133334/d5cdf4ad42eaa94618f429ad06a684e3/ pbn-data.pdf>; Europäisches Parlament und Rat, Richtlinie 2009/81/EG des Europäischen Parlaments und des Rates vom 13. Juli 2009 über die Koordinierung der Verfahren zur Vergabe bestimmter Bau-, Liefer- und Dienstleistungsaufträge in den Bereichen Verteidi­gung und Sicherheit und zur Änderung der Richtlinien 2004/17/EG und 2004/18/EG, Brüssel, 25.6.2025, <https://eur-lex.europa.eu/ legal-content/DE/TXT/?uri=CELEX:32009L0081>.

44

 »Remediation and Guidance Hub: Channel File 291 Incident«, CrowdStrike, 6.8.2024, <https://www.crowdstrike. com/falcon-content-update-remediation-and-guidance-hub/>.

45

 James Coker, »CrowdStrike Fault Causes Global IT Out­ages«, Infosecurity Magazine, 19.7.2024, <www.infosecurity-magazine.com/news/crowdstrike-fault-it-outages/>; David Weston, »Helping Our Customers through the CrowdStrike Outage«, Official Microsoft Blog, 20.7.2024, <https://blogs. microsoft.com/blog/2024/07/20/helping-our-customers-through-the-crowdstrike-outage/>.

46

 »CrowdStrike Achieves IL5 Authorization to Secure U.S. Department of Defense«, Pressemitteilung, CrowdStrike, 31.5.2023, <https://www.crowdstrike.com/en-us/press-releases/crowdstrike-achieves-il5-authorization-to-secure-us-dod/>.

47

 Carley Welch, »Joint Chiefs Chairman Says DoD Operations not Affected by Widespread CrowdStrike ›Glitch‹«, Breaking Defense, 19.7.2024, <http://breakingdefense.com/ 2024/07/joint-chiefs-chairman-says-dod-operations-not-affected-by-widespread-crowdstrike-glitch/>.

48

 »F-16 Fighting Falcon«, United States Air Force, September 2021, <https://www.af.mil/About-Us/Fact-Sheets/Display/ Article/104505/f-16-fighting-falcon/>.

49

 David Axe, »France to the Rescue! French-Made Mirage 2000 Jets Could Become Ukraine’s Most Important Aerial Radar Jammers«, in: Forbes, 7.3.2025, <www.forbes.com/ sites/davidaxe/2025/03/07/france-to-the-rescue-french-made-mirage-2000-jets-could-become-ukraines-most-important-aerial-radar-jammers/>; Justin Bronk, Airborne Electromagnetic Warfare in NATO: A Critical European Capability Gap, London: Royal United Services Institute (RUSI), 19.3.2025, <https://www.rusi.org/explore-our-research/publications/ occasional-papers/airborne-electromagnetic-warfare-nato-critical-european-capability-gap>.

50

 Benjamin Aronson, »Dominate the Spectrum: 350th SWW Enables EW Capabilities for Ukrainian F-16s«, Air Combat Command, 26.8.2024, <https://bit.ly/3IBP4bi>; US Defense Security Cooperation Agency, Ukraine – F-16 Sustainment Services, 10.12.2024, <https://www.dsca.mil/Press-Media/Major-Arms-Sales/Article-Display/Article/4009609/ ukraine-f-16-sustainment-services>.

51

 Axe, »France to the Rescue!« [wie Fn. 49].

52

 »After Trump’s Freeze, US Military Aid to Ukraine Resumes – Poland Confirms«, Kyiv Post, 12.3.2025, <https://www.kyivpost.com/post/48761>.

53

 U.S. Department of Justice, Two Chinese Hackers Associated with the Ministry of State Security Charged with Global Computer Intrusion Campaigns Targeting Intellectual Property and Confidential Business Information, Washington, D.C., 20.12.2018, <https://www.justice.gov/archives/opa/pr/two-chinese-hackers-associated-ministry-state-security-charged-global-computer-intrusion>; PwC UK / BAE, Operation Cloud Hopper, London, April 2017, <https://www.pwc.co.uk/cyber-security/pdf/pwc-uk-operation-cloud-hopper-report-april-2017.pdf>.

54

 Jack Stubbs u.a., »Stealing Clouds«, Reuters, 26.6.2019, <https://www.reuters.com/investigates/special-report/china-cyber-cloudhopper/>.

55

 Trey Herr u.a., Broken Trust: Lessons from Sunburst, Washing­ton, D.C.: Atlantic Council, 29.3.2021, <https://www. atlanticcouncil.org/in-depth-research-reports/report/broken-trust-lessons-from-sunburst>.

56

 Adam Janofsky, »Cyber Command: ›No Evidence‹ that SolarWinds Attackers Compromised DoD Networks«, The Record, 17.11.2022, <https://therecord.media/cyber-command-no-evidence-that-solarwinds-attackers-compromised-dod-networks>; Natasha Bertrand / Eric Wolff, »Nuclear Weapons Agency Breached Amid Massive Cyber Onslaught«, in: Politico, 17.12.2020, <https://www.politico.com/news/2020/12/17/ nuclear-agency-hacked-officials-inform-congress-447855>; Herr u.a., Broken Trust [wie Fn. 55].

57

 »Russia Behind Cyber-Attack with Europe-Wide Impact an Hour Before Ukraine Invasion«, Foreign, Commonwealth & Development Office, London, 10.5.2022, <https://www.gov.uk/ government/news/russia-behind-cyber-attack-with-europe-wide-impact-an-hour-before-ukraine-invasion>; Nick Saunders u.a., »Space Cybersecurity Incident Response Framework: A Viasat Case Study«, in: 2025 IEEE Aerospace Conference, S. 1–15, doi: <https://doi.org/10.1109/AERO63441.2025. 11068784>.

58

 Saunders u.a., »Space Cybersecurity Incident Response Framework« [wie Fn. 57]; Katrina Manson, »The Satellite Hack Everyone Is Finally Talking About«, Bloomberg, 1.3.2023, <https://www.bloomberg.com/features/2023-russia-viasat-hack-ukraine/>.

59

 Juan Andres Guerrero-Saade / Max van Amerongen, »AcidRain: A Modem Wiper Rains Down on Europe«, SentinelOne, 31.3.2022, <https://www.sentinelone.com/labs/ acidrain-a-modem-wiper-rains-down-on-europe/>.

60

 Dustin Volz, »Russian Hackers Tracked Ukrainian Artillery Units Using Android Implant: Report«, Reuters, 22.12.2016, <https://www.reuters.com/article/technology/ russian-hackers-tracked-ukrainian-artillery-units-using-android-implant-report-idUSKBN14B0CU/>; Jon Bateman, Russia’s Wartime Cyber Operations in Ukraine: Military Impacts, Influences, and Implications, Washington, D.C.: Carnegie Endowment for International Peace, 16.12.2022, <https://carnegieendowment.org/research/2022/12/russias-wartime-cyber-operations-in-ukraine-military-impacts-influences-and-implications?lang=en>.

61

 Lennart Maschmeyer, Subversion. From Covert Operations to Cyber Conflict, New York: Oxford University Press, 2024, doi: 10.1093/oso/9780197745854.001.0001; Matthias Schulze/ Mika Kerttunen, Cyber Operations in Russia’s War Against Ukraine. Uses, Limitations, and Lessons Learned so Far, Berlin: Stiftung Wissenschaft und Politik, April 2023 (SWP Comment 23/2023), doi: 10.18449/2023C23; Frederik A. Pedersen / Jeppe T. Jacobsen, »Narrow Windows of Opportunity: The Limited Utility of Cyber Operations in War«, in: Journal of Cybersecurity, 10 (2024) 1, doi: 10.1093/cybsec/tyae014.

62

 Zu den Teilnehmenden des Workshops, denen die Autorin zu großem Dank verpflichtet ist, zählen Amy Ertan, Andrew Dwyer, Chris Wysopal, Christoph Lobmeyer, Clotilde Bômont, Colin Topping, Daniel Voelsen, James Shires, John Scott, John Speed Meyers, Jörg Eschweiler, Marc Lanouette, Philip Engelmartin, Sara Ann Bracket, Sebastian Lange und Simon Stanley.

63

 Probasco, »Building the Tech Coalition« [wie Fn. 39], S. 9.

64

 Eine weitere Abwägung, nämlich ob Streitkräfte sich primär auf den Umgang mit den Risiken in den eigenen Software-Lieferketten oder auf die Ausnutzung von Schwach­stellen in gegnerischen Software-Lieferketten konzentrieren sollten, kann hier nicht diskutiert werden; die Argumente ähneln aber der Debatte zum Umgang mit Software-Schwach­stellen allgemein, siehe etwa Sven Herpig, Schwachstellen-Management für mehr Sicherheit. Wie der Staat den Umgang mit Zero-Day-Schwachstellen regeln sollte, Berlin: Interface, August 2018, <https://www.interface-eu.org/storage/archive/files/ vorschlag.schwachstellenmanagement.pdf>.

65

 John S. Meyers, »How to Fix the Military’s Software SNAFU«, Defense One, 4.4.2024, <https://www.defenseone.com/ ideas/2024/04/how-fix-militarys-software-snafu/395489/>.

66

 Bundesamt für Sicherheit in der Informationstechnik (BSI), Grundlagen des Cyber-Supply Chain Risk Management (C‑SCRM), Bonn, Oktober 2023, <www.bsi.bund.de/SharedDocs/ Downloads/DE/BSI/Publikationen/Broschueren/Management_Blitzlicht/Management_Blitzlicht_C-SCRM.html>.

67

 »Materiel and IT Command«, Ministry of Defence, Den Haag, <https://english.defensie.nl/organisation/materiel-and-it-command>.

68

 PwC, Strategische Marktanalyse zur Reduzierung von Abhängig­keiten von einzelnen Software-Anbietern, Berlin, August 2019, <www.cio.bund.de/SharedDocs/downloads/Webs/CIO/DE/ digitale-loesungen/marktanalyse-reduzierung-abhaengigkeit-software-anbieter.pdf>.

69

 Siehe dazu auch den Abschnitt »Ausschluss nicht vertrauenswürdiger Hersteller von der Vergabe«, S. 26.

70

 Sven Herpig, Fostering Open Source Software Security. Blue­print for a Government Cybersecurity Open Source Program Office, Berlin: Interface, 31.5.2023, S. 16, <https://www.interface-eu.org/index.php/publications/fostering-open-source-software-security>. Die militärische Nutzung von OSS hat Auswirkungen weit über den Umgang mit Software-Liefer­ketten-Risiken hinaus, die hier nicht diskutiert werden.

71

 Department of Defense (DoD), Chief Information Officer (CIO), Memorandum: Software Development and Open Source Software, Washington, D.C., 24.1.2022, <https://dodcio.defense.gov/portals/0/documents/library/ softwaredev-opensource.pdf>; dass., »Open Source Software FAQ«, Washington, D.C., 28.10.2021, <https://dodcio.defense. gov/Open-Source-Software-FAQ/>; dass., Open Technology Development (OTD). Lessons Learned and Best Practices for Military Software, Washington, D.C., 16.5.2011, <https://dodcio. defense.gov/portals/0/documents/foss/otd-lessons-learned-military-signed.pdf>.

72

 So finanziert etwa das Bundesministerium für Wirtschaft und Energie die Sovereign Tech Agency, die wiederum Einzelpersonen und Organisationen unterstützt, die sich der Absicherung von OSS widmen, siehe »Sovereign Tech Agency. Investing in the Infrastructure of the 21st Century«, Sovereign Tech Agency (online), Berlin, 25.4.2025, <www.sovereign.tech/>.

73

 Herpig, Fostering Open Source Software Security [wie Fn. 70], S. 17; Sara A. Bracket u.a., O$$ Security: Does More Money for Open Source Software Mean Better Security? A Proof of Concept, Washington, D.C.: Atlantic Council, 18.4.2024, <https://www.atlanticcouncil.org/content-series/cybersecurity-policy-and-strategy/o-security-does-more-money-for-open-source-software-mean-better-security-a-proof-of-concept/>.

74

 IT-Planungsrat, Föderale IT-Architekturrichtlinie. Version 1.9.0, 2025, S. 21–26, <www.it-planungsrat.de/beschluss/ beschluss-2025-17>.

75

 Herpig, Fostering Open Source Software Security [wie Fn. 70], S. 20–21.

76

 TODO Group, »Open Source Program Office (OSPO) Definition and Guide«, GitHub, 9.7.2024, <https://github.com/ todogroup/ospodefinition.org>; OpenForum Europe / OSPO Alliance, The OSPO. A New Tool for Digital Government, Brüssel, Juni 2022, S. 9ff, <https://openforumeurope.org/wp-content/ uploads/2022/06/The-OSPO-A-New-Tool-for-Digital-Government-2.pdf>; Herpig, Fostering Open Source Software Security [wie Fn. 70].

77

 BSI, »Vortrag des BSI beim Fachkongress Public-IT-Secu­rity im Juni 2025«, FragDenStaat, 3.6.2025, <https://fragdenstaat.de/anfrage/vortrag-des-bsi-beim-fachkongress-public-it-security-im-juni-2025/>.

78

 Siehe die Website von ZenDiS, <https://www.zendis.de/>.

79

 Dies sollte über die bestehende Zusammenarbeit zwischen der BWI GmbH und ZenDiS hinausgehen (»BWI und ZenDiS schließen Rahmenvertrag über souveräne Kommunikations- und Kollaborationslösungen«, ZenDiS, Bochum, 4.4.2025, <https://www.zendis.de/newsroom/presse/ bwi-und-zendis-schliessen-rahmenvertrag-ueber-souveraene-kommunikations-und-kollaborationsloesungen>).

80

 Shilla Saebi / Aison Yu, »Growing Sustainable Contri­butions through Ambassador Networks«, in: FOSDEM ’20, Brüssel, Februar 2020, <https://archive.fosdem.org/2020/ schedule/event/ambassadornetworks/>; Michael Picht, »How SAP Manages Open Source Software with an Open Source Program Office«, SAP, 28.10.2021, <https://community.sap.com/ t5/open-source-blogs/how-sap-manages-open-source-software-with-an-open-source-program-office/ba-p/13512864>.

81

 BSI, Grundlagen des Cyber-Supply Chain Risk Management [wie Fn. 66].

82

 BSI, Informationssicherheit mit System. Der IT-Grundschutz des BSI, Bonn, 22.10.2024, <www.bsi.bund.de/DE/Themen/ Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html>.

83

 Selbst wenn ein Softwareprodukt eine Komponente mit einer bekannten Schwachstelle enthält, stellt dies kein Sicher­heitsrisiko dar, wenn die Schwachstelle nicht aus­genutzt werden kann – etwa weil es an anderer Stelle im Code Schutzmaßnahmen gibt oder die Art und Weise der Einbindung der Komponente keine Ausnutzung erlaubt, siehe National Telecommunications and Information Ad­ministration (NTIA), Vulnerability-Exploitability eXchange (VEX) – An Overview, Washington, D.C., 27.9.2021, S. 1, <https:// www.ntia.gov/sites/default/files/publications/vex_one-page_ summary_0.pdf>.

84

 Boming Xia u.a., »An Empirical Study on Software Bill of Materials: Where We Stand and the Road Ahead«, in: 2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE), New York: IEEE, 2023, S. 2630–2642, doi: 10.1109/ ICSE48619.2023.00219.

85

 BSI, Technical Guideline TR-03183: Cyber Resilience Requirements for Manufacturers and Products. Part 2: Software Bill of Materials (SBOM), Bonn, 20.8.2025, S. 7, <http://www.bsi.bund.de/Shared Docs/Downloads/EN/BSI/Publications/TechGuidelines/TR03183/ BSI-TR-03183-2-2_0_0.pdf?__blob=publicationFile&v=3>.

86

 Cybersecurity and Infrastructure Security Agency (CISA), Types of Software Bill of Material (SBOM) Documents, Washington, D.C., 2023, <https://www.cisa.gov/sites/default/files/2023-04/sbom-types-document-508c.pdf>.

87

 Santiago Torres-Arias u.a., »A Viewpoint on Knowing Software: Bill of Materials Quality When You See It«, in: IEEE Security & Privacy, 21 (2023) 6, S. 50–54.

88

 BSI, Technical Guideline TR-03183 [wie Fn. 85].

89

 Omar Santos u.a., OpenEoX. A Standardized Framework for Managing End of Life and other Product Lifecycle Information, 24.4.2025, <https://docs.oasis-open.org/openeox/ standardization-framework/openeox-standardization-framework-technical-report.pdf>.

90

 Eine solche Definition kann auf Reifegradmetriken basieren wie etwa Linux Foundation, »OpenSSF Scorecard«, <https://securityscorecards.dev/>; OpenCode, »Badge Programm«, Bochum, 9.5.2025, <https://badges.opencode.de/ de/introduction/>. Die Einhaltung kann vertraglich vereinbart werden, J. C. Herz, »Crumbling Bridges: The Failed Eco­nomics of Software Maintenance«, in: Cyber Security: A Peer-Reviewed Journal, 8 (2024) 2, S. 150–159 (157).

91

 Ralf Wintergerst, IT-Fachkräfte 2040: Wo steht die deutsche Wirtschaft?, Berlin: Bitkom, 11.4.2024, <www.bitkom.org/ sites/main/files/2024-04/240411Bitkom-Charts-IT-Fachkraftemangel-2040final.pdf>.

92

 Probasco, »Building the Tech Coalition« [wie Fn. 39], S. 8.

93

 Diese werden im folgenden Kapitel dargestellt.

94

 Emily Dreyfuss, »Pentagon Weapons Systems Are Easy Cyberattack Targets, New Report Finds«, Wired, 10.10.2018, <https://www.wired.com/story/us-weapons-systems-easy-cyberattack-targets>; Bundeswehr, »CIR 2.0. Von der Idee zur Dimension«, in: cpm Forum für Rüstung, Streitkräfte und Sicherheit, September 2022, S. 83, <www.bundeswehr.de/resource/ blob/5519316/29945909e7ed8cc36f2c9ff4ecd53186/download-sonderheft-cir-2-0-data.pdf>.

95

 John S. Meyers u.a., »The US Military Should Red-Team Open Source Code«, Defense One, 10.8.2022, <www.defenseone.com/ideas/2022/08/military-should-red-team-open-source-code/375635/>.

96

 Wie im Fall der 5G-Telekommunikationstechnologie (siehe CSIS Working Group on Trust and Security in 5G Networks, Criteria for Security and Trust in Telecommunications Networks and Services, Washington, D.C.: Center for Strategic & International Studies, 13.5.2020, <https://www.csis.org/ analysis/criteria-security-and-trust-telecommunications-networks-and-services>) ist die Kategorie »(un)vertrauens­würdiger Anbieter« politisch geprägt.

97

 Kim Zetter, »Secret Code Found in Juniper’s Firewalls Shows Risk of Government Backdoors«, Wired, 19.12.2015, <https://www.wired.com/2015/12/juniper-networks-hidden-backdoors-show-the-risk-of-government-backdoors/>.

98

 Der Begriff »Anbieter« bezieht sich hier nicht nur auf Software-Hersteller, sondern auf jede Einheit in der Software-Lieferkette, die die Software anpasst, wie Wieder­verkäufer/Distributoren (wenn sie das Produkt anpassen), Systemintegratoren oder Hardware-Anbieter, siehe CISA, Framing Software Component Transparency: Establishing a Common Software Bill of Materials (SBOM), 3. Aufl., Washington, D.C., 3.9.2024, S. 26, <https://www.cisa.gov/sites/default/files/2024-10/SBOM%20Framing%20Software%20Component%20Transparency%202024.pdf>.

99

 Rolf Hager, »Software Defined Defence. Schnellere Soft­wareentwicklung für die Bundeswehr mit der ›Platform42‹«, in: Europäische Sicherheit & Technik, 19.3.2024, <https://esut.de/2024/03/fachbeitraege/47794/it-news-software-defined-defence-schnellere-softwareentwicklung-fuer-die-bundeswehr-mit-der-platform42/>.

100

 Siehe z. B. Murugiah Souppaya u.a., Secure Software Development Framework (SSDF) Version 1.1. Recommendations for Mitigating the Risk of Software Vulnerabilities, Gaithersburg: National Institute of Standards and Technology (NIST), Februar 2022; »Fundamental Practices for Secure Software Development. Essential Elements of a Secure Development Lifecycle Program«, SAFECode, März 2018, <https://safecode.org/uncategorized/fundamental-practices-secure-software-development/>; BSI, Technical Guideline TR-03183: Cyber Resilience Requirements for Manufacturers and Pro­ducts. Part 1: General Requirements, Bonn, 20.9.2024, <https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/ Publications/TechGuidelines/TR03183/BSI-TR-03183-1-0_9_0.pdf?__blob=publicationFile&v=4>.

101

 »Reduce Supply Chain Risk. Continuous SBOM Analysis Platform«, Dependency Track, <https://dependencytrack.org/>.

102

 Alex Gaynor, »Introduction to Memory Unsafety for VPs of Engineering«, alexgaynor.net, 12.8.2019, <https://alexgaynor.net/2019/aug/12/introduction-to-memory-unsafety-for-vps-of-engineering/#what-is-memory-unsafety>.

103

 »Requirements«, SLSA, <https://slsa.dev/spec/v0.1/ requirements>; Mikaël Barbero, »Understanding Software Provenance«, Opera Omnia, 26.12.2023, <https://mikael. barbero.tech/blog/post/2023-12-26-understanding-software-provenance>.

104

 »Definitions«, Reproducible Builds, <https://reproducible-builds.org/docs/definition/>; Chris Lamb / Stefano Zacchiroli, »Reproducible Builds: Increasing the Integrity of Software Supply Chains«, in: IEEE Software, 39 (2022) 2, S. 62–70; openCode / ZenDiS / BSI: Sichere Softwarelieferketten: openCode als Baustein einer souveränen digitalen Infrastruktur, Bochum, März 2025, <www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/ ZenDiS/Strategiepapier-Softwarelieferketten.pdf?__blob= publicationFile&v=2>.

105

 NTIA, Survey of Existing SBOM Formats and Standards, Washington, D.C., 2021, <www.ntia.gov/sites/default/files/ publications/sbom_formats_survey-version-2021_0.pdf>.

106

 CISA, Framing Software Component Transparency [wie Fn. 98], S. 10f. Eine solche Anforderung würde über die Anforderung des CRA hinausgehen, nur die erste Ebene von Komponenten darzustellen, siehe Europäisches Parlament und Rat, Verordnung (EU) 2024/2847 des Europäischen Parlaments und des Rates vom 23. Oktober 2024 über horizontale Cybersicherheitsanforderungen für Produkte mit digitalen Elementen und zur Änderung der Verordnungen (EU) Nr. 168/2013 und (EU) 2019/1020 und der Richtlinie (EU) 2020/1828 (Cyberresilienz-Verordnung), 23.10.2024, Anhang I, Teil I(1), <https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX: 32024R2847>).

107

 Common Security Advisory Framework (CSAF), <www.csaf.io/>; NTIA, Vulnerability-Exploitability eXchange [wie Fn. 83].

108

 Europäisches Parlament und Rat, Cyberresilienz-Verord­nung [wie Fn. 106], Art. 13(5).

109

 Ebd, Art. 2(7).

110

 Santos u.a., OpenEoX [wie Fn. 89].

111

 Scott Rose u.a., Zero Trust Architecture, Gaithersburg: NIST, August 2020, doi: 10.6028/NIST.SP.800-207.

112

 Allen D. Householder u.a., The CERT Guide to Coordinated Vulnerability Disclosure, Pittsburgh: Carnegie Mellon University, August 2017, <https://insights.sei.cmu.edu/documents/1945/ 2017_003_001_503340.pdf>.

113

 Murugiah Souppaya / Karen Scarfone, Guide to Enterprise Patch Management Planning. Preventive Maintenance for Technology (NIST SP 800-40 Rev. 4), Gaithersburg: NIST, 2022, doi: 10.6028/NIST.SP.800-40r4.

114

 NIST, The NIST Cybersecurity Framework (CSF) 2.0, Gaithersburg: NIST, 26.2.2024, <https://nvlpubs.nist.gov/ nistpubs/CSWP/NIST.CSWP.29.pdf>.

115

 John S. Meyers / Paul Gibert, »Questioning the Con­ventional Wisdom on Liability and Open Source Software«, in: Lawfare, April 2024, <www.lawfaremedia.org/article/ questioning-the-conventional-wisdom-on-liability-and-open-source-software>; Olaf Kolkman, »The EU’s Proposed Cyber Resilience Act Will Damage the Open Source Ecosystem«, Internet Society, 24.10.2022, <www.internetsociety.org/blog/ 2022/10/the-eus-proposed-cyber-resilience-act-will-damage-the-open-source-ecosystem/>.

116

 Herz, Crumbling Bridges [wie Fn. 90], S. 157.

117

 Für ein Beispiel aus dem zivilen Bereich siehe Der Beauftragte der Bundesregierung für Informationstechnik, Aktuelle EVB-IT, Berlin, 2.11.2023, <https://www.cio.bund.de/ Webs/CIO/DE/digitale-loesungen/it-einkauf/evb-it-und-bvb/evb-it/evb-it-node.html>.

118

 BMVg, Projektbezogene Bedarfsdeckung und Nutzung [wie Fn. 43].

119

 Siehe etwa The White House, Executive Order on Improving the Nation’s Cybersecurity (EO 14028), Washington, D.C., 12.5.2021, <https://bidenwhitehouse.archives.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/>.

120

 DoD, Department of the Army, Memorandum: Assistant Secretary of the Army (Acquisition, Logistics and Technology) Software Bill of Materials Policy, Washington, D.C., 17.10.2024, <https://api.army.mil/e2/c/downloads/2024/10/17/4072ab1e/ asaalt-software-bill-of-materials-policy-signed.pdf>.

121

 Deutscher Bundestag, Vorgang – Gesetzgebung: Gesetz zur beschleunigten Planung und Beschaffung für die Bundeswehr, Berlin 2025, <https://dip.bundestag.de/vorgang/gesetz-zur-beschleunigten-planung-und-beschaffung-f%C3%BCr-die-bundeswehr/324833>; Francesco Nicoli, Mapping the Road Ahead for EU Public Procurement Reform, Brüssel: Bruegel, 31.3.2025, <https://www.bruegel.org/first-glance/mapping-road-ahead-eu-public-procurement-reform>; Deutscher Bundestag, Vorgang – Gesetzgebung: Gesetz zur Beschleunigung der Vergabe öffentlicher Aufträge, Berlin 2025, <https://dip.bundestag.de/vorgang/gesetz-zur-beschleunigung-der-vergabe-%C3%B6ffentlicher-auftr%C3%A4ge/324928>.

122

 Für einen Überblick dieser Hindernisse siehe etwa Iain G. Mitchell, »Public Sector and Open Source«, in: Amanda Brock (Hg.), Open Source Law, Policy and Practice, Oxford: Oxford University Press, 2022, S. 429–468, <https://academic.oup.com/book/44727>.

123

 Trey Herr u.a., Buying Down Risk: Cyber Liability, Washing­ton, D.C.: Atlantic Council, 15.1.2025, <www.atlanticcouncil. org/content-series/buying-down-risk/cyber-liability/>; Gergely Biczók u.a., Realigning Incentives to Build Better Software: A Holistic Approach to Vendor Accountability, 10.4.2025, <http://arxiv.org/ pdf/2504.07766v1>.

124

 Gesetz über die Haftung für fehlerhafte Produkte. (ProdHaftG), 15.12.1989, <https://www.gesetze-im-internet.de/prodhaftg/ BJNR021980989.html>.

125

 Europäisches Parlament und Rat, Richtlinie (EU) 2024/ 2853 des Europäischen Parlaments und des Rates vom 23. Oktober 2024 über die Haftung für fehlerhafte Produkte und zur Aufhebung der Richtlinie 85/374/EWG des Rates, 23.10.2024, <https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX: 32024L2853>.

126

 Europäisches Parlament und Rat, Cyberresilienz-Verord­nung [wie Fn. 106], Art. 2(7).

127

 Maia Hamin u.a., »Three Questions on Software Liabili­ty«, in: Lawfare, September 2023, <www.lawfaremedia.org/ article/three-questions-on-software-liability>; Chinmayi Sharma / John S. Meyers, »Bugs in the Software Liability Debate«, Just Security, 18.7.2023, <www.justsecurity.org/ 87294/bugs-in-the-software-liability-debate/>.

128

 Paulus / Rupp, Government’s Role in Increasing Software Supply Chain Security [wie Fn. 24], S. 32f.

129

 DoD, CIO, About CMMC, Washington, D.C., <https://dodcio.defense.gov/CMMC/About/>.

130

 Europäisches Parlament und Rat, Cyberresilienz-Verordnung [wie Fn. 106].

131

 BSI, Transparente Sicherheit durch das IT-Sicherheits­kennzeichen, Bonn, 9.2.2023, <https://www.bsi.bund.de/DE/ Themen/Unternehmen-und-Organisationen/IT-Sicherheitskennzeichen/it-sicherheitskennzeichen_ node.html>.

132

 »Mehrheit für Reform der Schuldenbremse: 512 Ab­geordnete stimmen mit Ja«, Deutscher Bundestag, 18.3.2025, <www.bundestag.de/dokumente/textarchiv/2025/kw12-de-sondersitzung-1056916>.

133

 Probasco, Building the Tech Coalition [wie Fn. 39].

Dieses Werk ist lizenziert unter CC BY 4.0

SWP-Studien unterliegen einem Verfahren der Begut­achtung durch Fachkolle­ginnen und -kollegen und durch die Institutsleitung (peer review), sie werden zudem einem Lektorat unterzogen. Weitere Informationen zur Qualitätssicherung der SWP finden Sie auf der SWP-Website unter https:// www.swp-berlin.org/ueber-uns/qualitaetssicherung/.
SWP‑Studien geben die Auffassung der Autoren und Autorinnen wieder.

SWP

Stiftung Wissenschaft und Politik

Deutsches Institut für Internationale Politik und Sicherheit

Ludwigkirchplatz 3–4
10719 Berlin
Telefon +49 30 880 07-0
Fax +49 30 880 07-200
www.swp-berlin.org
swp@swp-berlin.org

ISSN (Print) 1611-6372

ISSN (Online) 2747-5115

DOI: 10.18449/2025S14