Was ist Analyse der Softwarezusammensetzung (SCA)?

SCA-Tools scannen den Quellcode der Software, erfassen ihn in einer Datenbank, vergleichen ihn mit bekannten Datenbanken für Schwachstellen, suchen nach Updates oder Lizenzproblemen und erstellen dann einen Bericht. 

Obwohl die Analyse der Softwarezusammensetzung alle Arten von Softwareelementen scannen kann, einschließlich proprietärer Komponenten und Container-Images, wird sie am häufigsten zur Analyse von Open-Source-Bibliotheken verwendet. Open-Source-Komponenten sind in nahezu jeder modernen Codebasis in gewissem Umfang enthalten, und da Schwachstellen in ihrem Code öffentlich bekannt sind, ist es besonders wichtig, Open-Source-Software aktuell und transparent zu halten.

SCA-Tools verwalten die Risiken von Schwachstellen durch Softwarekomponenten unbekannter Herkunft, Kompatibilitätsprobleme zwischen verschiedenen Open-Source-Lizenzen sowie unvollständige oder unzureichende Dokumentation oder Unterstützung für Open-Source-Bibliotheken.  

Die Analyse der Softwarezusammensetzung ist Teil der cloudnativen DevOps-Pipeline, die den Softwareentwicklungsprozess mit dem IT-Betrieb integriert. SCA unterstützt auch den Sicherheitsstatus eines Unternehmens als Teil der DevSecOps-Pipeline, die Sicherheit in Entwicklung und Betrieb integriert. SCA-Tools können in einer integrierten Entwicklungsumgebung (IDE) bereitgestellt werden und ermöglichen die Codeanalyse in Echtzeit während des Entwicklungsprozesses.

SCA unterscheidet sich von anderen Formen des Schwachstellen-Scannings wie statische Anwendungssicherheitstests (SAST), dynamische Tests der Anwendungssicherheit (DAST)dem Scannen von Abhängigkeiten.

IT-Teams verwenden oft SCA-Tools, um eine Software-Stückliste (SBOM) zu erstellen. Die SBOM listet alle Komponenten, Bibliotheken und Module eines Softwareprodukts in einem maschinenlesbaren Format auf, um die Einhaltung von Vorschriften und die Sicherheit der Lieferkette zu gewährleisten. SBOMs können zudem SCA-Scanning-Richtlinien weiter optimieren.

Laut Umfragedaten der International Data Corporation (IDC) nutzten im Jahr 2024 93 % der Unternehmen mit mindestens 100 Mitarbeitern Open-Source-Software, was den weit verbreiteten Bedarf an SCA-Lösungen unterstreicht.¹

SCA funktioniert, indem Quellcode erfasst, mit Schwachstellendatenbanken verglichen, die Codebasis auf potenzielle Compliance-Probleme analysiert, Fehlalarme entfernt und ein Bericht für die Cybersicherheits- und Entwicklungsteams erstellt wird. 

SCA-Tools scannen und analysieren aktiv Code während der Entwicklung als Teil der CI/CD-Pipeline (Continuous Integration und Continuous Delivery) über den gesamten Entwicklungslebenszyklus hinweg, wobei der Fokus primär auf Open-Source-Komponenten und Third-Party-Abhängigkeiten liegt.

Zu diesem Zweck erfassen SCA-Tools zunächst die grundlegenden Elemente der gesamten Software in der IT-Umgebung, einschließlich ihrer Komponenten, Frameworks, Bibliotheken, Container-Images, Module und Abhängigkeiten. Die beiden wichtigsten Formen des SCA-Scannings sind: 

• Statisches Scannen, auch Manifest-Scannen genannt, liest Konfigurations- und Metadatendateien, um die darin explizit beschriebenen Elemente zu finden.

• Dynamisches oder Laufzeit-Scannen, bei dem Bibliotheken während der Ausführung in Echtzeit durch Scannen des Binärcodes identifiziert werden. 

Beide Arten von Scans haben Vor- und Nachteile. Ein statischer Scan kann Schwachstellen von Drittanbieter-Komponenten im Quellcode enthalten, die nicht in der Laufzeitumgebung bereitgestellt werden, was zu falsch positiven Ergebnissen führt. Ein dynamischer Scan hingegen ist vielleicht nie komplett vollständig, da nicht alle Codeelemente in der Laufzeitumgebung ausgeführt werden. Viele Unternehmen verwenden eine Kombination aus beidem.

Sobald ein SCA-Tool die Codeerfassung abgeschlossen hat, erstellt es eine Software-Stückliste (SBOM) und vergleicht die Komponenten der SBOM mit Datenbanken, die häufige Schwachstellen und moderne Software-Sicherheitsrisiken beschreiben.

Sicherheitsteams vergleichen die SBOM sowohl mit proprietären Datenbanken bekannter Schwachstellen als auch mit öffentlichen Datenbanken wie der National Vulnerability Database (NVD) oder der Liste Gängiger Schwachstellen und Gefährdungen (CVEs) . Sobald potenzielle Schwachstellen markiert sind, weist das SCA-Tool jedem einen Bedrohungswert zu (oft mit dem Scoring-System für gängige Schwachstellen oder CVSS), der es dem Cybersicherheits-Team ermöglicht, die Sanierung zu priorisieren.

Einige Sicherheitstools automatisieren das Schwachstellenmanagement, indem sie den entsprechenden Patch oder das Update als Teil der CI/CD-Pipeline anwenden. Sicherheitsteams überwachen diesen Prozess in der Regel, um sicherzustellen, dass die vorgenommenen Änderungen keine Auswirkungen auf bestehende Abhängigkeiten oder Funktionen haben.

Die SCA-Tools prüfen außerdem, ob die SBOM mit den Unternehmensrichtlinien und Gesetzen zur Softwarelizenzierung abgeglichen ist, um die Einhaltung der Vorschriften sicherzustellen.

Die Open Source Initiative listet über 100 genehmigte Open-Source-Lizenzen auf, von denen einige die Erstellung proprietärer Produkte aus Open-Source-Code erlauben. Allerdings sind nicht alle von ihnen kompatibel, d. h. Unternehmen sind dafür verantwortlich, sicherzustellen, dass ihre Produkte den Anforderungen entsprechen.

SCA-Lösungen können überprüfen, ob alle Open-Source-Programme die erforderliche Quellenangabe enthalten oder ob Elemente, die dem „Copyleft“ unterliegen, das ihre Verwendung in proprietärer, urheberrechtlich geschützter Software untersagt, nicht in die Entwicklung dieser Software einfließen. 

Die Analyse der Softwarezusammensetzung kann auch Abhängigkeiten zwischen Projektkomponenten aufdecken, eine wichtige Quelle potenzieller Schwachstellen.

SCA-Tools können sowohl direkte Abhängigkeiten – bei denen Softwarekomponenten auf Codeebene direkt voneinander verwendet werden – als auch transitive Abhängigkeiten erkennen. Eine transitive Abhängigkeit entsteht, wenn ein Softwarebaustein indirekt von einer Softwarekomponente abhängig wird, von der eine seiner direkten Abhängigkeiten wiederum abhängig ist. Beispiel: Komponente A ist von Komponente B abhängig, welche wiederum von Komponente C abhängig ist. In diesem Fall ist Komponente A transitiv von Komponente C abhängig.

SCA-Tools müssen feststellen, welche Abhängigkeiten zu Schwachstellen führen und welche nicht, um die Anzahl falscher Warnmeldungen zu reduzieren. Dazu bewerten sie die Software-Lieferkette und stellen fest, ob eine Schwachstelle im Code „erreichbar“ ist – das heißt, ob sie in einer Laufzeitumgebung unter den aktuellen Konfigurationsbedingungen des Netzwerks aufgerufen wird. 

Die Ergebnisse der Analyse der Softwarezusammensetzung werden anschließend in einem Bericht zusammengefasst und häufig in einem proprietären Dashboard, als Rohdaten (z. B. in Form einer JSON-Datei), als neue SBOM oder in einer Kombination aus allen drei Formaten dargestellt.

In den letzten Jahren haben die Entwickler Fortschritte bei der Reduzierung von Fehlalarmen in diesen Berichten erzielt.

• Die Methodenanalyse verfolgt die Aufrufpfade von Komponenten, um sicherzustellen, dass erkannte Schwachstellen erreichbar sind.

• Maschinelles Lernen und künstliche Intelligenz haben zur Identifizierung von Falschmeldungen beigetragen. Mit dem richtigen Training können die Modelle genau erkennen, ob eine Schwachstelle erreichbar ist oder nicht. Die Verarbeitung natürlicher Sprache wird auch zur Analyse von Commit-Meldungen aus Versionskontroll-Repositorys wie GitHub verwendet, um potenzielle Probleme zu erkennen, die im Code nicht identifizierbar sind. 

Einige SCA-Tools verfügen über Funktionen zur kontinuierlichen Überwachung und automatischen Behebung, wodurch diese Vorgehensweise noch stärker in den DevSecOps-Entwicklungsworkflow integriert wird. Die automatische Sanierung erfolgt in der Regel durch die Einreichung von Pull-Anfragen, die Entwickler dazu auffordern, Lizenzprobleme zu beheben oder neue Sicherheitspatches zu installieren.

Zu den Vorteilen von SCA zählen ein höheres Vertrauen in die Compliance- und Cybersicherheitsmaßnahmen eines Unternehmens sowie eine stärkere Automatisierung der IT-Workflows.

Indem SCA dazu beiträgt, dass alle Open-Source-Komponenten im IT-Ökosystem gemäß den jeweiligen Lizenz- und Compliance-Anforderungen genutzt werden, kann SCA Unternehmen dabei unterstützen, rechtliche Risiken zu minimieren.

Die Erkennung von Netzwerk-Schwachstellen, die durch die Unvorhersehbarkeit von Open-Source-Softwarekomponenten entstehen, ist ein wesentlicher Bestandteil des IT-Risikomanagements. Durch mehr Transparenz in der Lieferkette für Open-Source-Software können Unternehmen die Vorteile der Anpassbarkeit und geringerer Kosten nutzen und gleichzeitig sicher sein, dass sie die damit verbundenen Sicherheitsrisiken reduziert haben.

Durch die Automatisierung großer Teile der Schwachstellen-, Abhängigkeits- und Compliance-Überwachung entlasten SCA-Lösungen die IT-Teams und ermöglichen ihnen, andere Aufgaben durchzuführen. Diese umfassende Automatisierung trägt auch zur Stärkung der DevOps-Praktiken eines Unternehmens bei.

Zu den Herausforderungen der Analyse der Softwarezusammensetzung gehören unter anderem die mangelnde Vollständigkeit bei der Erfassung von Schwachstellen, die Begrenzung von Fehlalarmen und die Beschränkung des Analyseumfangs.

Die Analyse der Softwarezusammensetzung unterscheidet sich von DAST und SAST, zwei weiteren Testmethoden zur Identifizierung von Schwachstellen in modernen Anwendungen. 

Während SCA IT-Teams eine umfassende Übersicht über Softwarekomponenten, Abhängigkeiten und Schwachstellen bietet, konzentrieren sich DAST und SAST auf die einzelnen Fehler in diesen Komponenten und der größeren Softwareanwendung, die sie darstellen, und decken diese auf.

Der Unterschied zwischen DAST und SAST ähnelt dem Unterschied zwischen statischem und dynamischem Scannen in SCA. Dynamische Tests der Anwendungssicherheit (DAST) bewerten Anwendungen in ihren Produktionsumgebungen, indem sie böswillige Benutzer und Cyberangriffe simulieren, um Sicherheitsprobleme zu identifizieren. Statische Tests der Anwendungssicherheit (SAST) untersuchen den Quellcode einer App, suchen nach Schwachstellen im Quellcode, während er geschrieben wird.  

Während sich SCA auf die Erfassung und Analyse der Komponenten einer bestimmten Software konzentriert, zielen DAST und SAST speziell darauf ab, diese Software auf Schwachstellen bei der Sicherheit zu testen, sei es zur Laufzeit im Falle von DAST oder im Quellcode im Falle von SAST. Beide werden häufig zusammen mit SCA angewendet, können aber auch unabhängig voneinander praktiziert werden. 

SCA unterscheidet sich von der Abhängigkeitszuordnung, dem Prozess der Identifizierung, des Verständnisses und der Visualisierung der Beziehungen zwischen Anwendungen, Systemen und Prozessen innerhalb des IT-Betriebs eines Unternehmens.

SCA-Tools bieten einen Überblick über die Abhängigkeiten der Komponenten und identifizieren potenzielle Schwachstellen, die daraus entstehen könnten, doch die Abhängigkeitszuordnung bezieht sich auf eine breitere Kategorie von Observability-Praktiken, die Abhängigkeiten in der gesamten IT-Umgebung identifizieren.

Die Abhängigkeitszuordnung kann sich auf Abhängigkeiten innerhalb und zwischen Anwendungen konzentrieren, aber sie kann auch größer angelegt sein und nach Abhängigkeiten in der Netzwerkinfrastruktur oder ganzen realen Systemen suchen, wie zum Beispiel einem intelligenten Stromnetz. Die Abhängigkeitszuordnung ist oft eine Komponente von SCA-Praktiken, kann aber auch unabhängig von SCA-Lösungen durchgeführt werden.