Der Angriff, den niemand kommen sah

Das Ziel ist nicht Ihr System. Das Ziel ist ein Werkzeug, das Sie täglich benutzen, ohne darüber nachzudenken. Ein Build-Plugin. Eine Open-Source-Bibliothek. Ein npm-Paket mit 50.000 wöchentlichen Downloads. Angreifer infizieren die Quelle – und warten darauf, dass Sie selbst die Schadsoftware in Ihre Produktion einbauen.

Genau das ist das Prinzip des Software Supply Chain Angriffs. Und es funktioniert erschreckend gut: Software-Lieferkettenangriffe haben sich 2025 weltweit mehr als verdoppelt. Über 70 % der Unternehmen meldeten mindestens einen Vorfall im Zusammenhang mit kompromittierten Drittanbieter-Komponenten. Der potenzielle globale Schaden für 2025 wird auf 60 Milliarden USD geschätzt.

Wie diese Angriffe konkret funktionieren

Die häufigsten Einfallstore sind heute nicht mehr geschwächte Firewalls oder ungepatchte Server – sondern die Entwicklungsinfrastruktur selbst:

  • Dependency Confusion: Angreifer veröffentlichen Pakete mit demselben Namen wie interne Bibliotheken in öffentlichen Repositories (npm, PyPI). Build-Systeme laden das öffentliche Paket statt das interne – mit Schadcode darin.
  • Typosquatting: Ein Paket heißt „requesets" statt „requests". Wer tippt, installiert Malware. Auf npm, PyPI und Docker Hub tauchten 2025 Hunderte solcher Pakete auf.
  • Kompromittierte Maintainer: Ein Entwickler mit hohen Publish-Rechten wird Opfer eines Phishing-Angriffs. Die nächste Version einer populären Bibliothek enthält Backdoor-Code – verteilt an alle Nutzer.
  • CI/CD-Pipeline-Angriffe: Build-Server, die GitHub Actions ausführen, werden kompromittiert. Der angreifende Code läuft in der Buildumgebung und schleust sich in das fertige Artefakt ein.

Über 50 % der Lieferkettenangriffe gehen auf APT-Gruppen (Advanced Persistent Threats) zurück – staatlich gesponserte oder hochprofessionelle Akteure, die langfristig planen und gezielt auf Entwicklerinfrastruktur zielen.

Was eine SBOM ist – und was sie nicht ist

Eine Software Bill of Materials (SBOM) ist ein formales, maschinenlesbares Inventar aller Komponenten eines Softwareprodukts: Bibliotheken, Pakete, Frameworks, Versionen, Lizenzen und bekannte Schwachstellen (CVEs). Sie ist das Äquivalent der Zutatenliste auf einem Lebensmittelprodukt – nur für Software.

Was eine SBOM nicht ist: eine Garantie für Sicherheit. Viele Unternehmen generieren SBOMs als letzten Schritt im Build-Prozess, produzieren dabei ungenaue oder veraltete Listen und haken eine Compliance-Checkbox ab. Experten sprechen von „SBOM-Washing" – das Dokument existiert, nützt aber nichts.

Der entscheidende Unterschied liegt in der Handlungsfähigkeit: Eine SBOM nützt nur dann etwas, wenn sie aktuell ist, maschinell verarbeitbar, mit Vulnerability-Datenbanken abgeglichen wird und Prozesse auslöst, wenn neue CVEs für enthaltene Komponenten bekannt werden.

Regulatorischer Druck: CRA und NIS2 machen SBOM zur Pflicht

Die Anforderung kommt nicht nur aus der Security-Community – sie ist regulatorische Realität:

  • EU Cyber Resilience Act (CRA): Ab September 2026 greift die Meldepflicht für aktiv ausgenutzte Schwachstellen. Wer keine SBOM hat, weiß nicht, welche seiner Produkte betroffen sind – und kann die 24-Stunden-Frist nicht einhalten. Ab Dezember 2027 ist das Schwachstellenmanagement inklusive SBOM volle Pflicht für alle Produkte mit digitalen Elementen.
  • NIS2: Lieferkettenkontrollen sind explizit Teil der Risikomanagement-Anforderungen. Unternehmen müssen nachweisen, dass sie die Sicherheit ihrer Software-Zulieferer aktiv prüfen.
  • ENISA: Die europäische Cybersicherheitsbehörde plant ab 2026 regelmäßige technische Advisories zu SBOM-Implementierungsanforderungen.

Laut TÜV Cybersecurity Studie 2025 stellt nur ein Drittel der Unternehmen überhaupt Sicherheitsanforderungen an Zulieferer – und nur 6 % führen regelmäßige Audits durch. Das wird sich ändern müssen.

Shift Left: Sicherheit in die Entwicklung verlagern

Supply-Chain-Sicherheit beginnt nicht bei der Auslieferung, sondern beim ersten Commit. Der Begriff „Shift Left" beschreibt die Verlagerung von Sicherheitskontrollen in früheste Phasen des Entwicklungsprozesses:

  1. Dependency-Scanning im IDE: Bereits beim Hinzufügen einer neuen Bibliothek prüfen Tools wie Snyk oder Dependabot, ob bekannte Schwachstellen existieren.
  2. Verifizierte Paketquellen: Dependency-Pinning auf konkrete Versionen und Hashes statt auf „latest". Private Package-Registries mit kontrollierten, geprüften Paketen.
  3. SBOM-Generierung im CI/CD: Automatische Erstellung bei jedem Build, nicht manuell und nicht nur bei Releases. Standardformate: SPDX oder CycloneDX.
  4. Signierte Artefakte: Build-Outputs werden kryptografisch signiert (Sigstore, cosign). So lässt sich nachweisen, dass ein Docker-Image tatsächlich aus dem eigenen CI-System stammt – und nicht manipuliert wurde.
  5. Kontinuierlicher Abgleich: Die SBOM wird regelmäßig gegen aktuelle CVE-Datenbanken (NVD, OSV) abgeglichen. Neue Schwachstellen in bereits ausgelieferten Produkten lösen automatisch Tickets aus.

Was das für Ihre Softwareentwicklung bedeutet

Software Supply Chain Security ist kein einmaliges Projekt. Es ist ein dauerhafter Prozess, der in die Entwicklungskultur eingebettet sein muss. Die gute Nachricht: Viele der notwendigen Tools sind Open Source und in moderne Build-Systeme integrierbar – ohne komplette Prozessumstellungen.

Der erste Schritt ist der ehrlichste: Wissen Sie, was in Ihrer Software steckt? Wenn nicht, ist eine SBOM-Inventur der sinnvolle Ausgangspunkt. Was nicht sichtbar ist, kann nicht geschützt werden.