Zum Inhalt

A03:2025 Schwachstellen in der Software-Lieferkette icon

Hintergrund.

Diese Kategorie belegte den ersten Platz in der Community-Umfrage zu den Top 10, wobei genau 50 % der Teilnehmer:innen sie auf Rang 1 setzten. Seit ihrem ersten Erscheinen im Top 10 von 2013 als „A9 – Using Components with Known Vulnerabilities" hat sich der Risikobereich ausgeweitet und umfasst nun alle Lieferkettenfehler, nicht nur solche mit bekannten Schwachstellen. Trotz dieses erweiterten Umfangs sind Lieferkettenfehler mit nur 11 Common Vulnerability and Exposures (CVEs), die die zugehörigen CWEs aufweisen, nach wie vor schwer zu identifizieren. Werden sie jedoch getestet und in den beigetragenen Daten gemeldet, weist diese Kategorie mit 5,19 % die höchste durchschnittliche Vorfallsrate aller Kategorien auf. Die relevanten CWEs sind CWE-477: Use of Obsolete Function, CWE-1104: Use of Unmaintained Third Party Components, CWE-1329: Reliance on Component That is Not Updateable, und CWE-1395: Dependency on Vulnerable Third-Party Component.

Punktetabelle.

Zugeordnete CWEs Max. Häufigkeit Durchschn. Häufigkeit Max. Abdeckung Durchschn. Abdeckung Durchschn. gewichtete Ausnutzbarkeit Durchschn. gewichtete Auswirkung Gesamtanzahl Summe CVEs
6 9.56% 5.72% 65.42% 27.47% 8.17 5.23 215,248 11

Beschreibung.

Schwachstellen in der Software-Lieferkette sind Störungen oder sonstige Kompromittierungen im Prozess der Erstellung, Verteilung oder Aktualisierung von Software. Sie werden häufig durch Schwachstellen oder böswillige Änderungen in Code, Werkzeugen oder anderen Abhängigkeiten von Drittanbietern verursacht, auf die das System angewiesen sind.

Sie sind wahrscheinlich verwundbar, wenn:

  • Sie die Versionen aller verwendeten Komponenten (sowohl client- als auch serverseitig) nicht sorgfältig nachverfolgen. Dies umfasst sowohl direkt verwendete Komponenten als auch verschachtelte (transitive) Abhängigkeiten.
  • Die Software verwundbar, nicht mehr unterstützt oder veraltet ist. Dies betrifft das Betriebssystem, Web-/Anwendungsserver, Datenbankmanagementsysteme (DBMS), Anwendungen, APIs und alle Komponenten, Laufzeitumgebungen und Bibliotheken.
  • Sie keine regelmäßigen Schwachstellen-Scans durchführen und keine Sicherheitsbulletins zu den von Ihnen verwendeten Komponenten abonniert haben.
  • Sie keinen Änderungsmanagementprozess oder keine Nachverfolgung von Änderungen in Ihrer Lieferkette haben, einschließlich der Nachverfolgung von IDEs, IDE-Erweiterungen und -Updates, Änderungen am Code-Repository Ihrer Organisation, Sandboxen, Image- und Bibliotheks-Repositories sowie der Art und Weise, wie Artefakte erstellt und gespeichert werden usw. Jeder Teil Ihrer Lieferkette sollte dokumentiert werden, insbesondere Änderungen.
  • Sie nicht jeden Teil Ihrer Lieferkette abgesichert haben, mit besonderem Fokus auf Zugangskontrolle und die Anwendung des Prinzips der minimalen Rechtevergabe.
  • Ihre Lieferkettensysteme keine Aufgabentrennung aufweisen. Keine einzelne Person sollte in der Lage sein, Code zu schreiben und ihn bis in die Produktion zu befördern, ohne die Aufsicht eines anderen Menschen.
  • Komponenten aus nicht vertrauenswürdigen Quellen, über jeden Teil des Tech-Stacks hinweg, in Produktionsumgebungen verwendet werden oder diese beeinflussen können.
  • Sie die zugrunde liegende Plattform, Frameworks und Abhängigkeiten nicht risikobasiert und zeitnah aktualisieren oder upgraden. Dies tritt häufig in Umgebungen auf, in denen das Patchen eine monatliche oder vierteljährliche Aufgabe unter Änderungskontrolle ist, wodurch Organisationen tagelangen oder monatelangen unnötigen Risiken ausgesetzt sind, bevor Schwachstellen behoben werden.
  • Softwareentwickler:innen die Kompatibilität aktualisierter, upgegradeter oder gepatchter Bibliotheken nicht testen.
  • Sie die Konfigurationen jedes Teils Ihres Systems nicht absichern (siehe A02:2025-Security Misconfiguration).
  • Ihre CI/CD-Pipeline eine schwächere Sicherheit aufweist als die Systeme, die sie erstellt und bereitstellt, insbesondere wenn sie komplex ist.

Prävention und Gegenmaßnahmen.

Es sollte ein Patch-Management-Prozess vorhanden sein, der:

  • Zentral das Software Bill of Materials (SBOM) Ihrer gesamten Software erstellt und verwaltet.
  • Nicht nur Ihre direkten Abhängigkeiten, sondern auch deren (transitive) Abhängigkeiten usw. nachverfolgt.
  • Die Angriffsfläche durch Entfernen ungenutzter Abhängigkeiten, unnötiger Funktionen, Komponenten, Dateien und Dokumentation reduziert.
  • Die Versionen sowohl client- als auch serverseitiger Komponenten (z. B. Frameworks, Bibliotheken) und deren Abhängigkeiten kontinuierlich mit Tools wie OWASP Dependency Track, OWASP Dependency Check, retire.js usw. inventarisiert.
  • Quellen wie Common Vulnerability and Exposures (CVE), National Vulnerability Database (NVD) und Open Source Vulnerabilities (OSV) kontinuierlich auf Schwachstellen in den von Ihnen verwendeten Komponenten überwacht. Nutzen Sie Software-Kompositionsanalyse, Software-Supply-Chain- oder sicherheitsorientierte SBOM-Tools, um den Prozess zu automatisieren. Abonnieren Sie Warnungen zu Sicherheitsschwachstellen in den von Ihnen verwendeten Komponenten.
  • Komponenten ausschließlich von offiziellen (vertrauenswürdigen) Quellen über sichere Verbindungen bezieht. Bevorzugen Sie signierte Pakete, um die Wahrscheinlichkeit zu verringern, eine modifizierte, bösartige Komponente einzubinden (siehe A08:2025-Software and Data Integrity Failures).
  • Bewusst wählt, welche Version einer Abhängigkeit verwendet wird, und nur bei Bedarf aktualisiert.
  • Bibliotheken und Komponenten überwacht, die nicht mehr gewartet werden oder keine Sicherheits-Patches für ältere Versionen bereitstellen. Falls kein Patchen möglich ist, sollten Sie eine Migration zu einer Alternative in Betracht ziehen. Falls auch das nicht möglich ist, ziehen Sie den Einsatz eines virtuellen Patches in Betracht, um das entdeckte Problem zu überwachen, zu erkennen oder dagegen zu schützen.
  • Ihre CI/CD-, IDE- und anderen Entwicklungs-Tools regelmäßig aktualisiert.
  • Vermeidet, Updates gleichzeitig auf alle Systeme auszurollen. Nutzen Sie gestaffelte Rollouts oder Canary-Deployments, um das Risiko zu begrenzen, falls ein:e vertrauenswürdige:r Anbieter:in kompromittiert wird.

Es sollte ein Änderungsmanagementprozess oder ein Tracking-System vorhanden sein, um Änderungen an folgenden Bereichen zu verfolgen:

  • CI/CD-Einstellungen (alle Build-Tools und Pipelines)
  • Code-Repositories
  • Sandbox-Bereiche
  • Entwicklungsumgebungen
  • SBOM-Tooling und erstellte Artefakte
  • Protokollierungssysteme und Protokolle
  • Drittanbieter-Integrationen, z. B. SaaS
  • Artefakt-Repositories
  • Container-Registries

Folgende Systeme sollten abgesichert werden, einschließlich der Aktivierung von MFA und der Einschränkung von IAM:

  • Ihr Code-Repository (dazu gehört das Nicht-Einchecken von Secrets, der Schutz von Branches und Backups)
  • Entwickler:innen-Workstations (regelmäßiges Patchen, MFA, Monitoring und mehr)
  • Ihr Build-Server & CI/CD (Aufgabentrennung, Zugangskontrolle, signierte Builds, umgebungsspezifische Secrets, manipulationssichere Protokolle und mehr)
  • Ihre Artefakte (Integrität durch Herkunftsnachweis, Signierung und Zeitstempel sicherstellen, Artefakte befördern statt für jede Umgebung neu zu bauen, sicherstellen, dass Builds unveränderlich sind)
  • Infrastructure as Code (wie jeder Code verwaltet, einschließlich der Verwendung von PRs und Versionskontrolle)

Jede Organisation muss einen fortlaufenden Plan zur Überwachung, Priorisierung und Anwendung von Updates oder Konfigurationsänderungen für die gesamte Lebensdauer der Anwendung oder des Portfolios sicherstellen.

Beispielhafte Angriffsszenarien.

Szenario Nr. 1: Ein vertrauenswürdiger Anbieter wird mit Malware kompromittiert, was dazu führt, dass Ihre Computersysteme beim Upgrade kompromittiert werden. Das bekannteste Beispiel hierfür ist wahrscheinlich:

Szenario Nr. 2: Ein vertrauenswürdiger Anbieter wird so kompromittiert, dass er sich nur unter einer bestimmten Bedingung böswillig verhält.

Szenario Nr. 3: Der Shai-Hulud-Supply-Chain-Angriff im Jahr 2025 war der erste erfolgreiche sich selbst verbreitende npm-Wurm. Angreifer:innen platzierten bösartige Versionen populärer Pakete, die ein Post-Install-Skript verwendeten, um sensible Daten zu sammeln und in öffentliche GitHub-Repositories zu exfiltrieren. Die Malware erkannte auch npm-Token in der Opferumgebung und nutzte diese automatisch, um bösartige Versionen aller zugänglichen Pakete zu veröffentlichen. Der Wurm erreichte über 500 Paketversionen, bevor er von npm gestoppt wurde. Dieser Supply-Chain-Angriff war fortschrittlich, schnell ausbreitend und schädlich, und indem er auf Entwicklungsmaschinen abzielte, zeigte er, dass Entwickler:innen selbst nun zu den Hauptzielen von Supply-Chain-Angriffen geworden sind.

Szenario Nr. 4: Komponenten laufen typischerweise mit denselben Berechtigungen wie die Anwendung selbst, sodass Fehler in einer beliebigen Komponente erhebliche Auswirkungen haben können. Solche Fehler können versehentlich (z. B. Codefehler) oder absichtlich (z. B. eine Hintertür in einer Komponente) sein. Einige Beispiele für entdeckte ausnutzbare Komponentenschwachstellen sind:

  • CVE-2017-5638, eine Struts-2-Schwachstelle zur Remote-Code-Ausführung, die die Ausführung beliebigen Codes auf dem Server ermöglicht, wurde für erhebliche Datenschutzverletzungen verantwortlich gemacht.
  • CVE-2021-44228 („Log4Shell"), eine Apache-Log4j-Zero-Day-Schwachstelle zur Remote-Code-Ausführung, wurde für Ransomware-, Kryptomining- und andere Angriffskampagnen verantwortlich gemacht.

Referenzen.

Liste der zugeordneten CWEs