Abhängigkeitssicherheit und Software Composition Analysis

Moderne Anwendungen bestehen zu großen Teilen aus Bibliotheken und Frameworks von Drittanbietern aus dem Open-Source-Bereich. Eine typische Node.js-Anwendung kann über 1.000 transitive Abhängigkeiten haben; ein Java-Projekt bindet möglicherweise Hunderte Maven-Artefakte ein. Jede Abhängigkeit ist eine potenzielle Angriffsfläche. Die Log4Shell-Sicherheitslücke (CVE-2021-44228) in der Log4j-Bibliothek zeigte, dass eine einzige Abhängigkeit innerhalb weniger Tage nach ihrer Bekanntgabe Millionen von Anwendungen weltweit unmittelbar ausnutzbar machen konnte.

Tools für die Software Composition Analysis (SCA) erfassen automatisch alle Open-Source-Komponenten einer Anwendung – einschließlich transitiver Abhängigkeiten (Abhängigkeiten Ihrer Abhängigkeiten) – und gleichen sie kontinuierlich mit Schwachstellendatenbanken auf bekannte CVEs ab. SCA erstellt eine Software Bill of Materials (SBOM), in der jede Komponente und Version aufgeführt ist. Dadurch lassen sich betroffene Systeme schnell identifizieren, wenn neue Schwachstellen bekannt gegeben werden.

Transitive Abhängigkeiten sind Bibliotheken, von denen Ihre direkten Abhängigkeiten abhängen und die Sie nicht ausdrücklich ausgewählt haben. Sie können direkt von Paket A abhängen, das von Paket B (Version 1.2) abhängt, das wiederum Paket C (Version 3.0 – eine anfällige Version) benötigt. Sie sind sich Paket C nicht bewusst, aber Ihre Anwendung führt es aus. SCA-Tools durchlaufen den vollständigen Abhängigkeitsbaum und machen diese verborgenen Schwachstellen sichtbar, auf die Entwickler keinen direkten Einblick haben.

Eine Software Bill of Materials (SBOM) ist ein formales, maschinenlesbares Verzeichnis aller Komponenten eines Softwareprodukts – vergleichbar mit einer Zutatenliste auf einem Lebensmittel. Zu den SBOM-Formaten gehören SPDX (Linux Foundation) und CycloneDX (OWASP). Die US Executive Order 14028 (2021) schrieb SBOMs für Software vor, die an die US-Bundesregierung verkauft wird. Mit einer SBOM können Sicherheitsteams sofort die Frage beantworten: „Welche unserer Produkte enthalten Log4j?“ – und erhalten innerhalb weniger Minuten statt nach tagelanger manueller Suche eine Antwort.

Das Festlegen von Abhängigkeitsversionen gibt exakte Versionen von Abhängigkeiten vor, statt flexible Bereiche zu verwenden (^1.2.3 oder *). Lock-Dateien (package-lock.json, yarn.lock, Pipfile.lock, Gemfile.lock) speichern die beim Installieren exakt aufgelöste Version jeder Abhängigkeit. Sie sollten in die Quellcodeverwaltung übernommen werden, damit jedes Teammitglied und jede CI/CD-Pipeline identische Abhängigkeitsversionen verwendet. So werden Supply-Chain-Angriffe verhindert, bei denen Paketversionen zwischen Installationen manipuliert werden.

Supply-Chain-Angriffe zielen auf das Ökosystem der Abhängigkeiten. Beim Typosquatting werden schädliche Pakete mit Namen veröffentlicht, die beliebten Paketen ähneln (z. B. lodahs statt lodash), in der Hoffnung, dass Entwickler den Namen falsch eingeben. Dependency-Confusion-Angriffe nutzen die Reihenfolge aus, in der Paketmanager Registries durchsuchen: Ein Angreifer veröffentlicht ein schädliches Paket mit demselben Namen wie ein internes privates Paket, aber mit einer höheren Versionsnummer. Dadurch installiert der Paketmanager stattdessen die schädliche öffentliche Version.

In der Branche werden mehrere SCA-Tools häufig eingesetzt. Snyk bietet eine entwicklerfreundliche Prüfung von Abhängigkeiten mit automatischen PRs zur Behebung. OWASP Dependency-Check ist ein kostenloses, weit verbreitetes Tool für Java, .NET, Python und Ruby. GitHub Dependabot erstellt automatisch Pull Requests, um anfällige Abhängigkeiten in GitHub-Repositories zu aktualisieren. JFrog Xray und Sonatype Nexus IQ integrieren SCA in Artefakt-Repositories, um zu verhindern, dass anfällige Builds die Produktion erreichen.

SCA ist am wirksamsten, wenn sie als Quality Gate in der CI/CD-Pipeline integriert wird. Bei jedem Pull Request und jedem Build führt die Pipeline das SCA-Tool aus und schlägt fehl, wenn CVEs mit kritischem oder hohem Schweregrad in den Abhängigkeiten gefunden werden. Dieser „Shift-left“-Ansatz erkennt anfällige Abhängigkeiten, bevor sie die Produktion erreichen – nicht erst Monate später bei einer manuellen Sicherheitsprüfung oder nach einem Sicherheitsvorfall. Teams sollten klare Schwellenwerte für den Schweregrad von Schwachstellen festlegen, die bestimmen, welche Befunde ein Deployment blockieren und welche lediglich Warnungen erzeugen.

Bewerten Sie vor dem Hinzufügen einer Abhängigkeit deren Sicherheitsstatus anhand mehrerer Kriterien. Wartungsaktivität: Wird das Projekt aktiv gepflegt? Wann erfolgten der letzte Commit und die letzte Veröffentlichung? Bekannte Schwachstellenhistorie: Wie viele CVEs gab es und wie schnell wurden sie behoben? Downloadvolumen: Weit verbreitete Pakete stehen stärker unter Sicherheitsbeobachtung. Anzahl der Abhängigkeiten: Pakete mit weniger Abhängigkeiten bringen ein geringeres Transitivitätsrisiko mit sich. Das OpenSSF Scorecard bietet eine automatisierte Bewertung der Sicherheitspraktiken von Open-Source-Projekten.

Wenn SCA eine anfällige Abhängigkeit identifiziert, gibt es mehrere Strategien zur Behebung. Aktualisieren Sie auf eine gepatchte Version – sofern verfügbar, ist dies die bevorzugte Option. Virtuelles Patching durch WAF-Regeln kann bekannte Angriffswege eindämmen, während ein Update vorbereitet wird. Entfernen Sie die Abhängigkeit, wenn sie nicht mehr benötigt wird. Akzeptieren Sie das Risiko mit einer dokumentierten Begründung, wenn die Schwachstelle im konkreten Nutzungskontext nicht ausnutzbar ist (z. B. eine serverseitige Schwachstelle in einer clientseitigen Bibliothek). Lassen Sie kritische Schwachstellen niemals ohne dokumentierte Risikoakzeptanz unbehandelt.

SCA-Tools erfüllen einen doppelten Zweck: Sie identifizieren Sicherheitslücken und weisen auf Lizenz-Compliance-Probleme bei Open-Source-Abhängigkeiten hin. Zu den häufig problematischen Lizenzen gehören GPL v2/v3 (Copyleft – bei Weitergabe muss auch Ihr Produkt als Open Source veröffentlicht werden), AGPL (erweitert GPL auf Netzwerkdienste) und SSPL. Die Verwendung einer GPL-lizenzierten Bibliothek in proprietärer kommerzieller Software ohne kommerzielle Lizenz kann erhebliche rechtliche Haftungsrisiken schaffen. SCA-Tools wie FOSSA, Black Duck und WhiteSource automatisieren die Lizenzprüfung parallel zur Erkennung von Schwachstellen und gewährleisten so die Einhaltung der Open-Source-Verpflichtungen.

Testen Sie Ihr Verständnis der CompTIA-Security+-Konzepte (SY0-701) aus dieser Lektion.

In dieser Lektion haben Sie gelernt: SCA-Tools durchsuchen den vollständigen Abhängigkeitsbaum einschließlich transitiver Abhängigkeiten nach bekannten CVEs, SBOMs liefern ein maschinenlesbares Verzeichnis und ermöglichen eine schnelle Reaktion, wenn neue Schwachstellen bekannt gegeben werden, und die Integration von SCA als Quality Gate in der CI/CD-Pipeline erkennt anfällige Abhängigkeiten, bevor sie die Produktion erreichen. Als Nächstes beschäftigen wir uns mit DevSecOps und damit, wie Sicherheitskontrollen im gesamten CI/CD-Prozess nach links verschoben werden können.