Angriffe auf die Software-Lieferkette werden immer häufiger und verheerender. Zum Beispiel: Gartner prognostiziert, dass 45 % aller Unternehmen bis 2025 einen Verstoß erleben werden. Darüber hinaus Cybersecurity Ventures unterstreicht die Schwere dieser Bedrohung und prognostiziert bis 138 einen jährlichen Schaden von 2031 Milliarden US-Dollar. Insgesamt unterstreichen diese Prognosen die dringende Notwendigkeit für Unternehmen, Prioritäten zu setzen software supply chain security und implementieren Sie robuste Maßnahmen zum Schutz sensibler Daten, Vorgänge und Reputationen.
Denn moderne pipelines hängen stark von externen Komponenten ab, der Aufstieg von Bibliotheken von Drittanbietern, schnellere Softwareentwicklungszyklen, komplexe Lieferketten, mangelnde Transparenz, neue Angriffstechniken, die Einführung von SaaS und begrenzte Ressourcen treiben den Anstieg der Angriffe auf die Software-LieferketteDaher müssen Unternehmen einen umfassenden und aktiven Ansatz verfolgen, um diese Herausforderungen zu bewältigen und ihre Software-Lieferketten zu schützen.
Was ist ein Software-Supply-Chain-Angriff?
ENISA definiert eine Angriff auf die Software-Lieferkette as „Eine Beeinträchtigung eines bestimmten Vermögenswerts, z. B. der Infrastruktur und kommerzieller Software eines Softwareanbieters, um einem oder mehreren bestimmten Zielen, z. B. den Kunden des Softwareanbieters, indirekt Schaden zuzufügen.“ Mit anderen Worten: Ein Software Supply Chain Attack ist eine böswillige Aktivität, die auf die Software-Lieferkette abzielt und darauf abzielt, Schwachstellen oder Schadsoftware in den Entwicklungs- und Verteilungsprozess einzuschleusen. Diese Art von Angriff nutzt das vernetzte und oft komplexe Netzwerk von Prozessen, Tools und Einheiten aus, die an der Entwicklung und Bereitstellung von Software beteiligt sind.
Schlüsselkomponenten und Konzepte im Zusammenhang mit einem Software Supply Chain-Angriff
Cyber-Bedrohungsinformationen und Infosec-Literatur brechen oft zusammen Angriffe auf die Software-Lieferkette in verschiedene Kategorien für eine bessere Analyse und Verteidigung. Dementsprechend stellt dieser Abschnitt die fünf Schlüsselkonzepte vor, die von der MITRE-Angriffsmusterkatalog. Dieser Katalog strukturiert Angriffsmuster in der Lieferkette, um die Analyse mithilfe verschiedener Quellen zu erleichtern, darunter auch vom NIST erfasste gegnerische Bedrohungen.
Angriffshandlung: Das Was
Der Angriffsakt ist die konkrete Aktion, die eine schädliche Nutzlast oder Absicht auf ein System überträgt. Dadurch entsteht direkter Schaden.
- Beispiel 1: Während des Build-Prozesses wurde Malware in die Systemsoftware eingefügt.
- Beispiel 2: Systemanforderungen oder Designdokumente wurden böswillig verändert.
Angriffsvektor: Das Wie
Der Angriffsvektor ist die Methode, mit der Angreifer Schwachstellen oder Prozessschwächen ausnutzen. Er zeigt also, wie Angreifer auf die Angriffsfläche zugreifen und diese missbrauchen.
- Beispiel 1: Ein Angreifer ändert den Quellcode in einem kompromittierten Repository.
- Beispiel 2: Ein Angreifer verschafft sich unberechtigten Zugriff auf interne technische Dokumentation.
Entdecken Sie mehr in unserem Glossar zu Angriffsvektoren für zusätzliche Einblicke.
Angriffsursprung: The Who
Der Ursprung identifiziert die Quelle des Angriffs. Daher verdeutlicht er die Rolle, den Status oder die Beziehung des Angreifers zum System.
- Beispiel 1: Ein Insider mit privilegiertem Zugriff auf Build-Server ändert ein Skript.
- Beispiel 2: Ein externer Bedrohungsakteur lädt ein mit einem Trojaner infiziertes Paket in ein öffentliches Register hoch.
Angriffsziel: Das Warum
Das Ziel erklärt den Grund für den Angriff. Vor allem aber verdeutlicht es, was die Gegner erreichen wollen.
- Unterbrechung: Anhalten von Diensten oder Builds.
- Korruption: Vertrauensverlust durch Änderung von Artefakten oder Quellcode.
- Offenlegung: Weitergabe vertraulicher Geheimnisse oder geistigen Eigentums.
Auswirkungen eines Angriffs: Die Folgen
Schließlich beschreibt der Abschnitt „Auswirkungen“ die Folgen eines Angriffs und zeigt die Konsequenzen für Softwareanbieter und Kunden.
- Beispiel 1: Jedes Projekt, das ein fehlerhaftes Programm verwendet, wird später beschädigt.
- Beispiel 2: Menschen installieren schädliche Software auf ihren Arbeitssystemen, ohne es zu wissen.
Die häufigsten Angriffe auf die Software-Lieferkette
Zahlreiche Arten von Angriffe auf die Software-Lieferkette existieren, und Organisationen müssen sich der verschiedenen Bedrohungsvektoren in jeder Phase des Lebenszyklus bewusst sein. Basierend auf das SLSA-Framework, das US-amerikanische National Institute of Standards und Technologie (NIST) und die Agentur für Cybersicherheit und Infrastruktursicherheit (CISA)Diese Bedrohungen können in vier Kategorien eingeteilt werden: Quell-, Build-, Paket- und Abhängigkeitsrisiken.
Angriffe auf die Software-Lieferkette in der Quellphase
- Senden Sie fehlerhaften Code → sehen Sie, wie Flask request.get Missbrauch or unsichere Deserialisierungsfehler direkte Angriffsflächen schaffen.
- Kompromittiertes Quellrepo
- Aus einer geänderten Quelle erstellen
- Schreiben Sie unsicheren Code
- Manipulation kritischer Dateien → wie erklärt in chmod 777 Backdoor-Analyse.
Angriffe auf die Software-Lieferkette in der Build-Phase
Im Stufe bauenkompilieren und integrieren Entwickler Code in eine funktionierende Version. Parce que Diese Phase ist so kritisch, dass das Risiko besteht, Sicherheitskontrollen in der CI/CD pipeline, Ändern des Codes nach der Versionskontrolle oder Gefährden des Build-Prozesses. Folglichkann sich bösartiger Code unbemerkt in Artefakte einschleichen.
- Umgehen CI/CD → verlinkt mit GitHub-Prebuild-Malware.
- Ändern des Codes nach der Quellcodeverwaltung
- Kompromittierter Build-Prozess → gemildert mit DevSecOps-Frühwarnerkennung.
- Kompromittierungsartefakt-Repository
Angriffe auf die Software-Lieferkette in der Paketphase
Das Paketphase ist die Zusammenstellung des gesamten Codes zu einem Endprodukt. Dieser Schritt ist riskant, da jemand möglicherweise fehlerhafte Pakete verwendet oder die Online-Quellen, von denen wir sie beziehen, ändert. Angreifer können sogar schädliche Versionen beliebter Pakete auf diese Websites hochladen.
- Kompromittiertes Paket verwenden → abgedeckt in Malware-Scanner-Auswertungen.
- Kompromittierung der Paketregistrierung
- Modifiziertes Paket hochladen → analysiert in Namso-gen Fake-Generator-Malware.
Angriffe auf die Software-Lieferkette in der Abhängigkeitsphase
Im Abhängigkeitsphase, fügen wir unserer Software Bibliotheken und Pakete von Drittanbietern hinzu. Diese Phase ist riskant, da sich Probleme in diesen Teilen leicht und unbemerkt auf das restliche Projekt ausbreiten können.
- Verwenden Sie kompromittierte Abhängigkeit → erklärt mit DoS-Risiken bei verschleierten Abhängigkeiten.
- Veraltete oder anfällige Abhängigkeiten
- Transitive Abhängigkeitsrisiken
- Schädliche Paketregistrierungen → gemildert mit DevOps-Sicherheitstools , Risikomanagement durch Dritte.
Häufige Risiken in der Lieferkette in jeder Phase der SDLC
| Praktikum | Typische Bedrohungen | Beispiel |
|---|---|---|
| Quelle |
• Einreichen von schädlichem oder unsicherem Code • Manipulation kritischer Dateien • Gefährdung des Quellrepositorys |
XcodeGhost (2015): Schadcode, der in den Xcode-Compiler von Apple eingeschleust wird und sich über iOS-Apps verbreitet. |
| Bauen |
• Umgehen CI/CD Sicherheitskontrollen • Ändern von Code nach der Quellcodeverwaltung • Kompromittierung von Artefakt-Repositories |
SolarWinds Orion (2020): Angreifer infiltrierten den Build pipeline, indem eine Hintertür in signierte Softwareupdates eingefügt wird. |
| Verpackung |
• Hochladen geänderter Pakete • Vergiftungspaketregister • Verteilung kompromittierter Artefakte |
EventStream NPM (2018): Angreifer hat eine Hintertür in ein beliebtes NPM-Paket eingefügt, das tausende Male heruntergeladen wurde. |
| Abhängigkeit |
• Verwendung veralteter oder anfälliger Abhängigkeiten • Ausnutzen transitiver Abhängigkeiten • Veröffentlichung bösartiger Lookalike-Pakete |
XZ Utils Hintertür (2024): eine mit einem Trojaner infizierte Komprimierungsbibliothek, die beinahe in Linux-Distributionen integriert worden wäre. |
Gängige Angriffstechniken für die Software-Lieferkette
Nach Angaben der US-Organisation CISLaut einem Bericht des NIST fallen Angriffe auf die Software-Lieferkette häufig in drei Hauptkategorien.
Jüngste Vorfälle zeigen jedoch zusätzliche Vektoren auf, die Entwickler verstehen müssen.
Im Folgenden erläutern wir die wichtigsten Techniken anhand praktischer Beispiele.
Hijacking-Updates
Angreifer kompromittieren legitime Update-Mechanismen, um Malware zu verbreiten.
So missbrauchte beispielsweise der NotPetya-Angriff im Jahr 2017 den ukrainischen MEDoc-Server für Steuersoftware-Updates und lieferte
zerstörerische Wiper-Malware, die als Patch getarnt ist. Um sich gegen dieses Risiko zu schützen, sollten Teams Bedrohungserkennung und -reaktion für DevOps Praktiken, die anomales Verhalten in Update-Flows kennzeichnen.
Untergrabung der Code-Signierung
Bei dieser Technik werden gültige Signaturzertifikate missbraucht oder gestohlen, um Schadcode legitim erscheinen zu lassen.
Ein bemerkenswerter Fall war der CCleaner-Angriff im Jahr 2017, bei dem Angreifer trojanisierte Software verbreiteten, die mit gültigen Zertifikaten signiert war.
Folglich benötigen Organisationen einheitliche Integritätskontrollen, wie sie in Strategien für Cybersicherheitsplattformen
Kompromittierung von Open-Source-Code
Angreifer fügen Hintertüren in beliebte Open-Source-Pakete ein, die später in Tausende von Projekten integriert werden.
Der EventStream-NPM-Vorfall und die XZ Utils-Hintertür (2024) veranschaulichen, wie kritisch dieser Vektor geworden ist.
Entwickler sollten Ressourcen wie Häufig gestellte Fragen zur NPM-Sicherheit , Typosquatted-Paketvorfälle um zu lernen, wie man vergiftete Abhängigkeiten vermeidet.
Abhängigkeitsverwirrung
Dieser Angriff wurde erstmals 2021 von Alex Birsan beschrieben und nutzt Namenskonflikte zwischen internen und öffentlichen Paketregistern aus, um Build-Systeme dazu zu bringen, bösartige Versionen anstelle vertrauenswürdiger interner Pakete abzurufen.
Typosquatting und bösartige Pakete
Angreifer veröffentlichen schädliche Pakete mit Namen, die denen beliebter Bibliotheken ähneln (z. B. „reqeusts“ statt „requests“).
Entwickler installieren diese versehentlich und schleusen so Schadsoftware in ihre Projekte ein.
Ein reales Beispiel wird analysiert in Namso-Gen-Malware und in unserer Liste der Open-Source-Malware-Scanner.
Bauen Pipeline Manipulation
Wie beim Angriff auf SolarWinds Orion zu sehen ist, können Angreifer Build-Server infiltrieren, um während der Kompilierung schädlichen Code einzuschleusen.
Dies macht die gesamte signierte Artefaktkette unzuverlässig. Zu den Präventionstechniken gehört die Überwachung CI/CD Integrität mit Frühwarnerkennung und analysieren
GitHub erstellt Malware-Kampagnen vor.
So sieht ein Angriff auf die Software-Lieferkette aus: Der Fall SolarWinds
Der Angriff auf SolarWinds Orion ist das bekannteste Beispiel für einen Verstoß gegen die Software-Lieferkette. Er zeigt, wie Angreifer im Build-Prozess Schritt für Schritt vorgehen und so schädlichen Code an Tausende von Benutzern verbreiten können.
Zunächst drangen Angreifer in die Build-Server von SolarWinds ein.
Danach fügten sie den Orion-Updates heimlich Schadcode hinzu.
Da diese Updates als vertrauenswürdige Software signiert und ausgeliefert wurden, installierten viele Unternehmen sie, ohne sich des Risikos bewusst zu sein.
Insgesamt waren mehr als 18,000 Organisationen betroffen und die Angreifer verschafften sich Zugriff auf sehr sensible Systeme.
Aus der Sicht eines Entwicklers können wir aus diesem Angriff drei einfache Lehren ziehen:
- Perimeterschutz reicht nicht aus: Die Angreifer haben den Build geändert pipeline sich.
- Kontinuierliche Kontrollen sind entscheidend: sicher build attestations, Integritätsprüfungen und Anomalieerkennung helfen, Manipulationen zu verhindern.
- Ein vergifteter Build kann sich global verbreiten: eine einzelne pipeline Ein Kompromiss kann eine weltweite Sicherheitskrise auslösen.
Xygeni: Die ultimative All-in-One-AppSec-Plattform
Da Angriffe auf die Software-Lieferkette jeden Schritt der SDLC,
die All-in-One-AppSec-Plattform, Xygeni, schützt Quellcode, Build, Paket und Abhängigkeitsphasen. Es bietet Entwicklern und Sicherheitsteams einen zentralen Ort, um Risiken einfach zu verhindern, zu erkennen und zu beheben. Dadurch müssen Sie nicht mehr mit mehreren Tools jonglieren, denn Xygeni deckt den gesamten Lebenszyklus ab.
Quellstufenschutz
Auf der Ursprungsstufe bestehen Risiken wie unsichere commits, vergiftete Repositories oder veränderte Dateien. Xygeni scannt Code in Echtzeit mit tiefen SAST und Geheimniserkennung.
Es blockiert auch schädliche commits durch CI/CD guardrails.
Auf diese Weise werden Probleme gestoppt, bevor sie das Repository verlassen.
Schutz der Build-Phase
Während der Build-Phase können Angreifer versuchen, pipelines oder Artefakte verändern.
Xygeni sichert den Build-Prozess mit SLSA-konformen Prüfungen, Integritätsvalidierung und schlüssellosen Signaturen. Es überwacht auch ungewöhnliches Verhalten innerhalb CI/CD Jobs. Infolgedessen werden manipulierte Builds sofort gekennzeichnet und vor der Veröffentlichung blockiert.
Paket Bühnenschutz
In der Paketphase wird durch kompromittierte Register oder geänderte Bibliotheken häufig Malware eingeschleust. Xygenis Malware-Erkennung und Lizenz-Scan jedes Artefakt überprüfen, während AutoFix schlägt sichere Upgrade-Pfade vor mit seiner Remediation Risk Analyse. Nur geprüfte und konforme Pakete kommen weiter in der pipeline.
Schutz der Abhängigkeitsphase
Code von Drittanbietern ist die größte Angriffsfläche. Xygenis Software Composition Analysis (SCA) Es listet nicht nur CVEs auf, sondern prüft auch, ob riskanter Code tatsächlich ausgenutzt werden kann. Es kennzeichnet auch versteckte Malware und riskante transitive Abhängigkeiten. Dies stellt vor allem sicher, dass Entwickler nur sichere Abhängigkeiten ausliefern.
Geheimnisse und Infrastruktursicherheit
Über Code und Pakete hinaus nutzen Angriffe häufig durchgesickerte Geheimnisse oder eine schwache Infrastruktur aus. Xygeni sucht nach offengelegten Schlüsseln, Token und Anmeldeinformationen in Code, Konfigurationen und Docker-Ebenen. Es kann auch durchgesickerte Geheimnisse validieren und automatisch widerrufen mit AutoFix-Korrektur. Gleichzeitig, IaC Scannen verhindert Fehlkonfigurationen, die Angreifer später missbrauchen könnten.
Intelligentere Erkennung und Behebung
Die meisten Tools hören bei Warnungen auf. Xygeni geht noch weiter. Seine AutoFix-Engine erstellt sichere Patches, pull requests, oder eine Schritt-für-Schritt-Anleitung, je nach Problem. Die Ansicht „Behebungsrisiko“ zeigt auch, welche Patch-Version am sichersten ist, sodass Teams Probleme beheben können, ohne neue hinzuzufügen.
Eine einheitliche Plattform
Weil Xygeni kombiniert SAST, SCA, Malware-Erkennung, Geheimnisverwaltung, IaC Scannen, Anomalieerkennung und sichere Build-Kontrollen in einer AppSec-Plattform,
Es bietet eine vollständige Abdeckung über die SDLCSowohl Entwickler als auch Sicherheitsteams erhalten eine einzige zuverlässige Quelle mit klarer Transparenz, praktischen Lösungen und starkem Schutz vor Angriffen auf die Lieferkette.
Alles in Betracht gezogen, Xygeni, die ultimative All-in-One-AppSec-Plattform, hilft Teams, schnell und sicher zu entwickeln. Durch den Schutz der Quellcode-, Build-, Paket- und Abhängigkeitsphasen und durch die automatische Behebung von Problemen in jedem Schritt wird sichergestellt, dass Angriffe auf die Software-Lieferkette gestoppt werden, bevor sie die Produktion erreichen.
