Definition von Software Composition Analysis Scanning
SCA-Scanning ist die automatisierte Analyse von Anwendungs-Codebasen, um alle Open-Source-Komponenten und Komponenten von Drittanbietern zu identifizieren. So lässt sich genau nachvollziehen, welcher externe Code innerhalb einer Software läuft. Auf dieser Grundlage lassen sich die damit verbundenen Risiken gezielt steuern.
SCA-Tools erstellen ein software bill of materials (SBOM), indem sie jede dependency, jede Version und jede Lizenz eines Projekts inventarisieren. Modernes SCA generiert SBOMs in standardisierten Formaten – vor allem SPDX (Software Package Data Exchange) und CycloneDX. So lassen sich diese Formate konsistent über Tools und Organisationen hinweg teilen. Die maschinenlesbaren Formate ermöglichen zudem kontinuierliches Monitoring: Sobald ein neues CVE erscheint, prüfen SCA-Tools sofort alle SBOMs und identifizieren betroffene Systeme.
Scanner führen diese Analyse auf zwei grundlegende Arten durch. Einige scannen Manifest-Dateien wie package.json oder requirements.txt, um deklarierte dependencies zu erfassen. Andere analysieren kompilierte Artefakte binär, um Komponenten zu finden, die in keiner Datei aufgeführt sind.
Entscheidend ist, dass SCA zwei Arten von dependencies erkennt: direkte dependencies, die explizit deklariert werden, und transitive dependencies, die Bibliotheken automatisch nachladen. Zusätzlich bewertet es Lizenzrisiken und sichert so die Einhaltung der Anforderungen an Open-Source-Lizenzen.
Warum SCA-Scanning für moderne Anwendungssicherheit entscheidend ist
Moderne Anwendungen enthalten in der Regel mehr Open-Source-Code als proprietären Code. Laut dem Bericht State of the Software Supply Chain 2024 von Sonatype besteht ein Großteil kommerzieller Anwendungen aus Open-Source-Komponenten. Bei manchen Codebasen nähert sich der OSS-Anteil 90 %. Damit hängt ein erheblicher Teil des Sicherheitsstatus einer Anwendung von Code ab, den das eigene Team nicht selbst geschrieben hat.
Supply-Chain-Angriffe nutzen Schwachstellen in diesen weitverbreiteten Bibliotheken aus, wie prominente Vorfälle rund um Log4j gezeigt haben. Mit steigender Entwicklungsgeschwindigkeit fügen Teams immer mehr dependencies hinzu und vergrößern so rasch die Angriffsfläche.
Eine weitere große Herausforderung ist der sogenannte „dependency drift". Dabei veralten Komponenten mit der Zeit und werden angreifbar, ohne dass es jemand bemerkt. Laut dem Open Source Security and Risk Analysis Report 2024 von Synopsys enthielten 91 % der Codebasen Komponenten, die zehn oder mehr Versionen hinter dem aktuellen Release lagen. Das vergrößert die Angriffsfläche durch bekannte Schwachstellen erheblich, die neuere Versionen bereits schließen. Herkömmliche Sicherheits-Tools übersehen diese Schwachstellen häufig, weil sie den eigenen Code prüfen und nicht die eingebetteten Bibliotheken von Drittanbietern.
Entsprechend fordern regulatorische Frameworks zunehmend Transparenz über die Software-Zusammensetzung, meist über verpflichtende SBOMs. Die Executive Order 14028 schreibt SBOMs für Software-Lieferanten von Bundesbehörden vor. Das Secure Software Development Framework (SSDF) von NIST liefert die passenden Umsetzungshinweise.
So funktioniert SCA-Scanning in der Praxis
Der Prozess beginnt mit einer Erkennungsphase. In dieser Phase identifizieren SCA-Tools alle dependencies über Repositories, container und Artefakte hinweg. Anschließend gleicht das Tool die Komponentenversionen mit Schwachstellendatenbanken ab und markiert alle bekannten Probleme.
Moderne SCA-Tools gehen weiter. Sie korrelieren Funde mit dem CVSS-Schweregrad, der Verfügbarkeit von Exploits (etwa CISA KEV), der Exploit-Vorhersage (EPSS) und dem Patch-Status. Führende Tools ergänzen graphbasierten Kontext und runtime-Signale. So gewichten sie erreichbare Schwachstellen in öffentlich exponierten workloads höher als theoretische Probleme in ungenutzten Code-Pfaden. Damit wird nicht nur klar, welche Schwachstellen existieren, sondern auch, welche davon eine unmittelbare Bedrohung in der jeweiligen Umgebung darstellen.
Empfehlungen zur Behebung: Das Tool generiert konkrete Hinweise, etwa zu welcher Version aktualisiert werden sollte oder welche alternativen Pakete sich anbieten.
Kontinuierliches Monitoring: SCA alarmiert das Team sofort, sobald in bereits genutzten dependencies neue Schwachstellen auftauchen.
Scanning über den gesamten Lebenszyklus: Scans laufen in mehreren Phasen, darunter Arbeitsplätze der Entwicklungsteams, Build-Pipelines, container registries und runtime-Umgebungen.
SCA-Scanning im Vergleich zu anderen Testmethoden für die Anwendungssicherheit
SCA unterscheidet sich von SAST (static application security testing), das den eigenen proprietären Code auf Programmierfehler wie SQL-Injection untersucht. SAST betrachtet den selbst geschriebenen Code, während SCA gezielt die importierten Komponenten von Drittanbietern prüft.
Ebenso grenzt es sich von DAST (dynamic application security testing) ab, das laufende Anwendungen von außen testet. In containerized workloads adressiert SCA die Anwendungs-dependencies. Das image scanning deckt zusätzlich Pakete des Betriebssystems und des base image ab. Gemeinsam decken beide Verfahren das Risiko rund um container vollständig ab.
Wichtig ist die klare Abgrenzung zur SBOM-Generierung. Die SBOM-Generierung dokumentiert die Komponenten, während SCA dieses Inventar analysiert und Schwachstellen findet. Umfassende Sicherheit entsteht erst im Zusammenspiel von SCA mit weiteren Testmethoden wie SAST, DAST und IaC-Scanning.
Zentrale Funktionen effektiver SCA-Scanning-Tools
Ein effektives Tool sollte gängige Sprachen und Paketmanager unterstützen (npm, Maven, PyPI, RubyGems, NuGet, Go-Module). Es sollte mehrere Quellen einlesen können, darunter Lockfiles (package-lock.json, requirements.txt), SBOMs (SPDX, CycloneDX), Ebenen von container images sowie binäre Fingerabdrücke. Dieser Ansatz mit mehreren Quellen sorgt für eine umfassende Erkennung von dependencies. Zusätzlich braucht es eine starke Analyse transitiver dependencies, die indirekte Schwachstellen tief im Abhängigkeitsbaum aufspürt.
Priorisierung: Funktionen, die das Rauschen reduzieren und sich auf ausnutzbare oder erreichbare Schwachstellen konzentrieren, sind entscheidend für die Bewältigung des Arbeitsaufwands. Eine effektive Priorisierung stützt sich auf mehrere Signale:
CVSS-Schweregrade liefern eine grundlegende Risikobewertung (Critical, High, Medium, Low).
Der CISA-KEV-Katalog erfasst Schwachstellen, die aktiv bei Angriffen ausgenutzt werden.
EPSS-Scores schätzen die Wahrscheinlichkeit eines Exploits auf Basis von threat intelligence.
Die runtime-Erreichbarkeit zeigt, ob verwundbare Code-Pfade tatsächlich ausgeführt werden.
Die Erreichbarkeit über das Netzwerk unterscheidet nach außen gerichtete von rein internen workloads.
Die Datensensibilität erfasst den Zugriff auf personenbezogene Daten (PII), Anmeldeinformationen oder geschäftskritische Daten.
Die Kritikalität der Ressourcen unterscheidet Produktions- von Entwicklungsumgebungen.
Dieser mehrstufige Ansatz hilft Teams, Schwachstellen zu beheben, die einen hohen Schweregrad mit tatsächlicher Ausnutzbarkeit in der jeweiligen Umgebung verbinden.
Integrationen für Entwicklungsteams: Plugins für IDEs und Prüfungen bei Pull Requests ermöglichen shift-left security (die frühe Verlagerung der Sicherheit in den Entwicklungsprozess), sodass Entwicklungsteams Probleme beheben, bevor Code gemergt wird.
agentless Integrationen: Anbindungen an Versionskontrollsysteme (GitHub, GitLab, Bitbucket), CI/CD-Plattformen (Jenkins, CircleCI, GitHub Actions) und container registries (ECR, ACR, GCR) erfordern keine Agent-Installation. Das reduziert Reibungsverluste und sorgt für eine breite Abdeckung über Repositories und Images hinweg, ohne die Build-Leistung zu beeinträchtigen.
Automatisierte Behebung: Vorschläge für sichere Versions-Upgrades beschleunigen den Behebungsprozess.
Lizenz-Compliance: Funktionen, die restriktive Lizenzen kennzeichnen, verhindern rechtliche Konflikte mit den Richtlinien einer Organisation. Laut dem Synopsys-Bericht 2024 weisen über 53 % der Codebasen Konflikte bei Open-Source-Lizenzen auf, etwa durch GPL-lizenzierte Komponenten in proprietärer Software oder durch das Mischen inkompatibler Lizenzen wie Apache 2.0 und GPL v2 im selben Projekt.
Auch kontinuierliches Monitoring ist unverzichtbar. So erhalten Teams eine Warnung in dem Moment, in dem ein neues CVE eine bestehende dependency betrifft.
Herausforderungen bei der Umsetzung und Best Practices für SCA-Scanning
Eine häufige Herausforderung bei der Umsetzung ist „alert fatigue": SCA-Tools erzeugen Tausende von Funden und überfordern damit die Sicherheitsteams. Verschärft wird dies oft durch false positives, bei denen markierte Schwachstellen im konkreten Kontext gar nicht ausnutzbar sind.
Lücken und Inkonsistenzen zwischen den Datenquellen für Schwachstellen betreffen etwa Namenskonventionen für Pakete, Versionierungsschemata und Metadatenformate. Ohne saubere Normalisierung führen sie zu übersehenen oder falsch zugeordneten Funden. Dasselbe Paket kann beispielsweise in der National Vulnerability Database anders referenziert sein als in den GitHub Security Advisories. Zudem fällt die Priorisierung von Fixes schwer, wenn nahezu jede dependency mehrere Schwachstellen aufzuweisen scheint.
Richtlinien etablieren: Akzeptable Risikoniveaus und SLAs für Schwachstellen steuern die Behebung.
Workflows automatisieren: Funde gelangen direkt an die zuständigen Entwicklungsteams und schaffen so klare Verantwortlichkeiten.
Nahtlos integrieren: SCA fügt sich in bestehende Workflows der Entwicklungsteams ein und vermeidet Reibungsverluste sowie Verzögerungen.
Regelmäßig aktualisieren: Updates von dependencies gehören fest zur Wartung und verhindern die Anhäufung von Schwachstellen.
Praktiken für dependency-Hygiene
Versionen pinnen: Exakte Versionsnummern in Lockfiles (package-lock.json, Gemfile.lock) statt Versionsbereiche sorgen für reproduzierbare Builds.
Updates automatisieren: Tools wie Renovate oder Dependabot erstellen automatisch Pull Requests für Updates von dependencies.
Freigabelisten pflegen: Freigegebene Pakete und Versionen erfüllen die eigenen Sicherheits- und Lizenzstandards.
Minimale base images verwenden: Distroless- oder Alpine-basierte Images reduzieren vererbte Schwachstellen von Anfang an.
Dependencies regelmäßig prüfen: Vierteljährliche Reviews entfernen ungenutzte dependencies und konsolidieren doppelte Pakete.
SCA-Scanning in cloud-native und container-Umgebungen
Containerized Anwendungen bündeln dependencies gemeinsam. Damit wird SCA für die Absicherung der container supply chain unverzichtbar. Da workloads in Kubernetes kurzlebig sind, reicht ein Scan zur Build-Zeit nicht aus; nötig ist ein kontinuierliches SCA-Monitoring.
Multi-Stage-Builds verschleiern oft, an welcher Stelle im Build-Prozess eine verwundbare dependency hinzukam. Effektives SCA scannt das finale Image einschließlich aller Basisebenen und verfolgt die Herkunft zurück bis zur konkreten Build-Stufe, die jede Komponente hinzugefügt hat. So beheben Teams die Ursache. SCA-Tools müssen sich in container registries integrieren und Images bereits vor dem Deployment scannen.
Das Scannen von serverless functions stellt eine besondere Herausforderung dar, weil dependencies häufig direkt mit dem Anwendungscode gebündelt werden. Cloud-native SCA sollte sowohl Anwendungs-dependencies als auch Pakete des Betriebssystems und des base image berücksichtigen, denn vererbte Schwachstellen entstehen oft in der Basisebene. Ein auf Ubuntu basierendes Node.js-Anwendungsimage erbt beispielsweise Dutzende CVEs auf Betriebssystemebene, bevor überhaupt Anwendungscode hinzukommt. Letztlich entscheidet der runtime-Kontext darüber, welche Schwachstellen in container ein tatsächliches Risiko für die Umgebung darstellen.
code-to-cloud-Lineage schafft Klarheit über Verantwortlichkeiten, indem sie Funde vom Quell-Repository über das container image bis zum laufenden workload abbildet. Diese Nachvollziehbarkeit ermöglicht es Sicherheitsteams, Fixes schnell an das richtige Entwicklungsteam weiterzuleiten. Ein Beispiel: Eine verwundbare Python-Bibliothek in einem Produktions-Pod stammt aus einem bestimmten Commit im Repository des Data-Science-Teams von vor drei Wochen.
Wiz Code – kontextbasiertes SCA-Scanning für cloud environments
Wiz Code bietet natives SCA und identifiziert Schwachstellen und Lizenzrisiken über dependencies in Repositories, Images und laufenden workloads hinweg. Funde erhalten graphbasierten Kontext: eine einheitliche Sicht darauf, wie Cloud-Ressourcen, Berechtigungen, Netzwerkpfade und Datenflüsse zusammenhängen. Hinzu kommen runtime-Signale, die statt theoretischer Risiko-Scores die tatsächliche Ausnutzbarkeit in der jeweiligen Umgebung abbilden.
Die runtime-Erreichbarkeitsanalyse mithilfe des Wiz Sensor validiert, welche verwundbaren Bibliotheken in Produktions-workloads tatsächlich geladen und ausgeführt werden. So trennt sie Schwachstellen, die nur im Code vorhanden sind, von jenen, die über Ausführungspfade aktiv erreichbar sind.
code-to-cloud-Nachvollziehbarkeit: Diese Funktion bildet SCA-Funde von Quell-Repositories bis zu Produktions-workloads ab und macht sichtbar, wer für die Behebung verantwortlich ist.
attack path analysis: Diese Analyse verknüpft Schwachstellen in dependencies mit der Erreichbarkeit über das Netzwerk, den Berechtigungen und dem Zugriff auf sensible Daten und zeigt so die vollständige Auswirkung.
WizOS: Abgesicherte base images mit nahezu null CVEs reduzieren vererbte Schwachstellen von Grund auf. Sie senken das Rauschen im SCA, indem sie Dutzende CVEs auf Betriebssystemebene beseitigen, bevor überhaupt Anwendungscode hinzukommt. Das verringert den Aufwand bei der Behebung und lässt Teams sich auf Risiken der Anwendungsebene konzentrieren, die sie tatsächlich kontrollieren.
Einheitliche Richtlinien-Engine: Konsistente security guardrails greifen in IDEs, Pull Requests, CI/CD-Pipelines, container registries und der cloud runtime. So gelangen riskante dependencies nicht in den Umlauf, und über alle Phasen hinweg gelten dieselben Richtliniendefinitionen. Eine einzige Richtlinie blockiert beispielsweise jedes Paket mit einem KEV-gelisteten CVE zur Commit-, Build- und Deployment-Zeit.
Wiz macht aus SCA-Funden priorisierte Maßnahmen, mit vollständigem code-to-cloud-Kontext. So beheben Teams ausnutzbare Probleme schneller, ohne die Auslieferung zu bremsen. Sicherheitsteams erhalten eine klare Risikopriorisierung, und Entwicklungsteams bekommen umsetzbare Empfehlungen zur Behebung direkt in ihren Workflows.
Sehen Sie, wie kontextbasiertes SCA in Ihrer Umgebung funktioniert – buchen Sie eine Demo und verbinden Sie ein Repository und eine container registry in wenigen Minuten. So erhalten Sie priorisierte Funde mit vollständigem Cloud-Kontext, ganz ohne Agents.