Was ist Software Composition Analysis (SCA)?
Bei Software Composition Analysis (SCA) werden die von einer Anwendung verwendeten Open-Source-Pakete im Detail analysiert. SCA deckt die in Abhängigkeiten enthaltenen Sicherheitslücken und Lizenzen zur Risiko- und Compliancebewertung auf und kann eine Softwarestückliste (SBOM) aller Ressourcen für interne Stakeholder und externe Kunden erstellen.
Was ist Software Composition Analysis?
Durch Software Composition Analysis können Entwickler Open-Source-Pakete sicher nutzen, ohne ihre Unternehmen damit unnötigen Sicherheitslücken, rechtlichen Schwierigkeiten oder Complianceproblemen auszusetzen.
Open-Source-Komponenten sind in der Softwareentwicklung heute allgegenwärtig: Ein Großteil der Codebasen moderner Anwendungen besteht aus solchen Paketen. Entwickler können dadurch schneller arbeiten, denn sie müssen Code nicht replizieren, der frei verfügbar ist und von der Community geprüft wurde. Dieser Ansatz bringt jedoch auch eigene Risiken mit sich.
Welche Risiken sind mit der Verwendung von Open-Source-Komponenten verbunden?
Entwickler, die Container-Images mit diesen Komponenten erstellen, müssen sich der Sicherheitsprobleme bewusst sein, die aus bekannten Sicherheitslücken in den Paketen resultieren. Auch die Complianceanforderungen, die sich aus den Softwarelizenzen ergeben, sind zu berücksichtigen und zu erfüllen.
Die Community findet und patcht Sicherheitslücken häufig, doch es ist an den Entwicklern, ihren Code zu aktualisieren. Wird eine Sicherheitslücke gefunden, dauert es nicht lange, bis ein Exploit veröffentlicht wird. Damit tut sich ein Einfallstor auf, das auch technisch weniger versierte Angreifer ausnutzen können.
Das Problem verschärft sich dadurch, dass ein Großteil der Sicherheitslücken in Software nicht in den direkt genutzten oder Root-Paketen steckt, sondern in von diesen Open-Source-Paketen genutzten Paketen und somit unter mehreren Schichten komplexer Abhängigkeiten verborgen sein kann. Es reicht also nicht in jedem Fall aus, die verwendeten Root-Pakete zu korrigieren, um die genutzten Bibliotheken zu schützen.
Zudem gibt es Dutzende Open-Source-Lizenzen mit verschiedensten Regeln. Manche erfordern beispielsweise die Namensnennung, während bei anderen auch der Quellcode für die Anwendung, die die Komponente nutzt, veröffentlicht werden muss. Es kann also schwierig sein, den Überblick über alle Lizenzen und die zugehörigen Regeln zu behalten.
Software Composition Analysis spürt Risiken in Open-Source-Paketen auf
SCA-Tools ermitteln sämtliche Open-Source-Pakete in einer Anwendung und alle bekannten Sicherheitslücken dieser Pakete. So erfahren Entwickler, ob Probleme in ihrem Code stecken, und können diese beheben, bevor sie ausgenutzt werden. Eine gute Software Composition Analysis nimmt neben den Paketmanagern auch die Infrastructure-as-Code (IaC)- und Kubernetes-Manifeste unter die Lupe und ruft Images ab, um Sicherheitslücken in ihnen ausfindig zu machen.
SCA-Tools mit Verbindungen zu IaC-Vorlagen und unbegrenzter Abhängigkeitsprüfung sorgen dafür, dass keine Sicherheitslücken unbemerkt und ausnutzbar bleiben.
Mit diesen Tools für die Analyse der Softwarezusammensetzung lässt sich auch eine Softwarestückliste (SBOM oder Software BOM) generieren, die alle von einer Anwendung genutzten Open-Source-Komponenten enthält. Die SBOM führt Details zur Paketversion sowie bekannte Sicherheitslücken und Lizenzen für jede verwendete Komponente auf. Für Python enthält die BOM beispielsweise alle Pakete in Import-Anweisungen wie httplib2, zusammen mit der Versionsnummer, erkannten Sicherheitslücken und Lizenzen für jedes Paket.
SCA-Programme sollten die Zusammenarbeit zwischen Stakeholdern wie Entwicklungs-, DevOps-, Sicherheits- und Complianceteams ermöglichen. Oft werden diese Programme verwendet, um Alarme zu generieren und/oder zu verhindern, dass Software mit Open-Source-Komponenten, die unternehmensinterne Compliancevorgaben zur Risikoeindämmung verletzen, in Repositorys aufgenommen wird. Entscheidungen darüber, welcher Schweregrad für Sicherheitslücken und Lizenztypen akzeptabel ist, sollten von allen betroffenen Parteien gemeinsam getroffen werden.
SCA-Verwendung in Entwicklungsprozessen
Ein guter SCA-Prozess ist in jede Entwicklungsphase integriert. Beginnend bei lokalen Umgebungen, müssen Entwickler während der Codeerstellung prüfen können, ob ihr Code Sicherheitslücken enthält und die Lizenzvorgaben erfüllt.
Mithilfe von Plug-ins für integrierte Entwicklungsumgebungen (IDEs) zeigen SCA-Tools Sicherheitslücken auf, wenn Pakete hinzugefügt werden. Bevor Code in ein Repository geladen wird, sollten Prüfungen und Kommentare für automatisierte Pull-Anforderungen die Entwickler darauf hinweisen, wenn damit Probleme eingeschleppt werden, und Code blockieren, der den Anforderungen nicht entspricht.
Auch bei der Bereitstellung sollte Software blockiert werden, die zuvor festgelegte Kategorien an Sicherheitslücken oder Lizenztypen enthält. Die Sicherheitsteams sollten zudem umfassenden Einblick in das Sicherheitsniveau der Komponenten in ihrer Umgebung haben.
Software Composition Analysis erweitert die Abdeckung vom Code bis in die Cloud und von der Infrastruktur bis auf die Anwendungsebenen, um Schwachstellen im gesamten Entwicklungszyklus zu verfolgen.
In allen Bereichen benötigen Entwickler Informationen über Risiken, für die sie durch die Pakete anfällig werden. Sicherheitslücken müssen bewertet und priorisiert werden (z. B. aufgrund von CVE-Scores und der seit der Meldung der Schwachstelle verstrichenen Zeit), damit kritische Schwachstellen mit Auswirkungen auf besonders wichtige Infrastrukturen (wie private VPCs) vorrangig behoben werden können. Lizenzen werden idealerweise in verschiedene Gruppen eingeteilt: diejenigen, die erlaubt sind, aber weitere Details wie die Namensnennung erfordern, und diejenigen, die gemäß den Unternehmensrichtlinien nicht zulässig sind, z. B. „Copyleft“-Lizenzen.
Die Vorteile von Software Composition Analysis
Ihre Teams sollten sich des Sicherheitsniveaus ihrer Anwendungsumgebungen unbedingt bewusst sein. Software Composition Analysis kann zur Minimierung der Risiken, die mit der Verwendung von Open-Source-Komponenten in Anwendungen verbunden sind, beitragen, indem sie die verantwortlichen Teams frühzeitig und regelmäßig auf Sicherheitslücken und einzuhaltende Lizenzvorgaben hinweist. Auch wenn eine Patchrate von 100 % unwahrscheinlich ist, kommt es dem Sicherheitsniveau zugute, wenn sich das Risiko einschätzen lässt und die Kosten für das Beheben einer Sicherheitslücke abgewogen werden können.
Weitere Informationen über die Sicherheit in modernen Entwicklungsprozessen finden Sie hier: Was ist DevSecOps?