Software Supply Chain Security
Seit dem SolarWinds-Angriff (2020) ist der Begriff allgegenwärtig. Der Stuxnet-Angriff 2009/2010 auf Siemens Step 7-SPSen im Iran war vielleicht der erste prominente Vorfall dieser Art. Aber echte Maßnahmen folgten erst 2020 mit dem SUNBURST-Ereignis und der Executive Order 14028, die jeden Softwareanbieter, der Dienstleistungen für US-Behörden erbringt, dazu verpflichtete, SBOMs bereitzustellen, einen Mindestsicherheitsstandard für an die US-Regierung verkaufte Software festzulegen und die Erkennung, Untersuchung und den Austausch von Informationen über Cybervorfälle zwischen Regierungsbehörden und dem privaten Sektor zu verbessern. Seit dieser Zeit gewinnen auch Zero-Trust-Architekturen im staatlichen Bereich an Bedeutung.
Um mehr über die Natur solcher Angriffe zu erfahren, lesen Sie die folgenden Artikel:
Der SolarWinds-Angriff, von Forschern unter dem Codenamen SUNBURST bezeichnet, ist einer der raffiniertesten und folgenschwersten Angriffe auf die Software-Lieferkette in der Geschichte. Der Kernansatz des Angriffs bestand darin, in das Netzwerk von SolarWinds, einem Anbieter von Netzwerkmanagement-Software, einzudringen und hochentwickelten Schadcode direkt in die Build-Umgebung ihres Flaggschiffprodukts Orion einzuschleusen. Diese Methode, Malware in ein legitimes, vertrauenswürdiges Software-Update einzubetten, wird als Tainted Artifact-Angriff bezeichnet.
Der Schadcode wurde sorgfältig in das Orion-Quellcode-Repository eingefügt. Während des Standard-Build-Prozesses wurde die Malware zusammen mit der echten Software kompiliert und mit den privaten Schlüsseln von SolarWinds digital signiert, sodass das resultierende trojanisierte Update für alle Sicherheitstools und -systeme völlig legitim erschien. Die Angreifer erzielten eine tiefgreifende Penetration und geduldige Aufklärung und verteilten die kontaminierten Updates zwischen März und Juni 2020 an etwa 18.000 Kunden von SolarWinds, darunter Regierungsbehörden, Rüstungsunternehmen und große Technologieunternehmen.
Die Auswirkungen des SUNBURST-Angriffs waren tiefgreifend, da er das implizite Vertrauen ausnutzte, das mit Updates von Anbietern einhergeht. Nach der Installation blieb das bösartige Update wochenlang inaktiv, bevor es diskret eine Hintertür aktivierte, die es den Angreifern ermöglichte, dauerhaften privilegierten Zugriff auf hochsensible interne Netzwerke zu erhalten. Der Vorfall unterstrich das verheerende Potenzial einer Kompromittierung der Lieferkette, bei der ein Angreifer nur einen einzigen vorgelagerten Anbieter kompromittieren muss, um anschließend Tausende von hochwertigen nachgelagerten Zielen anzugreifen, wodurch sich der Schwerpunkt der Cybersicherheit grundlegend von der Perimeterverteidigung auf die Integrität von Artefakten und Pipelines verlagert hat.
Der vielleicht bekannteste und weitreichendste Angriff, der das Risiko von Abhängigkeiten verdeutlicht, war der Log4Shell-Vorfall im Jahr 2021. Diese Schwachstelle offenbarte die katastrophale Anfälligkeit, die mit der Abhängigkeit moderner Software von verschachtelten Open-Source-Komponenten einhergeht.
Die Log4Shell-Sicherheitslücke (CVE-2021-44228) war ein extremes Beispiel für einen Vulnerable Dependency-Angriff. Im Mittelpunkt stand die allgegenwärtige Java-Logging-Bibliothek Log4j, die weltweit von Millionen von Anwendungen genutzt wird. Die Sicherheitslücke entstand durch eine obskure Funktion innerhalb des Loggers, die es ihm ermöglichte, Suchvorgänge über das JNDI-Protokoll (Java Naming and Directory Interface) durchzuführen. Ein Angreifer konnte dies ausnutzen, indem er einfach eine speziell gestaltete Zeichenfolge (die einen Verweis auf einen bösartigen externen Server enthielt) in eine beliebige Protokolleingabe einfügte – beispielsweise in ein Suchfeld, einen User-Agent-Header oder ein Benutzernamenfeld. Wenn Log4j diese Zeichenfolge protokollierte, interpretierte es die Suche, kontaktierte den Server des Angreifers und führte Remote-Code (RCE) auf dem System des Opfers aus – alles ohne Authentifizierung.
Die Auswirkungen von Log4Shell waren unmittelbar und führten zu einem systemischen Chaos in der gesamten digitalen Landschaft. Da Log4j so tief eingebettet war, oft viele Ebenen tief als transitive Abhängigkeit, waren sich die meisten Unternehmen nicht bewusst, dass sie es verwendeten. Dies führte zu einer beispiellosen globalen Anstrengung, anfällige Systeme zu entdecken, zu triagieren und zu patchen, was sich auf große Cloud-Anbieter, Unternehmensanwendungen und unzählige proprietäre Software-Stacks auswirkte. Der Angriff zeigte, dass die Kontrolle über die Software-Lieferkette bedeutungslos ist, wenn eine einzige grundlegende Komponente kompromittiert wird, und unterstrich die entscheidende Notwendigkeit einer Software Composition Analysis (SCA) und der Pflege einer vollständigen Software Bill of Materials (SBOM), um Transparenz über das Abhängigkeitsdiagramm zu gewinnen.
Der Shai-Hulud-Angriff, siehe Details in der Beschreibung unserer Beratungsabteilung (EACG), war ein ausgeklügelter Supply-Chain-Angriffswurm, der Anfang bis Mitte September 2025 auf das npm-Ökosystem (Node.js-Pakete) abzielte. Er entwickelte das Playbook zur Kompromittierung von Abhängigkeiten weiter, indem er ein sich selbst verbreitendes Element integrierte, wodurch er weitaus gefährlicher war als typische Angriffe zum Diebstahl von Anmeldedaten.
Der Ansatz des Shai-Hulud-Angriffs war zweigeteilt. Zunächst wurden bösartige npm-Pakete genutzt, um Anmeldedaten und Tokens von Entwicklern zu stehlen und diese in öffentliche Repositorys zu exportieren. Die entscheidende Eskalation war jedoch die Einführung eines Wurm-Elements. Nachdem das System mit den ursprünglichen Tokens kompromittiert worden war, nutzte der Wurm diese Anmeldedaten, um sich auf andere private Repositorys auszubreiten, auf die das kompromittierte Konto Zugriff hatte. Er injizierte sich selbst in neue Projekte, indem er bundle.js als postinstallSkript innerhalb der Datei package.json hinzufügte. Dadurch wurde sichergestellt, dass die böswilligen Aktionen ausgeführt wurden und der Wurm mit dedizierten Workflows in seinen eigenen Zweigen Persistenz erlangte.
Die Auswirkungen des Shai-Hulud-Wurms gingen über den einfachen Diebstahl von Anmeldedaten hinaus. Sobald er sich in einem neuen Repository etabliert hatte, versuchte er, private Repositorys in öffentliche Versionen zu konvertieren oder zu klonen. Entscheidend war, dass er sich in alle Pakete einschleuste, auf die er Zugriff hatte, und diese infizierten Pakete dann wieder in der öffentlichen Registrierung veröffentlichte. Dies führte zu einer raschen, exponentiellen Ausbreitung über die gesamte Lieferkette hinweg und machte die Opfer zu unwissenden Vektoren für weitere Angriffe. Der Vorfall war eine deutliche Warnung vor den Risiken, die mit der standardmäßigen Vertrauenswürdigkeit von Paketmanagern verbunden sind, und vor der dringenden Notwendigkeit von Integritätsprüfungen und Paket-Proxy-Servern, um Abhängigkeiten vor ihrer Ausführung in der Build-Umgebung zu überprüfen.
Möchten Sie mehr zu Supply Chain Security und wie Sie sich dagegen schützen können, erfahren?
Wie die TrustSource Plattform Sie vor diversen Angriffsformen schützen kann
Die Grundlage jeder Art von Schutz ist die Transparenz der Angriffsfläche. Aus diesem Grund verlangen EO 14028 und EU CRA von jedem Softwareanbieter die Bereitstellung von SBOMs.
TrustSource hat eine Open-Source-Scanlösung entwickelt, die alle Arten von Bewertungen und Analysen unterstützt, um eine fundierte und umfassende Software-Stückliste (SBOM) bereitzustellen. ts-scan erstellt tatsächlich das Software-Artefakt für die Zusammensetzungsbewertung und liest nicht nur die Baulisten. Auf diese Weise kann alles katalogisiert werden, was zur Erstellung des beobachteten Build-Artefakts verwendet wird, einschließlich aller transitiven Abhängigkeiten. Weitere Informationen finden Sie hier.
ts-scan ist als zentrale Anlaufstelle für alle Arten von Bewertungen konzipiert: Docker-Container, Suche nach Binärdateien von Drittanbietern für bekannte Malware, Bewertung von Dateistrukturen oder Konvertierung von SBOMs von einem SBOM-Standard in einen anderen, Unterstützung von CycloneDX 1.4, 1.6 und SPDX 2.2 und 2.3 (sowie unserem Format). Alles in einem Tool, das einfach zu verwalten und zu warten ist.
Wie TrustSource Sie unterstützt:
Mit TrustSource können Sie eine „Versionssprung”-Erkennung aktivieren.
Heutzutage beginnen moderne CI/CD-Pipelines bei jedem Check-in von neuem Code mit dem Build. Zu diesem Zeitpunkt erscheint eine neue Konfiguration, wenn Abhängigkeiten vom Paketmanager abgerufen werden. ts-scan oder ein beliebiger Scanner eines Drittanbieters erstellt eine SBOM des neuen Artefakts. TrustSource bewertet dann die in diesem Build verwendeten Versionen anhand der Versionen des letzten Builds.
Um erfolgreich zu sein, verwenden Abhängigkeitsangriffe in der Regel höhere Versionsnummern, insbesondere wenn das Ziel unbekannt ist. Ein Standard-Upgrade wäre also von v1.2 auf v2.0.x oder von v6.3 auf 7.1. Wenn TrustSource nach v5.3.4 eine v8.0 oder v20.1 identifiziert – oder eine andere ungewöhnliche Versionserhöhung –, wird der Projektmanager des Artefakts benachrichtigt.
Was ist ein Dependency-Confusion-Angriff?
Ein Dependency-Confusion-Angriff ist eine Kompromittierung der Lieferkette, bei der ausgenutzt wird, wie moderne Paketmanager (wie npm, PyPI oder NuGet) Software-Abhängigkeiten auflösen, wenn ein Paketname mehrdeutig ist oder sowohl in einem privaten, internen Repository als auch in einem öffentlichen Repository vorhanden ist.
Der Angriff funktioniert, indem ein Angreifer einen Paketnamen identifiziert, den ein Zielunternehmen intern verwendet (z. B. @acme/utils), aber nie öffentlich veröffentlicht hat. Der Angreifer lädt dann ein bösartiges Paket mit genau demselben Namen in das öffentliche Repository (z. B. npmjs.com) hoch, jedoch mit einer viel höheren Versionsnummer.
Während eines routinemäßigen Builds oder einer Installation überprüft der Paketmanager sowohl das interne als auch das öffentliche Repository. Aufgrund einer Standardpräferenz für die höchste verfügbare Version oder schlecht konfigurierter Build-Tools zieht das System das bösartige Paket mit der höheren Version aus dem öffentlichen Repository anstelle des legitimen internen Pakets. Diese Verwirrung ermöglicht es, dass der Code des Angreifers innerhalb der sicheren Build-Umgebung des Opfers ausgeführt wird, was häufig zu Netzwerkaufklärung, Diebstahl von Anmeldedaten oder der Einrichtung einer dauerhaften Hintertür führt.
Was sind OpenSSF-Scorecards?
OpenSSF-Scorecards sind eine Reihe automatisierter Sicherheitsmetriken für Open-Source-Projekte. Sie wurden von der Open Source Security Foundation (OpenSSF) entwickelt und dienen in erster Linie dazu, die Sicherheitslage einer Open-Source-Abhängigkeit auf der Grundlage beobachtbarer Sicherheitspraktiken und -konfigurationen schnell und objektiv zu bewerten. Jede Scorecard vergibt eine Pass/Fail-Note oder eine numerische Punktzahl für verschiedene automatisierte Prüfungen, z. B. ob das Projekt signierte Commits erzwingt, statische Analysen (SAST) verwendet, Branch-Schutz aktiviert hat oder regelmäßig Fuzzing durchführt.
Im Zusammenhang mit der Sicherheit der Software-Lieferkette sind Scorecards von unschätzbarem Wert, da sie den Nutzern von Open-Source-Software helfen, fundierte Vertrauensentscheidungen zu treffen. Da über 90 % der modernen Codebasen auf OSS basieren, müssen Sicherheitsteams die Qualität ihrer Upstream-Abhängigkeiten bewerten. Anstatt Tausende von Projekten manuell zu überprüfen, bieten Scorecards eine standardisierte, skalierbare Methode zur Bewertung der „Hygiene” eines Pakets. Auf diese Weise können automatisierte Governance-Systeme Abhängigkeiten mit niedriger Bewertung zur manuellen Überprüfung markieren oder sie gemäß dem Zero-Trust-Prinzip automatisch von der Aufnahme in Hochsicherheitsanwendungen ausschließen und so das Risiko mindern, dass anfällige oder schlecht gewartete Komponenten in die Lieferkette des Unternehmens gelangen.
OpenSSF Scorecard
TrustSource nutzt Scorecards intensiv:
- Wir ziehen Scorecards für jede Open-Source-Komponente heran. Wenn diese noch nicht bewertet sind, können Sie einen Test auslösen, den TrustSource für Sie durchführt.
- Wenn Sie den Scorecard-Test für Ihr eigenes Repository durchführen möchten, können Sie TrustSource Zugriff gewähren, um den Test auf Ihrem Repo durchzuführen. Lesen Sie hier, wie Sie dies einrichten können.
- Wir sammeln alle Scorecard-Informationen, sodass wir die Entwicklung der Bewertungen im Laufe der Zeit darstellen können.
- Sie können Ihre SBOM nach schwachen Scorecards filtern, um weitere Bewertungen vorzunehmen.
Häufig werden mehrere hundert Komponenten kombiniert, um ein Artefakt herzustellen. Es ist ein enormer Aufwand, alle Komponenten hinsichtlich ihrer Lieferkettensicherheit zu bewerten und zu überwachen. Aus diesem Grund übernimmt TrustSource diese Aufgabe. Wir bewerten alle Komponenten Ihrer SBOM und führen bei Bedarf die Scorecard-Prüfungen für Sie durch.
Die Ergebnisse können Sie im Scorecard-Bericht einsehen. Der Bericht enthält eine Zusammenfassung aller Bewertungen in Ihrer SBOM und vergleicht diese mit der durchschnittlichen Verteilung aller Projekte auf der Plattform. So erhalten Sie einen Überblick darüber, wo Sie in Bezug auf die allgemeine Sicherheit der Lieferkette stehen und wie anfällig Ihre Codebasis für Angriffe auf die Lieferkette sein könnte.
Was ist eine Distribution-Attack?
Bei diesem Ansatz tauscht der Angreifer eine Original-Binärdatei gegen seine böswillig manipulierte Binärdatei aus. In der Regel handelt es sich dabei nicht um das eigentliche Lieferobjekt, sondern um ein zugrunde liegendes unterstützendes Element, z. B. ein Container-Image oder eine unterstützende Infrastruktur oder gängige Open-Source-Komponenten.
Wie TrustSource Sie schützt
TrustSource ermöglicht es Ihnen, bestimmte Binärdateien, die durch Hashes identifiziert werden, mit Ihren SBOMs zu verknüpfen. Bei jeder Veröffentlichung wird automatisch ein Schlüssel generiert, den Sie in Ihre App oder Lösung integrieren können. Mit diesem Schlüssel ist es möglich, eine TrustSource-API aufzurufen und die Prüfsummen, SBOMs und Notice Files zusammen mit den Binärdateien zu überprüfen.
So hat Ihr Kunde immer die Möglichkeit zu sehen, ob er die Originaldateien oder manipulierte Dateien verwendet.