Ob Open-Source-Libraries, Paketmanager oder Build-Tools – moderne Webentwicklung beruht auf einem komplexen Geflecht externer Software-Komponenten. Doch genau hier lauert eines der gefährlichsten IT-Risiken unserer Zeit: Supply-Chain-Angriffe. OWASP nimmt dieses Thema 2025 erstmals prominent ins Visier – und das aus guten Gründen.
Was ist eine Software Supply Chain?
Die Software Supply Chain (SSC) bezeichnet alle Komponenten, Werkzeuge und Dienste, die am Entwicklungsprozess und dem Betrieb von Software beteiligt sind. Dazu gehören unter anderem:
- Open-Source- und Drittanbieter-Bibliotheken
- Build-Werkzeuge und Continuous Integration (CI)-Systeme
- Paketmanager wie npm, pip oder Maven
- Container und ihre Abhängigkeiten
- Cloud-Services und Plattformen
Jede dieser Komponenten kann Einfallstor für Cyberattacken sein – insbesondere dann, wenn sie nicht regelmäßig überprüft, aktualisiert oder gegen Manipulation abgesichert wird.
Warum die Software Supply Chain in den OWASP Top Ten 2025 auftaucht
Die OWASP Top Ten gelten als der weltweit wichtigste Sicherheitsstandard in der Webentwicklung. Im Vorentwurf der OWASP Top Ten 2025 wird „Insecure Software Supply Chain“ erstmals als separate Bedrohung klassifiziert. Dieser Schritt ist eine unmittelbare Reaktion auf eine Reihe hochkarätiger Vorfälle, bei denen Angreifer über kompromittierte Software-Komponenten Zugriff auf Zielsysteme erhielten.
Besonders bekannt wurde der SolarWinds-Hack (2020), bei dem Tausende Organisationen – darunter US-Regierungsbehörden – durch manipulierte Updates der Orion-Software kompromittiert wurden. Auch Log4Shell, eine kritische Schwachstelle in der beliebten Java-Bibliothek Log4j, zeigte 2021 auf dramatische Weise, wie gefährlich Lücken in verbreiteten Third-Party-Komponenten sein können.
Laut einer Snyk-Studie (2023) enthalten durchschnittlich 77 % der Open-Source-Projekte bekannte Schwachstellen. Noch kritischer: 95 % aller Enterprise-Anwendungen basieren auf Open Source – oft ohne dass Entwickler den vollständigen Komponentenstamm verstehen (Source: Snyk, „The State of Open Source Security“, 2023).
Die Anatomie eines Supply-Chain-Angriffs
Anders als klassische Cyberangriffe zielen Supply-Chain-Attacken auf die Vertrauenskette der Softwarebereitstellung. Angriffsvektoren können sein:
- Manipulation von Package-Repositories (z. B. npm, PyPI)
- Typosquatting bei Bibliotheksnamen (etwa „request“ vs. „requset“)
- Backdoors in legitimen Dependencies durch böswillige Maintainer
- Kompromittierte CI/CD-Umgebungen oder Buildprozesse
Ein prominentes Beispiel: Im März 2022 entdeckte GitHub, dass mehrere populäre npm-Packages wie „ua-parser-js“ mit Bitcoin-Miner-Malware infiziert waren – durch eine Kompromittierung der Maintainer-Konten. Fast 1 Million Projekte waren potenziell betroffen.
Wie lässt sich das Risiko minimieren?
Um die Integrität der Software-Lieferkette zu schützen, sind ganzheitliche Sicherheitsstrategien gefragt. In Gesprächen mit mehreren Branchenexperten kristallisieren sich folgende Best Practices heraus:
- Verwendung einer Software Bill of Materials (SBOM): Diese dokumentiert, aus welchen Komponenten eine Anwendung besteht – samt Versionen, Lizenzen und Herkunft.
- Kontinuierliches Dependency Scanning: Tools wie Snyk, OWASP Dependency-Check oder GitHub Dependabot erkennen bekannte Schwachstellen frühzeitig.
- Vertrauenswürdige Quellen und digitale Signaturen: Signierte Pakete und verifizierte Maintainer-Konten verringern das Risiko versehentlicher Infektionen.
- Vermeidung von veralteten oder unmaintained Libraries: Komponenten ohne regelmäßige Updates sollten proaktiv ersetzt werden.
Eine Statistik von Sonatype (State of the Software Supply Chain 2024) belegt die Wirksamkeit solcher Maßnahmen: Organisationen mit einem automatisierten Vulnerability-Management reduzierten das mittlere Behebungsintervall (MTTR) von Sicherheitslücken von 49 Tagen auf nur 15 Tage.
Die Rolle von DevSecOps und Policy Enforcement
Die Integration von Sicherheitsmechanismen in den Build- und Releasesprozess – DevSecOps – ist ein Schlüsselfaktor zur Absicherung der Software Supply Chain. Sicherheitsrichtlinien sollten bereits in frühen Phasen greifen:
- Pull Requests müssen automatisierte Security-Checks durchlaufen
- CI/CD-Pipelines enthalten Signierungsprozesse und Verifizierungen
- Policy Enforcement blockiert den Einsatz ungeprüfter Pakete
Sebastian Schreiber, CEO von SySS GmbH, betont im Interview: „Sicherheit in der Lieferkette darf kein Abfallprodukt sein, sondern muss systematisch orchestriert werden. Jeder Build, der eine Schwachstelle transportieren kann, ist ein potenzieller Exploit.“
Open Source ist nicht das Problem, sondern Teil der Lösung
Obwohl viele Schwachstellen über Open-Source-Komponenten eingeschleust werden, ist Open Source selbst nicht das Sicherheitsproblem. Im Gegenteil: Durch Transparenz, Community-Wartung und schnelle Updates erlaubt Open Source mehr Kontrollmöglichkeiten als mancher proprietäre Code.
Ein entscheidendes Werkzeug ist hier Sigstore – ein Open-Source-Framework für das sichere Signieren und Verifizieren von Software-Artefakten. Viele Linux-Distributionen und zunehmend auch npm, PyPI und DockerHub adaptieren dieses Sicherheitsmodell.
Der OpenSSF Scorecard-Bericht 2024 zeigt, dass Projekte mit aktiver Security-Maintenance und guten CI-Prozessen 83 % weniger anfällig für Supply-Chain-Risiken sind (Quelle: OpenSSF Scorecard Report 2024).
Praktische Empfehlungen für Entwickler und Teams
Software-Lieferketten zu sichern bedeutet mehr als nur Tools einzusetzen. Es geht auch um Kultur, Verantwortlichkeiten und Governance. Unsere Empfehlungen:
- Pflegen Sie eine vollständige SBOM und aktualisieren Sie sie regelmäßig im Releasemanagement.
- Etablieren Sie ein „Zero-Trust“-Modell für alle externen Abhängigkeiten – jede Komponente muss validiert werden.
- Nutzen Sie Continuous Monitoring für Repositorys, CI/CD-Pipelines und öffentlich zugängliche APIs.
Fazit: Vom Passiv-User zum aktiven Kurator der eigenen Codebasis
Die Software Supply Chain ist für die Webentwicklung ein kritisches Sicherheitsfeld geworden – ihr Schutz gehört heute zur Pflicht jedes Entwicklerteams. Wer sich darauf verlässt, dass Third-Party-Bibliotheken schon sicher sind, riskiert nicht nur Angriffe, sondern auch Reputationsverlust, Datenschutzverstöße und Compliance-Probleme.
Doch das Gute: Mit der richtigen Strategie, einem wachen Team und verlässlichen Tools lässt sich Sicherheit in der Supply Chain nicht nur erreichen, sondern nachhaltig verankern. Wie geht ihr im Team mit SSC-Risiken um? Teilt eure Erfahrungen und Tools mit der Community!
