Sicherheit der Software-Lieferkette

Warum Abhängigkeiten eine Angriffsfläche sind

Der meiste Code in einem modernen Service wurde nicht von dem Team geschrieben, das ihn betreibt. Ein kleiner Webservice deklariert vielleicht zwanzig direkte Abhängigkeiten und installiert über deren eigene Abhängigkeiten mehrere hundert Pakete; der Container, in dem er ausgeliefert wird, bringt ein Betriebssystem-Userland mit, und die Pipeline, die ihn baut, führt Compiler, Plug-ins und CI-Actions aus, die wiederum andere geschrieben haben. Abschnitt 0.3 stellte Abhängigkeiten als Aufwandsersparnis mit Wartungskosten vor. Dieser Abschnitt betrachtet ihre Sicherheitskosten: Jede dieser Komponenten und jede Person und jedes System, die sie ändern können, gehört zu Ihrer Angriffsfläche.

Ein Software-Supply-Chain-Angriff kompromittiert etwas, das Sie nutzen, um Sie zu erreichen, meist viele Opfer auf einmal. Er kann auf vier grundlegenden Wegen kommen. Schadcode aus einer vertrauenswürdigen Quelle: Das Konto eines Maintainers wird per Phishing übernommen, ein Maintainer wird feindselig, oder ein Projekt wird einem Fremden übergeben. Bösartige Doppelgänger: Typosquatting veröffentlicht reqeusts neben requests; Dependency Confusion, im Februar 2021 von Alex Birsan demonstriert, veröffentlicht in der öffentlichen Registry ein Paket mit demselben Namen wie ein internes Paket eines Unternehmens und einer höheren Versionsnummer, das manche Build-Tools dann bevorzugen. Manipulation in der Pipeline: Der Quellcode ist in Ordnung, aber das Build-System, die Signaturschlüssel oder die Registry sind kompromittiert. Ehrliche Schwachstellen: Am Schreiben des Codes war kein Angreifer beteiligt, aber ein schwerer Fehler in einer weit verbreiteten transitiven Abhängigkeit gefährdet jeden, der sie ausliefert.

Die letzten Jahre haben gezeigt, wie schnell sich die erste Art ausbreitet. Im März 2025 wurden die Versions-Tags einer beliebten GitHub Action, tj-actions/changed-files, auf einen bösartigen Commit verschoben, der CI-Secrets in Build-Logs ausgab; betroffen waren Tausende Repositorys, die per Tag auf die Action verwiesen. Im September 2025 wurde ein Maintainer weit verbreiteter npm-Pakete wie chalk und debug über eine gefälschte npm-Support-Seite per Phishing getäuscht, und bösartige Versionen wurden veröffentlicht und binnen Stunden wieder entfernt; später im selben Monat stahl ein sich selbst verbreitender Wurm mit dem Spitznamen Shai-Hulud npm-Tokens und veröffentlichte damit infizierte Versionen weiterer Pakete.

Vier Vorfälle, genau erzählt

event-stream (2018). event-stream war ein beliebtes npm-Paket mit rund zwei Millionen Downloads pro Woche, für das sein ursprünglicher Autor keine Zeit mehr hatte. Im September 2018 übergab er die Veröffentlichungsrechte an einen Freiwilligen, der Hilfe angeboten hatte. Der neue Maintainer fügte eine Abhängigkeit hinzu, flatmap-stream, deren veröffentlichtes Paket eine verschlüsselte Nutzlast enthielt, die nur im Build von Copay, einer Bitcoin-Wallet-Anwendung, aktiv wurde und versuchte, Wallets mit hohen Guthaben zu stehlen. Ein Entwickler bemerkte den verdächtigen Code im November 2018. Nichts am Modell von npm war gebrochen worden: Ein vertrauenswürdiger Name hatte einfach den Besitzer gewechselt.

SolarWinds (2020). Angreifer, die die US-Regierung später dem russischen Auslandsgeheimdienst zuordnete, verschafften sich Zugang zur Build-Umgebung von SolarWinds, dem Hersteller des Netzwerkmanagement-Produkts Orion. Ein Implantat (von den Ermittlern SUNSPOT genannt) wartete auf Orion-Builds, tauschte während der Kompilierung eine Quelldatei gegen eine Version mit Backdoor aus und legte anschließend das Original zurück. Die so entstandenen Updates, veröffentlicht zwischen März und Juni 2020, wurden von SolarWinds’ eigener Pipeline gebaut und mit dem echten Zertifikat des Unternehmens signiert. Rund 18.000 Kunden installierten sie; die Angreifer wählten dann eine viel kleinere Zahl von Behörden und Unternehmen für weitere Eindringversuche aus. FireEye entdeckte die Kampagne im Dezember 2020 bei der Untersuchung eines Angriffs auf das eigene Unternehmen. Die Lehre für Architekten: Eine Signatur beweist, wer etwas gebaut hat, nicht, dass der Build sauber war.

Log4Shell (2021). CVE-2021-44228, am 9. Dezember 2021 offengelegt und nach CVSS mit 10,0 bewertet, war ein Fehler in Log4j 2, der dominierenden Logging-Bibliothek für Java. Log4j löste Lookups auf, die in Log-Nachrichten standen, darunter JNDI-Lookups, die eine Klasse von einem entfernten Server laden konnten; ein Angreifer, der eine Zeichenkette wie einen Benutzernamen oder einen Request-Header ins Log bringen konnte, konnte so Code auf dem Server ausführen. Kein Angreifer hatte die Lieferkette angetastet; der Schaden entstand dadurch, wie weit verbreitet und wie tief eingebettet die Bibliothek war. Organisationen verbrachten Wochen damit herauszufinden, wo sie sie nutzten, mehrere Folge-Releases waren nötig, um verwandte Fehler zu schließen, und wer ein genaues Inventar hatte, beantwortete die Frage in Stunden.

xz utils (2024). xz ist eine Kompressionsbibliothek, die über andere Bibliotheken vom OpenSSH-Server mehrerer Linux-Distributionen genutzt wird. Über etwa zwei Jahre leistete ein Konto namens Jia Tan nützliche Beiträge und wurde, unterstützt von weiteren Konten, die den überlasteten ursprünglichen Maintainer drängten, Hilfe anzunehmen, zum Co-Maintainer. Die Versionen 5.6.0 und 5.6.1, veröffentlicht im Februar und März 2024, enthielten eine Backdoor, mit der der Inhaber eines bestimmten privaten Schlüssels Befehle über SSH hätte ausführen können. Der Schadcode war in binären Testdateien versteckt und wurde durch ein verändertes Build-Skript aktiviert, das nur in den Release-Tarballs existierte, nicht im öffentlichen Repository. Am 29. März 2024 machte Andres Freund, ein Entwickler bei Microsoft, sie öffentlich, nachdem er untersucht hatte, warum SSH-Logins auf einem Testsystem ungewöhnlich viel CPU verbrauchten und etwa eine halbe Sekunde länger dauerten; sie wurde als CVE-2024-3094 erfasst. Weil sie früh entdeckt wurde, hatte sie vor allem Entwicklungs- und Rolling-Release-Distributionen erreicht und kaum stabile.

Software Bills of Materials

Eine Software Bill of Materials (SBOM) ist eine maschinenlesbare Liste der Komponenten einer Software mit Versionen, Kennungen und den Beziehungen zwischen ihnen. Sie macht Software nicht von selbst sicherer; sie macht Fragen beantwortbar. Wird das nächste Log4Shell bekannt, verwandelt ein durchsuchbarer Bestand an SBOMs für jedes deployte Artefakt die Frage Sind wir betroffen, und wo? in eine Abfrage.

Zwei Formate dominieren. SPDX von der Linux Foundation begann als Format für Lizenz-Compliance; Version 2.2.1 ist die internationale Norm ISO/IEC 5962:2021, und SPDX 3.0 (2024) ergänzt Profile für Sicherheit, Builds und KI. CycloneDX, ein OWASP-Projekt für Sicherheitsanwendungsfälle, ist von Ecma International als ECMA-424 standardisiert; Version 1.7 erschien im Oktober 2025. Beide können Komponenten mit einer Package URL (purl) wie pkg:npm/express@4.21.2 identifizieren, und genau damit gleichen Schwachstellendatenbanken ab. Die ergänzende Idee VEX (Vulnerability Exploitability eXchange) erlaubt es einem Lieferanten zu erklären, dass eine gelistete verwundbare Komponente in seinem Produkt nicht ausnutzbar ist, etwa weil die verwundbare Funktion nie aufgerufen wird; das verringert das Rauschen für die Kunden.

Die Politik hat SBOMs in den Mainstream gebracht. Die US Executive Order 14028, Improving the Nation's Cybersecurity, unterzeichnet am 12. Mai 2021, legte Maßnahmen für die Software-Lieferkette bei Software fest, die an die Bundesregierung verkauft wird, darunter die Bereitstellung einer SBOM für Käufer; die National Telecommunications and Information Administration veröffentlichte daraufhin die Mindestelemente einer SBOM (Lieferant, Komponentenname, Version, weitere eindeutige Kennungen, Abhängigkeitsbeziehungen, Autor der SBOM-Daten und ein Zeitstempel). Die US-Politik hat sich seither von einheitlichen Vorgaben entfernt: Im Januar 2026 hob das Memorandum M-26-05 des Office of Management and Budget die frühere Pflicht von Lieferanten auf, sichere Entwicklungspraktiken zu bescheinigen; die Behörden legen nun risikobasierte Anforderungen fest und verlangen SBOMs, wo sie es für richtig halten. In der EU macht die weiter unten beschriebene Cyberresilienz-Verordnung eine SBOM zum Teil der technischen Dokumentation für Produkte mit digitalen Elementen.

Erzeugen Sie SBOMs während des Builds, aus dem, was tatsächlich aufgelöst und paketiert wurde, statt aus dem Manifest, das ein Entwickler geschrieben hat; speichern Sie sie neben dem Artefakt, mit dessen Digest als Schlüssel; und speisen Sie sie in einen Service ein, der jede gespeicherte SBOM erneut prüft, sobald eine neue Schwachstelle veröffentlicht wird.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "metadata": {"timestamp": "2026-10-20T09:14:02Z",
               "component": {"bom-ref": "orders-service", "type": "application",
                             "name": "orders-service", "version": "4.12.0"}},
  "components": [
    {"bom-ref": "log4j-core", "type": "library", "name": "log4j-core",
     "group": "org.apache.logging.log4j", "version": "2.24.3",
     "purl": "pkg:maven/org.apache.logging.log4j/log4j-core@2.24.3",
     "hashes": [{"alg": "SHA-256", "content": "9f2c..."}]},
    {"bom-ref": "jackson-databind", "type": "library", "name": "jackson-databind",
     "version": "2.18.2",
     "purl": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.18.2"}
  ],
  "dependencies": [
    {"ref": "orders-service", "dependsOn": ["log4j-core", "jackson-databind"]}
  ]
}

SLSA: Level für die Build-Integrität

SLSA (Supply-chain Levels for Software Artifacts, ausgesprochen salsa) ist ein Framework, inzwischen unter dem Dach der Open Source Security Foundation gepflegt, das aufeinander aufbauende Schutzstufen gegen Manipulation beschreibt. Version 1.0 (2023) definierte einen Build-Track; Version 1.2 gliederte die Spezifikation in mehrere Tracks und ergänzte einen Source-Track. Das zentrale Artefakt ist die Provenienz: eine signierte Aussage, meist im Attestierungsformat von in-toto, darüber, welche Build-Plattform ein Artefakt erzeugt hat, aus welcher Quellcode-Revision und mit welcher Build-Definition und welchen Parametern. Ein Konsument prüft die Provenienz gegen Erwartungen wie von unserer CI aus dem main-Branch von github.com/fooddelivery/orders gebaut.

Der Source-Track hat vier Level: Versionskontrolle (L1), eine fortlaufende, unveränderliche Historie mit Provenienz für jede Revision (L2), fortlaufend durchgesetzte technische Kontrollen wie geschützte Branches (L3) und ein Review durch zwei Personen für jede Änderung an geschützten Branches (L4). Für die meisten Organisationen ist das realistische Ziel Build L3 auf einer gemeinsamen, gut betriebenen Build-Plattform plus Source L3 oder L4 für wichtige Repositorys; die Level sagen, was eine Plattform garantieren muss, und ein Plattformteam kann sie einmal für alle Services erfüllen.

Signieren und Provenienz mit Sigstore

Artefakte zu signieren ist seit Langem möglich, doch die Verwaltung langlebiger Signaturschlüssel war so mühsam, dass nur wenige Open-Source-Projekte es taten, und gestohlene Schlüssel waren selbst ein Risiko. Sigstore, 2021 gestartet und heute Teil der Open Source Security Foundation, macht das Signieren durch schlüsselloses Signieren billig. Ein CI-Job weist Fulcio, der Zertifizierungsstelle von Sigstore, seine Identität mit einem OpenID-Connect-Token nach; Fulcio stellt ein wenige Minuten gültiges Zertifikat aus, das diese Identität nennt, etwa einen bestimmten Workflow in einem bestimmten Repository; das Tool signiert das Artefakt und erfasst die Signatur in Rekor, einem öffentlichen Transparenzlog, an das nur angefügt werden kann; der ephemere private Schlüssel wird danach verworfen. Prüfer kontrollieren die Signatur, die Identität im Zertifikat und den Log-Eintrag, statt einem Schlüssel zu vertrauen, der durchgesickert sein könnte.

Das Tool cosign wendet das auf Container-Images und andere Artefakte an, und Paket-Ökosysteme haben dieselben Ideen übernommen: npm kann Pakete mit Provenienzangaben veröffentlichen, die sie mit dem Quell-Repository und dem Build verknüpfen (2023), und PyPI unterstützt Trusted Publishing aus der CI ohne langlebige Tokens (2023) sowie auf Sigstore basierende Attestierungen (2024). Beim Deployment kann ein Admission Controller in Kubernetes, etwa der Policy Controller von Sigstore oder Kyverno, jedes Image ablehnen, das nicht von der erwarteten Identität signiert ist oder dem die erwartete Provenienz fehlt. Denken Sie an SolarWinds: Signatur und Provenienz beweisen, woher etwas stammt; erst Build-Isolation, Review und Erkennung machen vertrauenswürdig, was dabei herauskommt.

Lockfiles, Pinning und automatisierte Updates

Ein Manifest wie package.json oder pyproject.toml gibt zulässige Versionsbereiche an; ein Lockfile (package-lock.json, poetry.lock, uv.lock, go.sum, Cargo.lock) hält die exakt aufgelösten Versionen fest, meist mit einem kryptografischen Hash für jede. Wird das Lockfile committet und in der CI daraus installiert (npm ci, pip install --require-hashes), nutzt jeder Build dieselben geprüften Bytes, und ein mit anderem Inhalt neu veröffentlichtes Paket fällt bei der Hash-Prüfung durch. Pinning gilt auch für Build-Werkzeuge: Verweisen Sie auf CI-Actions per vollständigem Commit-Hash, nicht per Tag, den der Eigentümer oder ein Angreifer verschieben kann, denn genau das ließ den tj-actions-Vorfall sich ausbreiten; verweisen Sie auf Basis-Images per Digest.

Pinning ohne Updates schafft das umgekehrte Risiko: Alte Versionen sammeln bekannte Schwachstellen an, und Upgrades werden zu groß, um sie noch anzugehen. Update-Bots wie Dependabot und Renovate öffnen kleine, häufige Pull Requests, die die CI automatisch testet. Eine nützliche Verfeinerung ist ein Mindestalter für Releases: einige Tage warten, bevor man eine routinemäßige neue Version übernimmt, denn die meisten bösartigen Releases werden innerhalb von Stunden oder Tagen entdeckt und zurückgezogen; Sicherheitskorrekturen sind davon ausgenommen und werden beschleunigt.

Werkzeuge für Software Composition Analysis (SCA) wie OWASP Dependency-Check, Trivy, Grype oder kommerzielle Dienste gleichen Ihre Abhängigkeiten mit Schwachstellendatenbanken ab. Ihre Schwäche ist das Rauschen: Hunderte Befunde, die meisten in Codepfaden, die Sie nie aufrufen. Priorisieren Sie mit Exploit-Daten (steht die Schwachstelle im Katalog Known Exploited Vulnerabilities der CISA, wie hoch ist ihr EPSS-Wert?), mit Erreichbarkeitsanalyse, wo Ihre Werkzeuge sie bieten, und mit der Exposition (ist der Service aus dem Internet erreichbar?). Abschnitt 8.8 behandelt Schwachstellenmanagement als Prozess.

Container und Build-Integrität

Ein Container-Image enthält neben Ihrem Code ein Betriebssystem-Userland, und jedes Paket darin gehört zur Lieferkette. Beginnen Sie mit minimalen Basis-Images (distroless, Alpine oder schlanke Distributions-Images), die weniger potenziell verwundbare Pakete enthalten; bauen Sie Images regelmäßig neu, damit Korrekturen im Basis-Image ankommen, auch wenn sich Ihr Code nicht geändert hat; scannen Sie Images in der CI und laufend erneut in der Registry, weil jeden Tag neue Schwachstellen für alte Images veröffentlicht werden; und deployen Sie Images per Digest, damit genau das läuft, was gescannt wurde.

Das Build-System ist das wertvollste Ziel in der Kette, weil es alles berührt, wie SolarWinds gezeigt hat. Lassen Sie Builds auf ephemeren Runnern laufen, die für einen einzigen Job erstellt und danach zerstört werden, damit sich ein Angreifer nicht zwischen Builds festsetzen kann. Machen Sie Builds hermetisch, mit allen Eingaben deklariert und per Hash abgerufen und ohne Netzwerkzugriff während der Kompilierung, damit keine nicht deklarierten Eingaben hineingelangen. Halten Sie langlebige Secrets aus der CI heraus, indem Sie per OIDC-Föderation für jeden Job kurzlebige Cloud-Zugangsdaten beziehen, und geben Sie jeder Pipeline nur die geringsten nötigen Rechte, damit ein Pull Request aus einem Fork die Deployment-Zugangsdaten nicht erreichen kann. Schützen Sie den Release-Pfad mit Branch-Schutz und Review durch zwei Personen. Schließlich erlauben reproduzierbare Builds, bei denen derselbe Quellcode stets eine bitgenau identische Ausgabe ergibt, unabhängigen Parteien, neu zu bauen und zu vergleichen; das Projekt Reproducible Builds und Distributionen wie Debian haben die meisten ihrer Pakete reproduzierbar gemacht, und eine Abweichung ist ein starkes Indiz für Manipulation.

Die Cyberresilienz-Verordnung der EU

Die Cyberresilienz-Verordnung (CRA), Verordnung (EU) 2024/2847, legt horizontale Cybersicherheitsanforderungen für Produkte mit digitalen Elementen fest, die auf dem Unionsmarkt bereitgestellt werden: Hardware- und Softwareprodukte einschließlich ihrer Lösungen zur Datenfernverarbeitung. Sie ist am 10. Dezember 2024 in Kraft getreten und gilt stufenweise. Die Vorschriften über die Notifizierung von Konformitätsbewertungsstellen gelten ab dem 11. Juni 2026. Die Meldepflichten nach Artikel 14 gelten ab dem 11. September 2026: Ein Hersteller muss eine aktiv ausgenutzte Schwachstelle oder einen schwerwiegenden Sicherheitsvorfall, der die Sicherheit seines Produkts beeinträchtigt, mit einer Frühwarnung innerhalb von 24 Stunden, nachdem er davon Kenntnis erlangt hat, einer ausführlicheren Meldung innerhalb von 72 Stunden und später einem Abschlussbericht melden (bei einer Schwachstelle spätestens 14 Tage, nachdem eine Korrekturmaßnahme verfügbar ist; bei einem schwerwiegenden Vorfall innerhalb eines Monats), und zwar über die einheitliche Meldeplattform, die von ENISA, der Agentur der Europäischen Union für Cybersicherheit, betrieben wird. Die meisten übrigen Pflichten gelten ab dem 11. Dezember 2027.

Die grundlegenden Anforderungen in Anhang I sind ebenso architektonisch wie verfahrensbezogen: Produkte müssen so konzipiert sein, dass sie ein angemessenes Cybersicherheitsniveau gewährleisten, mit einer sicheren Standardkonfiguration bereitgestellt werden, Angriffsflächen begrenzen, die Vertraulichkeit und Integrität von Daten schützen, Daten minimieren sowie sicherheitsrelevante Ereignisse protokollieren und Sicherheitsupdates empfangen können. Hersteller müssen Komponenten ermitteln und dokumentieren, unter anderem durch die Erstellung einer SBOM, die zumindest die obersten Abhängigkeiten erfasst, Schwachstellen über eine Strategie zur koordinierten Offenlegung behandeln und Sicherheitsupdates für einen Unterstützungszeitraum bereitstellen, der in der Regel mindestens fünf Jahre betragen sollte, es sei denn, das Produkt wird voraussichtlich kürzer verwendet. Geldbußen für Verstöße gegen die grundlegenden Anforderungen oder die Pflichten der Hersteller können bis zu 15 Millionen EUR oder 2,5 % des weltweiten Jahresumsatzes betragen, je nachdem, welcher Betrag höher ist.

Der Anwendungsbereich ist entscheidend. Freie und quelloffene Software, die außerhalb einer Geschäftstätigkeit entwickelt oder bereitgestellt wird, fällt nicht unter die Cyberresilienz-Verordnung, und für Verwalter quelloffener Software, die solche Software für die kommerzielle Nutzung unterstützen, gilt eine leichtere Regelung. Reine Software as a Service fällt grundsätzlich nicht unter die Verordnung, es sei denn, sie ist die Lösung zur Datenfernverarbeitung eines Produkts; Cloud- und andere digitale Diensteanbieter können stattdessen unter die NIS-2-Richtlinie fallen. Ob ein bestimmtes Produkt in den Anwendungsbereich fällt und welches Konformitätsbewertungsverfahren gilt, ist eine Rechtsfrage für jede Organisation; die architektonische Folge ist, dass SBOMs, Schwachstellenbehandlung, Update-Mechanismen und Sicherheitsprotokollierung zu Nachweisen werden, die vorhanden sein müssen, statt guter Absichten.