Supply-Chain-Risiken in der Software: Open-Source-Abhängigkeiten absichern

Supply-Chain-Risiken in der Software bezeichnen alle Sicherheitsbedrohungen, die aus der Verwendung externer Abhängigkeiten entstehen - also aus Bibliotheken, Frameworks, SDKs und Tools, die ein Softwareprojekt einbindet, ohne dass deren Code intern entwickelt wurde. Da moderne Anwendungen zu einem Grossteil aus fremdem Code bestehen, hat sich dieser Angriffsvektor zu einem der bedeutendsten Risiken in der Anwendungssicherheit entwickelt.

Warum Open-Source-Abhängigkeiten so riskant sind

Ein typisches modernes Softwareprojekt besteht zu 70 bis 90 Prozent aus Drittanbieter-Code. Eine Node.js-Anwendung kann leicht über 1.000 transitive Abhängigkeiten haben - Pakete, die von Paketen abhängen, die von anderen Paketen abhängen. Der eigene Code ist dabei oft nur die Spitze eines riesigen Eisbergs.

Das Kernproblem: Entwicklerteams haben in der Regel nur einen Bruchteil dieser Abhängigkeiten bewusst ausgewählt. Transitive Abhängigkeiten wurden nie direkt geprüft, werden oft nicht aktiv überwacht und können jederzeit eine kritische Schwachstelle enthalten - oder durch einen Angreifer kompromittiert werden.

Die Folgen reichen von ungepatchten bekannten Schwachstellen (wie Log4Shell, CVE-2021-44228) bis zu gezielt eingeschleustem Schadcode in Open-Source-Paketen, der über reguläre Installations- und Update-Prozesse verteilt wird.

Angriffsmuster auf Open-Source-Abhängigkeiten

Typosquatting

Angreifer veröffentlichen Pakete mit Namen, die absichtlich bekannten, legitimen Paketen ähneln:

• colourama statt colorama
• request statt requests
• lodahs statt lodash

Das Paket enthält meist identische Funktionalität plus eingebettete Malware. Tippfehler beim Installieren reichen aus, um den Angreifer-Code ins Projekt einzubinden.

Dependency Confusion

Bei diesem Angriff nutzt ein Angreifer die Tatsache aus, dass viele Paketmanager bei der Namensauflösung öffentliche Registries vor internen bevorzugen. Kennt ein Angreifer den internen Paketnamen eines Unternehmens, kann er ein gleichnamiges öffentliches Paket mit höherer Versionsnummer veröffentlichen. Der Paketmanager wählt dann automatisch die "neuere" öffentliche Version - und damit den Schadcode.

Account Takeover legitimer Paket-Maintainer

Viele Open-Source-Pakete mit Millionen Downloads werden von einzelnen Personen ohne professionelle Sicherheitspraktiken verwaltet. Wird deren Account über Phishing, geleakte Zugangsdaten oder schwache Passwörter übernommen, kann der Angreifer eine neue, schädliche Version des Pakets veröffentlichen - unter dem vertrauenswürdigen Namen des legitimen Maintainers.

Abhängigkeits-Hijacking bei verwaisten Paketen

Open-Source-Projekte werden aufgegeben, wenn Maintainer das Interesse verlieren. Solche verwaisten Pakete können von beliebigen Personen "übernommen" werden - was nicht immer im besten Sinne der Nutzer geschieht. In einigen Fällen haben Angreifer gezielt populäre, aber nicht mehr aktiv gewartete Pakete übernommen.

Einschleusen über Pull Requests

Ein Angreifer kann über scheinbar harmlose Beiträge zu einem Open-Source-Projekt Schadcode einschleusen. Das erfordert Geduld und technisches Verständnis, ermöglicht aber bei erfolgreicher Aufnahme eine sehr breite Verteilung - wie das Beispiel der XZ-Utils-Backdoor (CVE-2024-3094) gezeigt hat, bei der ein Angreifer über zwei Jahre als Contributor Vertrauen aufbaute.

Software Bill of Materials (SBOM)

Die grundlegende Voraussetzung für das Management von Supply-Chain-Risiken ist Transparenz: Welche Komponenten sind überhaupt in einer Anwendung enthalten?

Ein SBOM (Software Bill of Materials) ist eine strukturierte, maschinenlesbare Liste aller in einer Software enthaltenen Komponenten - vergleichbar mit der Zutatenliste eines Lebensmittels. Ein SBOM enthält:

• Alle direkten und transitiven Abhängigkeiten
• Versionsinformationen
• Lizenzinformationen
• Herkunftsinformationen (Quelle, Hash-Werte)

Standardisierte Formate:

• CycloneDX - von OWASP entwickelt, weit verbreitet, gut tooling-unterstützt
• SPDX - von der Linux Foundation, besonders stark bei Lizenz-Compliance
• SWID Tags - ISO/IEC-Standard, häufig in Unternehmensumgebungen

Ein SBOM allein schützt nicht - er muss kontinuierlich gegen Schwachstellendatenbanken abgeglichen werden. Das BSI, die CISA und die EU (Cyber Resilience Act) fordern SBOMs zunehmend als Pflichtbestandteil für kritische Software.

Dependency-Management-Praktiken

Versionspinning und Lock-Dateien

Das Festlegen exakter Versionen verhindert, dass automatische Updates eine kompromittierte neue Version einspielen:

• Schlechte Praxis: requests>=2.0.0 oder "react": "^18.0.0" - erlaubt automatische Updates auf beliebige kompatible Versionen
• Bessere Praxis: requests==2.31.0 oder "react": "18.2.0" - exakte Version fixiert
• Beste Praxis: Hash-basiertes Pinning - nicht nur die Version, sondern der kryptografische Hash des Paketinhalts wird festgelegt

Lock-Dateien (package-lock.json, pnpm-lock.yaml, Cargo.lock, poetry.lock) sollten immer ins Repository eingecheckt und niemals ignoriert werden. Sie stellen sicher, dass alle Teammitglieder und CI/CD-Pipelines identische Abhängigkeiten installieren.

Automatisiertes Schwachstellenscanning

Mehrere Tools prüfen Abhängigkeiten kontinuierlich gegen bekannte Schwachstellen:

• Dependabot (GitHub) - erstellt automatisch Pull Requests für verwundbare Abhängigkeiten
• Renovate - flexibleres Upgrade-Management, kann Updates gruppieren und zeitlich planen
• Snyk - kommerzielles Tool mit guter Developer-Experience, auch für Container-Images
• npm audit / pip-audit / cargo audit - direkt in den jeweiligen Paketmanagern integriert
• OSV-Scanner von Google - prüft gegen die Open Source Vulnerabilities-Datenbank

Diese Tools sollten in CI/CD-Pipelines als Pflichtschritt integriert sein, sodass ein Build mit kritischen Schwachstellen in Abhängigkeiten fehlschlägt.

Dependency Review bei Pull Requests

Jede Änderung an Abhängigkeiten sollte als eigener Review-Schritt behandelt werden. Bevor ein neues Paket aufgenommen wird, sind folgende Fragen relevant:

• Wird das Paket aktiv gepflegt? (letzte Commits, Issue-Reaktionszeit)
• Wie viele Maintainer hat das Projekt? (Einzelpersonen-Projekte sind risikoreicher)
• Hat das Paket eine Security-Policy und einen Responsible-Disclosure-Prozess?
• Welchen OpenSSF-Scorecard-Score hat das Paket?
• Ist das Paket wirklich notwendig, oder kann die Funktion selbst implementiert werden?

Der OpenSSF Scorecard ist ein automatisiertes Tool, das Open-Source-Projekte nach Sicherheitspraktiken bewertet (0-10 Punkte) und dabei Kriterien wie Code-Review-Prozesse, automatisierte Tests, Dependency-Pinning und Schwachstellenbehebungszeiten berücksichtigt.

Private Package Registries und Zugriffskontrolle

Unternehmen sollten ihre eigene Package Registry betreiben (z.B. JFrog Artifactory, Sonatype Nexus oder Azure Artifacts), die als Proxy und Cache für öffentliche Registries dient. Diese Infrastruktur erlaubt:

• Paketprüfung vor der Veröffentlichung im internen Netz
• Blacklisting von als schädlich bekannten Paketen
• Auditierung aller installierten Pakete
• Schutz vor Dependency-Confusion-Angriffen durch klare Namensraum-Konfiguration

Scoped Packages (@firmenname/paketname) mit fest konfiguriertem internen Registry für diesen Scope verhindern, dass ein gleichnamiges öffentliches Paket bevorzugt wird.

Regulatorische Anforderungen

NIS2-Richtlinie

Artikel 21 der NIS2-Richtlinie verlangt von kritischen und wichtigen Einrichtungen explizit Sicherheitsmaßnahmen in der Lieferkette. Dazu gehört die Bewertung von Sicherheitsrisiken in Zulieferer-Beziehungen und die vertragliche Verankerung von Sicherheitsanforderungen.

Cyber Resilience Act (CRA)

Der Cyber Resilience Act, der 2024 in Kraft getreten ist, verpflichtet Hersteller von Produkten mit digitalen Elementen zur Erstellung und Pflege von SBOMs, zur Bereitstellung von Sicherheitsupdates über die gesamte Produktlebensdauer und zur Meldung aktiv ausgenutzter Schwachstellen.

OWASP Top 10

"Vulnerable and Outdated Components" ist seit Jahren in den OWASP Top 10 vertreten und steht als A06:2021 für das weit verbreitete Problem unsicherer Drittanbieterkomponenten in Webanwendungen.

Build-Pipeline-Sicherheit

Neben den Abhängigkeiten selbst ist auch der Build-Prozess ein Angriffsziel. Maßnahmen für sichere Build-Pipelines:

• Least Privilege in CI/CD: Jede Pipeline bekommt nur die minimal notwendigen Secrets und Berechtigungen. Deployment-Secrets gelten nur für den Haupt-Branch.
• Ephemere Build-Umgebungen: Jeder Build läuft in einer frischen, nicht persistenten Umgebung. Permanente Build-Server können kompromittiert bleiben, ohne dass dies bemerkt wird.
• Hermetic Builds: Die Build-Umgebung hat keinen Internetzugriff während des Builds. Alle Abhängigkeiten werden vorab in einem internen Cache bereitgestellt.
• Signierte Artefakte: Build-Outputs werden kryptografisch signiert (z.B. mit Sigstore/Cosign), sodass die Herkunft jederzeit nachvollziehbar ist.
• SLSA-Framework: Die Supply-chain Levels for Software Artifacts (SLSA) definieren Sicherheitsstufen für Build-Prozesse. SLSA Level 3 schützt gegen kompromittierte Build-Systeme.

Umgang mit Schwachstellen in Abhängigkeiten

Wenn eine neue kritische Schwachstelle in einer weit verbreiteten Bibliothek bekannt wird, stehen viele Teams vor dem Problem, nicht zu wissen, welche ihrer Anwendungen betroffen sind. Mit einem aktuellen SBOM kann diese Frage innerhalb von Minuten beantwortet werden.

Empfohlener Reaktionsablauf:

1. SBOM aller Produktivsysteme gegen die neue CVE prüfen
2. Betroffene Anwendungen identifizieren und priorisieren (Kritikalität, Erreichbarkeit der Schwachstelle)
3. Verfügbarkeit eines Patches prüfen - ist eine neue Version erschienen?
4. Falls kein Patch verfügbar: Workarounds oder Mitigationen umsetzen (z.B. Features deaktivieren, WAF-Regeln)
5. Patch testen, ausrollen und im SBOM aktualisieren

Fazit

Supply-Chain-Risiken durch Open-Source-Abhängigkeiten sind keine abstrakte Gefahr, sondern ein alltägliches, konkretes Risiko in der Softwareentwicklung. Die Voraussetzung für wirksamen Schutz ist zunächst Transparenz: Wer nicht weiß, was in seiner Software steckt, kann es nicht absichern. SBOMs, automatisiertes Vulnerability-Scanning, konsequentes Dependency-Pinning und eine gehärtete Build-Pipeline sind die praktischen Grundlagen, auf denen eine wirksame Abwehr gegen Supply-Chain-Angriffe aufgebaut werden kann.