Was ist Dependency Scanning in der Cloud-Sicherheit?

Was ist Dependency Scanning?

Dependency Scanning ist die automatisierte Analyse der Bibliotheken, Frameworks und Pakete von Drittanbietern, die Entwicklungsteams zum Erstellen von Anwendungen nutzen. Statt den selbst geschriebenen Code zu prüfen, untersucht es die importierten externen Open-Source- und kommerziellen Komponenten auf bekannte Sicherheitsrisiken. Dieser Prozess wird häufig als software composition analysis (SCA) bezeichnet.

Das Scanning erkennt bekannte Schwachstellen, die als Common Vulnerabilities and Exposures (CVEs) katalogisiert sind, sowohl in direkten als auch in transitiven dependencies.

• Direkte dependencies: Diese Bibliotheken werden explizit in der Manifest-Datei eines Projekts aufgeführt.

• Transitive dependencies: Diese Bibliotheken werden von den direkten dependencies benötigt und ziehen oft einen tiefen Baum an zusätzlichem Code nach sich.

Ein Dependency Checker liest Manifest-Dateien wie package.json, pom.xml oder requirements.txt. Er vergleicht die dort aufgeführten Versionen mit umfassenden Schwachstellendatenbanken wie der National Vulnerability Database (NVD) oder der GitHub Advisory Database.

Das Scanning kann in mehreren Phasen des Software-Lebenszyklus erfolgen, um Probleme früh und regelmäßig zu erkennen:

• Entwicklung: Tools laufen in der Integrated Development Environment (IDE), während der Code geschrieben wird.

• Build: Scanner prüfen den Code während des Commits oder innerhalb von CI/CD pipelines.

• Runtime: Fortgeschrittene Tools analysieren laufende Anwendungen und zeigen, was tatsächlich in den Speicher geladen ist.

Es lohnt sich, Dependency Scanning von anderen Testverfahren abzugrenzen. SAST (Static Application Security Testing) scannt den eigenen Quellcode auf Fehler, während DAST (Dynamic Application Security Testing) laufende Anwendungen auf externe Schwachstellen testet. Dependency Scanning zielt gezielt auf die Lieferkette des vorgefertigten Codes ab, den ein Team einsetzt.

Warum Dependency Scanning in cloud-native Umgebungen zählt

Moderne Anwendungen stützen sich stark auf Open-Source-Komponenten. Eine typische Anwendung enthält Hunderte oder sogar Tausende externer dependencies. Das bedeutet: Der Großteil des Codes in einer Produktionsumgebung stammt wahrscheinlich von jemandem außerhalb der eigenen Organisation.

Cloud-native Architekturen wie container, microservices und serverless functions verstärken die Risiken dieser dependencies.

• Kurzlebige workloads: Verwundbarer Code lässt sich in kurzlebigen container schnell über die gesamte Infrastruktur verteilen und ohne Automatisierung kaum nachverfolgen.

• Container images: Ein container image bündelt dependencies, sodass sich ein einziges verwundbares image sofort über Tausende Pods repliziert.

• Gemeinsam genutzte Base Images: Enthält ein Base Image eine Schwachstelle, überträgt sich dieser Fehler auf jede Anwendung, die darauf aufbaut.

Supply-Chain-Angriffe haben den Ernst dieser Risiken gezeigt. Aufsehenerregende Vorfälle wie Log4Shell (CVE-2021-44228) im Dezember 2021 und Angriffe mit bösartigen npm-Paketen nutzten das Vertrauen aus, das Organisationen in externen Code setzen.

Supply-Chain-Angriffe missbrauchen dieses Vertrauen über mehrere Vektoren:

Typosquatting-Angriffe

• Angreifer veröffentlichen Pakete mit Namen, die populären Bibliotheken ähneln (etwa „reqeusts“ statt „requests“).

• Entwicklungsteams installieren durch Tippfehler versehentlich bösartige Pakete.

Dependency Confusion

• Angreifer laden bösartige Pakete unter internen Paketnamen in öffentliche Registries hoch.

• Build-Systeme bevorzugen aufgrund einer Fehlkonfiguration öffentliche Pakete gegenüber privaten.

Übernahme bösartiger Maintainer

• Angreifer kompromittieren Maintainer-Konten oder überzeugen Maintainer, die Eigentümerschaft zu übertragen.

• Legitime Pakete werden mit bösartigem Code aktualisiert.

Bösartige Post-Install-Skripte

• Pakete führen während der Installation über Lifecycle-Hooks beliebigen Code aus.

• Skripte greifen Zugangsdaten ab, installieren Backdoors oder schürfen Kryptowährungen.

Ausnutzung bekannter Schwachstellen

• Angreifer durchsuchen öffentliche Repositories nach Anwendungen mit verwundbaren dependencies.

• Log4Shell (CVE-2021-44228) wurde binnen Stunden nach der Veröffentlichung ausgenutzt.

• Automatisiertes Scannen macht es trivial, Ziele in großem Maßstab zu finden.

Vorgaben des öffentlichen Sektors und Branchenrichtlinien betonen software supply chain security immer stärker. Die Executive Order 14028 (erlassen im Mai 2021) und das NIST Secure Software Development Framework (SSDF) treiben die Verbreitung von SBOM bei US-Bundesbehörden und ihren Software-Lieferanten voran. Viele Unternehmen nehmen SBOM-Anforderungen in ihre Beschaffungsprozesse für kritische Infrastrukturen und regulierte workloads auf.

Werden dependencies nicht abgesichert, drohen erhebliche geschäftliche Folgen:

• Datenlecks: Angreifer nutzen bekannte Schwachstellen aus, um an sensible Kundendaten zu gelangen.

• Betriebsunterbrechungen: Bösartige Pakete enthalten Cryptominer oder Code, der Anwendungen zum Absturz bringt.

• Regulatorische Strafen: Verstöße gegen Gesetze zur data protection können empfindliche Bußgelder nach sich ziehen.

• Reputationsschäden: Vertrauen geht verloren, sobald Kunden erfahren, dass ihre Daten über eine bekannte Schwachstelle offengelegt wurden.

Funktionsweise von Dependency Scanning

Dependency Scanning folgt in der Regel einem strukturierten vierstufigen Prozess, um Risiken zu erkennen und zu melden.

1. Erkennung: Der Scanner identifiziert die Manifest-Dateien der dependencies in den code repositories oder container images.

2. Inventarisierung: Das Tool parst diese Dateien und erstellt einen vollständigen Dependency-Graphen, der jede direkte und transitive Bibliothek abbildet.

3. Abgleich: Der Scanner vergleicht das erfasste Inventar mit Schwachstellendatenbanken und findet Treffer für konkrete Versionen.

4. Reporting: Das Tool erstellt einen Bericht mit Funden, Schweregraden, betroffenen Versionen und Hinweisen zur Behebung.

Scanner setzen je nach Ziel unterschiedliche Techniken ein. Das statische Parsen von Manifesten liest Konfigurationsdateien, während die Layer-Analyse von container images kompilierte dependencies innerhalb von Docker-Images untersucht. Runtime Scanning erhöht die Präzision, indem es Bibliotheken erkennt, die in Produktionsumgebungen tatsächlich geladen sind und ausgeführt werden, und ergänzt so die statische Manifest-Analyse und das Scannen der Image-Layer.

Für eine präzise Analyse der Software-dependencies ist es entscheidend, die Schwachstellendatenbanken aktuell zu halten. Sicherheitsforschende entdecken täglich neue Schwachstellen, deshalb müssen Scanner sich häufig mit den Quellen synchronisieren, um die neuesten Bedrohungen zu erkennen. Die meisten Tools arbeiten signaturbasiert, einige moderne Lösungen nutzen zusätzlich eine verhaltensbasierte Erkennung, um bösartige Aktivitäten aufzudecken, die noch nicht als CVE katalogisiert sind.

Arten von dependencies und Scanning-Ansätze

Unterschiedliche Programmiersprachen und Infrastrukturkomponenten erfordern jeweils spezifische Scanning-Ansätze.

Sprachspezifische Paket-Ökosysteme

Jede Programmiersprache nutzt einen eigenen Paketmanager und ein eigenes Format für Manifest-Dateien. Das bestimmt, wie dependencies aufgelöst und gescannt werden.

Jedes Ökosystem löst dependencies anders auf. npm etwa erlaubt verschachtelte dependencies, die zu mehreren Versionen derselben Bibliothek führen können, während Go versucht, dependencies flach zu halten. Für einige Sprachen gibt es sehr ausgereifte Tools für das Dependency Scanning, andere erfordern eine speziellere Konfiguration.

Scanning von container und cloud-native Umgebungen

Das Scannen von container images prüft Schwachstellen sowohl in den Base-Image-Layern als auch in den Anwendungs-Layern.

• Base-Image-Layer: Diese enthalten Betriebssystem-Pakete, die über Tools wie apt oder yum installiert werden.

• Anwendungs-Layer: Diese enthalten die sprachspezifischen Bibliotheken und den Code, der auf dem Betriebssystem aufsetzt.

Beide zu scannen ist entscheidend, denn eine Schwachstelle in einer Systembibliothek wie openssl ist genauso gefährlich wie ein Fehler in einem Python-Paket.

In Kubernetes-Umgebungen setzen Teams häufig admission controllers mit Policy-Engines (etwa open policy agent oder Kyverno) ein, um verwundbare oder nicht konforme images vom Deployment auszuschließen. Das Scannen von images und die Cluster-Richtlinien lassen sich mit Runtime-Signalen kombinieren, um sich auf die dependencies zu konzentrieren, die in Produktions-workloads tatsächlich geladen sind und ausgeführt werden. Auch serverless functions wie AWS Lambda erfordern ein Scanning, da sie dependencies in das Deployment-Paket bündeln, das mit der Zeit veralten kann.

Integration in Entwicklungs-Workflows und CI/CD pipelines

Die wirksamste Sicherheitsstrategie ist shift-left (Vorverlagerung der Sicherheit in den Entwicklungsprozess). Sie bedeutet, Schwachstellen früh im Entwicklungsprozess zu erkennen, bevor sie die Produktion erreichen.

Das Scanning lässt sich an mehreren wichtigen Punkten im Workflow integrieren:

• IDE-Plugins: Sie geben Entwicklungsteams in real-time Rückmeldung, während diese Code schreiben und neue Bibliotheken importieren.

• Pre-Commit-Hooks: Diese Skripte blockieren Commits, die kritische Schwachstellen einführen.

• Pull-Request-Scanning: Automatisierte Prüfungen laufen bei jedem Pull Request und stellen sicher, dass neuer Code vor dem Review die Sicherheitsstandards erfüllt.

• Gates in der CI/CD pipeline: Build-Pipelines lassen sich so konfigurieren, dass sie bei Problemen mit hohem Schweregrad fehlschlagen und so die Erstellung verwundbarer Artefakte verhindern. Eine einzige Policy-Engine sorgt dafür, dass IDE-Prüfungen, Pull-Request-Scans, Pipeline-Gates, Registry-Scans und Cluster-Admission-Entscheidungen denselben Schweregrad-Schwellenwerten und Ausnahmeregeln folgen.

• Registry-Scanning: Viele container registries (etwa Amazon ECR, Azure Container Registry und Google Artifact Registry) bieten integriertes Scanning, um Schwachstellen in gespeicherten images zu erkennen, auch in solchen, die zuletzt nicht neu ausgerollt wurden.

• Runtime-Monitoring: Das kontinuierliche Scannen von Produktions-workloads erkennt Risiken in aktiven Anwendungen.

Sicherheits-Gates mit der Entwicklungsgeschwindigkeit in Einklang zu bringen, ist eine häufige Herausforderung. Blockiert jeder Fund mit niedrigem Schweregrad ein Deployment, umgehen Entwicklungsteams die security controls womöglich. Deshalb braucht es klare Richtlinien dazu, welche Schweregrade eine Blockade auslösen.

Automatisierte Updates von dependencies helfen, diese Balance zu halten. Tools erstellen automatisch Pull Requests, um verwundbare Bibliotheken zu aktualisieren, sodass Teams Korrekturen mit einem einzigen Klick zusammenführen.

Risikopriorisierung und vulnerability management

Ein häufiges Problem beim Scannen von OSS ist alert fatigue: Teams werden von Hunderten Funden überrollt.

Um das zu steuern, priorisiert man Risiken anhand des Kontexts statt allein anhand roher Schweregrad-Werte.

• Schweregrad-Werte: CVSS-Bewertungen liefern eine Grundlage, spiegeln aber die spezifische Umgebung nicht wider.

• Ausnutzbarkeit: Es gilt zu prüfen, ob für die Schwachstelle ein bekannter Exploit im Umlauf ist, oft im CISA-KEV-Katalog referenziert.

• Reachability: Es gilt festzustellen, ob der verwundbare Code von der Anwendung tatsächlich geladen und ausgeführt wird.

• Angriffsfläche: Es gilt zu klären, ob die verwundbare Komponente zum Internet hin exponiert oder hinter einer Firewall geschützt ist.

• Datensensibilität: Anwendungen, die Personenbezogene Daten (PII), PHI oder andere kritische Geschäftsdaten verarbeiten, haben Vorrang.

• Geschäftskritikalität: Produktionsumgebungen stehen vor Staging- oder Entwicklungs-Sandboxes im Fokus.

„Toxische Kombinationen“ entstehen, wenn mehrere Risikofaktoren zusammentreffen, etwa eine kritische Schwachstelle in einem zum Internet hin exponierten container mit administrativen Rechten. Die Korrelation von Schwachstellen mit der Netzwerk-Angriffsfläche, den Identitätsberechtigungen und der Datensensibilität hebt realistische attack paths hervor statt isolierter CVEs. Diese korrelierten Risiken stellen unmittelbare Bedrohungen dar und erfordern dringendes Handeln.

Unterschied zwischen Reachability und Ausnutzbarkeit

Reachability und Ausnutzbarkeit sind verwandte, aber unterschiedliche Risikofaktoren:

• Reachability: Die verwundbare Bibliothek ist in den Speicher geladen und die konkrete verwundbare Funktion wird vom Anwendungscode aufgerufen. Tools für die statische Analyse verfolgen Call-Graphen, um die Reachability zu bestimmen.

• Ausnutzbarkeit: Die Schwachstelle lässt sich durch einen Angreifer über verfügbare Angriffsvektoren auslösen (Netzwerkanfragen, Datei-Uploads, API-Aufrufe). Eine Schwachstelle kann reachable, aber nicht ausnutzbar sein, wenn Eingaben bereinigt werden oder der Codepfad privilegierten Zugriff erfordert.

Eine echte Risikopriorisierung verbindet Reachability mit dem Umgebungskontext:

• Netzwerk-Angriffsfläche (zum Internet hin exponiert oder intern);

• Identitätsberechtigungen (worauf die workload zugreifen kann);

• Datensensibilität (Personenbezogene Daten (PII), PHI, Zahlungsdaten);

• bestehende security controls (WAF-Regeln, Netzwerksegmentierung).

Ein Beispiel: Eine kritische SQL-Injection-Schwachstelle in einer erreichbaren Datenbankbibliothek stellt ein minimales Risiko dar, wenn die Anwendung in einem privaten Subnetz ohne externen Netzwerkzugriff und mit rein lesenden Datenbank-Zugangsdaten läuft.

Vulnerability management geht über die reine Erkennung hinaus. Es umfasst den fortlaufenden Prozess, Probleme zu verfolgen, zu priorisieren und zu beheben. Eine software bill of materials (SBOM) ist dabei ein zentrales Werkzeug: Sie dient als umfassendes Inventar, mit dem sich betroffene Komponenten schnell prüfen lassen, sobald neue Schwachstellen bekannt werden.

Herausforderungen bei der Umsetzung und Best Practices

Ein robustes Scanning-Programm einzuführen bringt Hürden mit sich, doch Best Practices ebnen den Weg zum Erfolg.

Häufige Herausforderungen

Beim Ausrollen von Scanning-Tools stoßen Organisationen oft auf spezifische Hindernisse.

• False Positives: Scanner melden mitunter Schwachstellen in Codepfaden, die nie genutzt werden.

• Umgang mit Rauschen: Ein hohes Aufkommen an Funden mit niedrigem Schweregrad lenkt von kritischen Problemen ab.

• Komplexität der Behebung: Für manche dependencies gibt es keine gepatchte Version, oder ein Update bringt die Anwendung zum Absturz.

• Reibung für Entwicklungsteams: Zu viele Sicherheits-Gates bremsen die Entwicklung und frustrieren die Teams.

• Tool-Wildwuchs: Der Einsatz mehrerer verschiedener Scanner führt zu inkonsistenten Ergebnissen und Datensilos.

• Probleme mit transitiven dependencies: Indirekte dependencies lassen sich oft nur schwer aktualisieren, ohne die direkte dependency zu beschädigen, die sie benötigt.

• Lizenzkonformität: Das Management von Open-Source-Lizenzen (etwa GPL, Apache 2.0, MIT) läuft parallel zum Sicherheits-Scanning; Verstöße gegen Lizenzrichtlinien sind häufig und erfordern eine kontinuierliche Überwachung, um rechtliche und Schutzrechts-Risiken zu vermeiden.

Best Practices für wirksames Scanning

Diese Herausforderungen lassen sich mit einem strategischen Ansatz bei der Umsetzung bewältigen.

• Klare Richtlinien festlegen: Es gilt genau zu definieren, welche Schweregrad-Schwellen sofortiges Handeln erfordern und welche Reaktions-SLAs gelten.

• Wo möglich automatisieren: Tools nutzen, die automatisch Pull Requests für Updates von dependencies erstellen.

• Konsequent priorisieren: Die begrenzten Ressourcen zuerst auf ausnutzbare, exponierte Schwachstellen richten.

• Entwicklungsteams befähigen: Teams die Tools und den Kontext geben, die sie brauchen, um Probleme eigenständig zu beheben.

• Überall scannen: Für eine Abdeckung über repositories, CI/CD pipelines, Registries und Runtime-Umgebungen hinweg sorgen.

• SBOM pflegen: Ein genaues, aktuelles Inventar aller Software-Komponenten führen.

• Regelmäßige Updates: Feste Zyklen einplanen, um dependencies zu aktualisieren, auch wenn keine Sicherheitsprobleme gefunden werden.

• Kontinuierlich überwachen: Sich nicht allein auf Scans zur Build-Zeit verlassen, sondern die Produktion auf neu bekannt gewordene Schwachstellen überwachen.

• Teams schulen: Entwicklungsteams darin ausbilden, sichere dependencies auszuwählen und Scan-Ergebnisse zu interpretieren.

Wie Wiz Dependency Scanning mit Cloud-Kontext verändert

Wiz verändert die Analyse von Software-dependencies, indem es über einfache Listen von Schwachstellen hinausgeht und tiefen Cloud-Kontext liefert.

Wiz Code bietet native SCA-Funktionen über repositories hinweg mit einer einheitlichen Policy-Engine und ermöglicht eine konsistente Durchsetzung vom Code-Commit über container registries bis in die Runtime-Umgebungen. Ergänzt wird dies durch den Wiz Runtime Sensor, der eine Reachability-Analyse unterstützt und erkennt, welche dependencies in der Produktion tatsächlich geladen sind und ausgeführt werden.

Der Wiz Security Graph korreliert Funde zu dependencies mit der Cloud-Angriffsfläche (zum Internet hin exponierte workloads), den Identitätsberechtigungen (IAM-Rollen und Service-Konten) und der Datensensibilität (Personenbezogene Daten (PII), PHI, Zahlungsdaten), um echte attack paths sichtbar zu machen und das Wesentliche zu priorisieren.

• Netzwerk-Angriffsfläche: Wiz erkennt, ob die verwundbare workload zum Internet hin exponiert ist.

• Identität und Berechtigungen: Die Plattform analysiert, welche Cloud-Berechtigungen die verwundbare workload besitzt.

• Datensensibilität: Wiz erkennt, ob die workload Zugriff auf sensible Daten wie Personenbezogene Daten (PII) oder PHI hat.

• Pfade für lateral movement: Der Graph zeigt, wie ein Angreifer die Schwachstelle nutzen könnte, um sich zu anderen Teilen des Netzwerks zu bewegen.

Die code-to-cloud-Korrelation macht es möglich, eine verwundbare dependency in einem laufenden container bis zu ihrem konkreten Quell-Repository und dessen Verantwortlichen zurückzuverfolgen. Diese Transparenz ermöglicht schlanke Workflows in gängigen Versionsverwaltungs- und CI-Plattformen, sodass die richtige Person sofort benachrichtigt wird.

Wiz integriert sich in CI/CD pipelines, um zu verhindern, dass riskante dependencies die Produktion erreichen. Die Plattform blockiert Builds anhand von Richtlinien und unterstützt eine KI-gestützte Behebung, die Pull Requests mit konkreten Versions-Updates und Änderungen an dependencies entwirft. Das beschleunigt Korrekturen und belässt Entwicklungsteams zugleich in ihren gewohnten Workflows. So konzentrieren sich Teams auf den kleinen Anteil an Funden, der echte attack paths darstellt.

Demo anfordern und sehen, wie Wiz dabei hilft, Risiken aus dependencies mit vollem Cloud-Kontext zu priorisieren.