OWASP Top 10 2025: Software Supply Chain Failures

Mit der lang erwarteten Veröffentlichung der 2025 OWASP Top Ten stehen Unternehmen vor einigen neuen Bedrohungen, vor denen sie sich besonders in Acht nehmen müssen – darunter eine, die weit oben auf der Liste steht. Software Supply Chain Failures, eine neue Kategorie, die jedoch nicht völlig neu ist, belegt Platz 3 der alle vier Jahre erscheinenden Liste des Open Web Application Security Project zu den schwerwiegendsten Risiken für die Sicherheit von Webanwendungen. Ein Risiko, das Unternehmen sehr ernst nehmen sollten, falls sie es nicht bereits tun.

Software Supply Chain Failures ging aus einer Kategorie der vorherigen Liste von 2021 hervor, Vulnerable and Outdated Components, und umfasst nun ein breiteres Spektrum an Kompromittierungen im gesamten Software-Ökosystem aus Abhängigkeiten, Build-Systemen und Verteilungsinfrastruktur. Das Erscheinen auf der Liste sollte nicht überraschen, wenn man die Schäden durch prominente Supply-Chain-Angriffe wie SolarWinds im Jahr 2019, den Bybit-Hack Anfang dieses Jahres und die anhaltende Shai-Hulud-Kampagne betrachtet – ein besonders tückischer, selbstreplizierender npm-Wurm, der in Entwicklerumgebungen für Chaos sorgt.

Die OWASP Top Ten sind im Allgemeinen konsistent, was einer Liste entspricht, die alle vier Jahre erscheint, auch wenn es zwischendurch Aktualisierungen gibt. Normalerweise gibt es einige Verschiebungen innerhalb der Liste – Injection, ein langjähriger Bewohner, fällt beispielsweise von Platz 3 auf Platz 5, Insecure Design rutscht zwei Plätze auf Platz 6 ab, während Security Misconfiguration von Platz 5 auf Platz 2 springt. Broken Access Control behauptet weiterhin die Spitzenposition. Die Ausgabe 2025 enthält zwei neue Einträge: die bereits erwähnten Software Supply Chain Failures und Mishandling of Exceptional Conditions, das auf Platz 10 einsteigt. Hier werfen wir einen genaueren Blick auf den neuen Eintrag zu Supply-Chain-Schwachstellen.

[VIDEO ANSEHEN]

Schwachstellen können fast überall auftreten

Software Supply Chain Failures ist eine etwas ungewöhnliche Kategorie auf der Liste, da sie unter den 10 Einträgen die wenigsten Vorkommen in den Forschungsdaten von OWASP aufweist, aber gleichzeitig die höchsten durchschnittlichen Exploit- und Impact-Werte aus den fünf Common Weakness Enumerations (CWEs) der Kategorie erzielt. OWASP vermutet, dass die begrenzte Präsenz der Kategorie auf aktuelle Herausforderungen bei der Prüfung zurückzuführen ist, was sich jedoch verbessern könnte. Unabhängig davon nannten die Umfrageteilnehmer Software Supply Chain Failures überwältigend als ein Hauptanliegen.

Die meisten Supply-Chain-Schwachstellen entstehen durch die vernetzte Art des Geschäftslebens, an der vor- und nachgelagerte Partner sowie Dritte beteiligt sind. Jede Interaktion beinhaltet Software, deren Komponenten (auch Abhängigkeiten oder Bibliotheken genannt) ungeschützt sein könnten. Ein Unternehmen kann anfällig sein, wenn es nicht alle Versionen seiner eigenen Komponenten (Client-Seite, Server-Seite oder verschachtelt) sowie transitive Abhängigkeiten (von anderen Bibliotheken) nachverfolgt, um sicherzustellen, dass diese nicht anfällig, nicht unterstützt oder veraltet sind. Komponenten haben in der Regel dieselben Berechtigungen wie die Anwendung; daher können kompromittierte Komponenten, einschließlich solcher von Drittanbietern oder aus Open-Source-Repositories, weitreichende Auswirkungen haben. Rechtzeitiges Patchen und Aktualisieren sind unerlässlich – selbst regelmäßige monatliche oder vierteljährliche Patch-Zyklen können ein Unternehmen tagelang oder monatelang angreifbar machen.

Ebenso kann das Fehlen eines Change-Management-Prozesses für Ihre Lieferkette zu Schwachstellen führen, wenn Sie Integrated Development Environments (IDEs) oder Änderungen an Ihrem Code-Repository, Image- und Bibliotheks-Repositories oder anderen Teilen der Lieferkette nicht nachverfolgen. Ein Unternehmen muss die Lieferkette durch Zugriffskontrollen und Least-Privilege-Richtlinien härten und sicherstellen, dass niemand ohne Aufsicht Code erstellen und in die Produktion überführen kann und dass niemand Komponenten aus nicht vertrauenswürdigen Quellen herunterlädt.

Supply-Chain-Angriffe können viele Formen annehmen. Der berüchtigte SolarWinds-Angriff begann, als russische Angreifer Malware in ein Update der beliebten Netzwerkmanagement-Software des Unternehmens einschleusten. Er betraf etwa 18.000 Kunden. Obwohl die Zahl der tatsächlich betroffenen Unternehmen eher bei 100 lag, umfasste diese Liste große Konzerne und Regierungsbehörden. Der 1,5-Milliarden-Dollar-Bybit-Hack, der auf Nordkorea zurückgeführt wurde, betraf kompromittierte Kryptowährungs-Apps. Der kürzliche Glass Worm-Supply-Chain-Angriff beinhaltete einen unsichtbaren, selbstreplizierenden Code, der den Open VSX Marketplace infizierte.

Prävention von Supply-Chain-Exploits

Da Supply-Chain-Angriffe die gegenseitige Abhängigkeit von Systemen ausnutzen, erfordert die Verteidigung dagegen einen ganzheitlichen Ansatz. OWASP bietet Tipps zur Prävention von Angriffen, einschließlich Patch-Management-Prozessen für:

• Kennen Sie Ihre Software Bill of Materials (SBOM) für alle Software und verwalten Sie diese zentral. Es ist am besten, SBOMs während des Builds zu generieren, anstatt später, unter Verwendung von Standardformaten wie SPDX oder CycloneDX, und mindestens eine maschinenlesbare SBOM pro Release zu veröffentlichen.
• Verfolgen Sie alle Ihre Abhängigkeiten, einschließlich transitiver Abhängigkeiten, und entfernen Sie ungenutzte Abhängigkeiten sowie unnötige Funktionen, Komponenten, Dateien und Dokumentationen.
• Inventarisieren Sie kontinuierlich sowohl client- als auch serverseitige Komponenten und deren Abhängigkeiten mithilfe von Tools wie OWASP Dependency Check oder retire.js.
• Bleiben Sie bei Schwachstellen auf dem Laufenden und überwachen Sie kontinuierlich Quellen wie die Common Vulnerabilities and Exposures (CVE)-Website und die National Vulnerability Database (NVD) und abonnieren Sie E-Mail-Benachrichtigungen für Sicherheitslücken in den von Ihnen verwendeten Komponenten.
• Verwenden Sie nur Komponenten aus vertrauenswürdigen Quellen über sichere Verbindungen. Ein vertrauenswürdiger Anbieter wäre beispielsweise bereit, mit einem Forscher zusammenzuarbeiten, um eine von diesem entdeckte CVE in einer Komponente offenzulegen.
• Wählen Sie bewusst, welche Version einer Abhängigkeit Sie verwenden, und führen Sie Upgrades nur bei Bedarf durch. Arbeiten Sie mit Bibliotheken von Drittanbietern, deren Schwachstellen in einer bekannten Quelle wie der NVD veröffentlicht wurden.
• Überwachen Sie nicht gewartete oder nicht unterstützte Bibliotheken und Komponenten. Wenn ein Patch nicht möglich ist, ziehen Sie die Bereitstellung eines virtuellen Patches in Betracht, um das entdeckte Problem zu überwachen, zu erkennen oder dagegen zu schützen.
• Aktualisieren Sie regelmäßig die Entwicklertools.
• Behandeln Sie Komponenten in Ihrer CI/CD-Pipeline als Teil dieses Prozesses, härten und überwachen Sie diese und dokumentieren Sie Änderungen.

Change-Management oder ein Nachverfolgungsprozess sollte auch für Ihre CI/CD-Einstellungen, Code-Repositories, Sandboxes, integrierte Entwicklungsumgebungen (IDEs), SBOM-Tools, erstellte Artefakte, Protokollierungssysteme und Protokolle, Integrationen von Drittanbietern wie SaaS, Artefakt-Repositories und Ihre Container-Registry gelten. Sie müssen auch Systeme härten, von Entwickler-Workstations bis zur CI/CD-Pipeline. Stellen Sie sicher, dass Sie die Multi-Faktor-Authentifizierung aktivieren und gleichzeitig strenge Identitäts- und Zugriffsrichtlinien durchsetzen.

Der Schutz vor Software-Supply-Chain-Ausfällen ist angesichts unserer hochgradig vernetzten Welt ein vielschichtiges, fortlaufendes Unterfangen. Unternehmen müssen starke Verteidigungsmaßnahmen für den gesamten Lebenszyklus ihrer Anwendungen und Komponenten einsetzen, um sich gegen diese sich schnell entwickelnde, moderne Bedrohung zu wehren.

Hinweis für Nutzer des SCW Trust Score™ :

Während wir unsere Lernplattform-Inhalte an den OWASP Top 10 2025 Standard anpassen, könnten Sie geringfügige Änderungen am Trust Score Ihrer Full-Stack-Entwickler feststellen. Bitte wenden Sie sich bei Fragen oder Unterstützungsbedarf an Ihren Customer Success Manager.