Was ist
Software Composition Analysis (SCA)?

Übersicht

Es gibt viele Arten von Risiken und Sicherheitslücken, und Schwachstellen können an vielen Stellen im Software-Lebenszyklus (SDLC) auftreten. So können etwa schlechte Programmier-Praktiken Risiken in den Quellcode von Anwendungen einführen, oder unsichere Abhängigkeiten in Pakete vor der Bereitstellung einbezogen werden. Neben solchen potentiellen Sicherheitsrisiken könnte es durch unsachgemäße  Nutzung des Codes Dritter auch zu Lizenzverletzungen kommen, die dem Unternehmen Klagen einbringen und dem Ruf schaden.

Eine Methode zur Minimierung solcher Risiken ist die Implementierung von Software Composition Analysis (SCA) Scans zur Erkennung potenzieller Bedrohungen in jeder Phase des SDLC. Schauen wir uns genauer an, was SCA bedeutet und wie sie funktioniert, um ihre Vorteile und Limitierungen besser zu verstehen und um zu erfahren, wie SCA-Tools eingesetzt werden sollten, um einen möglichst durchgängigen Schutz vor der ständig wachsenden Zahl von Angriffen und Schwachstellen zu erreichen.

SCA-Tools können viele Arten von Schwachstellen aufspüren, insbesondere unsichere Abhängigkeiten in Open-Source-Bibliotheken:

• Verwundbare Bibliotheken: Dies sind Libraries, die bekannte Schwachstellen enthalten, die von Angreifern ausgenutzt werden können.
• Nicht mehr gepflegte Bibliotheken: Libraries, die von ihren Entwicklern nicht mehr aktiv gepflegt werden, können mit der Zeit unsicher werden.
• Bösartige Bibliotheken: Dies sind Libraries, die absichtlich erstellt oder verändert wurden, um böswilligen Code zu enthalten. Angreifer können diese Bibliotheken über öffentliche Repositories verbreiten, in der Hoffnung, dass Entwickler sie unwissentlich in ihre Anwendungen einbauen, um dann sensible Daten zu stehlen, Hintertüren zu installieren oder die Integrität der Anwendung zu gefährden.

Darüber hinaus können SCA-Tools feststellen, ob Code aus einer Drittquelle in eine Anwendung eingeschleust wurde. Die Erkennung solcher Code-Schnipsel ist nicht nur wichtig, weil sie Sicherheitslücken enthalten könnten, sondern auch, weil der Code möglicherweise Lizenzbestimmungen unterliegt, gegen die das Unternehmen verstößt, wenn die Entwickler den Code einfach kopieren und einfügen, ohne sich über Lizenzbedingungen den Kopf zu zerbrechen.

Allerdings ist zu beachten, dass ein einzelner SCA-Scan nicht unbedingt in der Lage ist, Sicherheitsprobleme in allen Schwachstellenkategorien zu erkennen. Die Ergebnisse eines Scans hängen davon ab, ob man den Quellcode der Anwendung, die Binärdateien der Anwendung, die Anwendungspakete oder die Konfigurationsdateien scannt.

Daher empfiehlt es sich, Ihre Anwendungen in jeder Phase des Entwicklung und Produktion zu scannen, um sicherzustellen, dass alle Instanzen einer konkreten Sicherheitslücke erkannt werden. Weil unsichere Abhängigkeiten beispielsweise sowohl im Quellcode als auch in den Konfigurationsdaten definiert sein können, ist es unerlässlich, sowohl den Quellcode als auch das Release-Paket zu scannen, um alle potenziellen abhängigkeitsbezogenen Schwachstellen zu erkennen.

Zwei Beispiele für SCA aus der Praxis

Um zu veranschaulichen, was Software Composition Analysis in der Praxis bedeutet, schauen wir uns zwei konkrete Beispiele für die Suche nach Risiken und Schwachstellen via SCA an.

Unsicheres Modul im Quellcode

Angenommen, Sie haben eine Python-Anwendung, die (weil sie eine Legacy-Anwendung ist) von einer bestimmten Version eines externen Python-Moduls abhängt. Das Modul heißt Insecure, und Ihre Anwendung importiert eine bestimmte Version davon mit folgendem Quellcode:

import pkg_resources
pkg_resources.require("Insecure==1.2.3")
import insecure

In diesem Szenario ist die Version 1.2.3 des Insecure-Moduls als anfällig bekannt. Durch das Scannen des Quellcodes kann ein SCA-Tool feststellen, dass Ihre Anwendung in diesem Fall ein unsicheres Modul importiert. Ihre Entwickler können jetzt die Anwendung aktualisieren, um eine sichere Version des Moduls zu verwenden.

In der Zwischenzeit kann Ihr IT-Team das Problem eventuell entschärfen, indem es die Voraussetzungen blockiert, unter denen die Sicherheitslücke im unsicheren Modul in der Laufzeitumgebung Ihrer Anwendung ausgenutzt werden kann. (Wenn für das Ausnutzen der Schwachstelle beispielsweise ein bestimmter Port geöffnet sein muss, könnte das IT-Team sicherstellen, dass dieser Port gesperrt ist).

Unsichere Abhängigkeit eines Pakets

Als zweites Beispiel nehmen wir ein Debian-Paket (ein Dateiformat, das für die Installation von Software unter Ubuntu und anderen Linux-Distributionen verwendet wird), das eine Konfigurationsdatei im folgenden Verzeichnis enthält:

packagename-1.0/debian/control

Der Inhalt der Datei lautet:

Source: packagename
Section: unknown
Priority: optional
Maintainer: "Firstname Lastname" <email.address@example.org>
Build-Depends: ssl-cert (= 1.0.39)
Standard-Version: 4.5.1
Homepage: <insert the upstream URL, if relevant>
Requires-Root: no

Unter anderem definiert diese Datei die Version 1.0.39 des Pakets ssl-cert als Abhängigkeit. Das heißt, dass bei der Installation des Hauptpakets auf einem Linux-Server auch die Version 1.0.39 des Pakets ssl-cert installiert wird. Weil das ssl-cert Version 1.0.39 eine bekannte Schwachstelle enthält, wird durch die Installation des Pakets eine ausnutzbare Bedrohung in die Hostumgebung eingeführt.

Ein SCA- Tool, das das Control-File für dieses Paket analysiert, würde diese unsichere Abhängigkeit aber erkennen und sie entsprechend kennzeichnen, damit die Developer dieses Risiko eindämmen können.

Die Vorteile von Software Composition Analysis

Software Composition Analysis ist nicht die einzige Möglichkeit, Risiken und Schwachstellen in Software-Quellcode oder -Paketen zu entdecken. Vor der Entwicklung dieser Technologie mussten Entwickler ihre Anwendung in jeder Phase des Entwicklungszyklus manuell überprüfen, um Fehler oder unsichere Abhängigkeiten aufzuspüren. Dies war nicht nur Fehleranfällig sondern verlangsamte auch die Geschwindigkeit neuer Deployments.

Mittlerweile ist SCA ein zentrales Security Werkzeug im DevSecOps-Arsenal und bietet eine ganze Reihe an Vorteilen:

Automatisierter Prozess

Am offensichtlichsten ist wahrscheinlich, dass SCA-Tools Risiken automatisiert aufspüren können, so dass Entwicklerteams viel weniger Zeit in die Überprüfung stecken müssen und diese in die Verbesserung und Absicherung der Software-Lieferkette investieren können.

Frühzeitige Erkennung von Risiken

Die Möglichkeit, die Erkennung von Schwachstellen und Risiken zu automatisieren, bedeutet auch, dass Sie schon sehr früh im Lebenszyklus der Software mit dem Scannen starten können. So können Sie Probleme in einem frühzeitigen Stadium erkennen, wenn sie noch schnell und einfach zu beheben sind.

Wenn Sie zum Beispiel eine unsichere Abhängigkeit schon entdecken, während Sie noch den Quellcode für Ihre Anwendung schreiben, können Sie Ihren Quellcode einfach auf den neuesten Stand bringen, um das Problem zu lösen. Entdecken Sie das Problem dagegen erst kurz vor dem Einsatz im Produktivbetrieb, müssen Sie zum Quellcode zurückgehen, die Anwendung neu kompilieren und sie erneut testen, was wiederum wertvolle Zeit und Ressourcen frisst.

Übersicht über Abhängigkeiten

Abhängigkeiten sind eine gute Sache. Sie ermöglichen es Entwicklern, Funktionen in Anwendungen zu integrieren, ohne den gesamten Code für die jeweilige Funktion von Grund auf neu schreiben zu müssen.

Anwendungen, die sich stark auf Abhängigkeiten stützen, können jedoch mit Dutzenden verschiedener Module, Bibliotheken oder anderer Abhängigkeiten enden, die sie benötigen, um überhaupt zu laufen. Da diese Abhängigkeiten alle an verschiedenen Stellen definiert sein können (z. B. im Quellcode, in den Konfigurationsdateien von Paketen oder Deployment-Tools), kann es schwierig werden, den Überblick über all diese Abhängigkeiten zu behalten.

Mit SCA-Tools lässt sich dieses Problem lösen, weil sie Ihnen einen Gesamtüberblick darüber verschaffen, welche Abhängigkeiten Ihre Anwendungen haben, welche spezifischen Versionen der einzelnen Abhängigkeiten die Anwendung braucht und ob diese Versionen als sicher gelten.

Über SCA-Tools lässt sich daher auch schnell und einfach eine SBOM (Software Bill of Materials) erstellen.

Einhaltung von Lizenzbedingungen

Doch SCA-Tools können nicht nur auf Sicherheitsrisiken hin prüfen, sondern Entwickler auch warnen, wenn sie Drittanbieter-Code auf eine Art und Weise in eine Codebasis aufnehmen, die gegen Lizenzbestimmungen verstößt.

Ein SCA-Tool weist dann auf die Open-Source-Lizenz hin und gibt , so dass die Entwickler sicherstellen können, dass sie den Code auf lizenzkonforme Weise vertreiben – und dass sie eine etwaige Haftung aufgrund von Lizenzverletzungen vermeiden.

Ein SCA-Tool weist dann auf die entsprechende Open-Source-Lizenz hin und gibt Entwicklern die Möglichkeit, den Code auf lizenzkonforme Weise zu nutzen und so eine etwaige Haftung aufgrund von Lizenzverletzungen zu vermeiden.

Die Grenzen von Software-Kompositionsanalyse

SCA ist ein mächtiges Instrument, das Sie in Ihrem Werkzeugkasten haben sollten, aber es ist wichtig zu wissen, dass SCA-Lösungen nicht alle Arten von Risiken und Schwachstellen erkennen können.

Anwendungsbereich

Im Wesentlichen können SCA-Tools nur Risiken erkennen, die durch Open-Source-Code oder entsprechende Abhängigkeiten entstehen. Sie können keine Sicherheitslücken aufzeigen, die durch proprietäre Abhängigkeiten verursacht werden, weil diese Abhängigkeiten nicht der öffentlichen Überwachung unterliegen und die damit verbundenen Sicherheitslücken daher normalerweise auch nicht in öffentlichen Datenbanken auftauchen.

Darüber hinaus können SCA-Tools zwar manche Risiken erkennen, die Developer durch schlechte Programmier-Praktiken in ihrem Code einführen, aber einige dieser Risiken werden vielleicht nicht erkannt. Weil es unzählige Wege gibt, Quellcode zu schreiben, ist es unmöglich, jede potenzielle Abweichung von sicheren Programmierverfahren zu erkennen.

Externe Konfigurationsdateien

Eine letzte große Einschränkung von SCA Lösungen besteht darin, dass die Scans  zwar bestimmte Konfigurationsdateien innerhalb einer Anwendung oder eines Pakets scannen können, aber keine Sicherheitsrisiken erkennen können, die in Konfigurationsdaten außerhalb der Anwendung oder des Pakets enthalten sind.  Wenn Sie beispielsweise unsichere IAM-Settings (Identity Access Management) in der Cloud-Umgebung konfiguriert haben, in der Sie Ihre Anwendung bereitstellen, wird Ihr SCA-Tool dieses Risiko nicht erkennen können. Dazu solche Schwachstellen zu finden, brauchen Sie IaC-Scanner, wie sie in Tools wie JFrog Advanced Security, IDE Plugins oder CSPM-Tools verfügbar sind.

Alarm Fatigue

Wie bei vielen Sicherheitstools führen SCA-Scans oft zu einer großen Anzahl von Warnungen. Je komplexer das Projekt und je höher die Anzahl der Abhängigkeiten, desto höher auch die Anzahl irrelevanter Warnungen zu Sicherheitslücken, die in der Praxis gar nicht ausnutzbar sind. Das kann DevSecOps-Teams schnell überfordern und dazu führen, dass Warnungen ignoriert werden.

Sie müssen daher einen Prozess finden, potenzielle Schwachstellen zu priorisieren und auf Warnungen zu reagieren, die eine ernsthafte Bedrohung darstellen, während sie den Rest außer Acht lassen. Je besser das SCA-Tool, desto geringer die Anzahl der False Positives.

Wie man Software Composition Scanning effektiv nutzt

Da die Ergebnisse von SCA-Scans von der Art der gescannten Komponenten abhängen, ist es am effektivsten, SCA in mehreren Phasen des Lebenszyklus einzusetzen:

Starten Sie zunächst mit einem Scan des Quellcodes zum Beginn Ihrer Pipeline. Scannen Sie anschließend die Binärdateien, die während des Build-Prozesses erstellt werden. In der dritten Phase sollten Sie die Pakete und Container scannen, in denen Ihre Binärdateien zur Distribution gespeichert sind.

Je konsequenter Sie SCA-Scans in den Lebenszyklus integrieren, desto höher sind Ihre Chancen, Sicherheits- und Lizenzkonformitätsprobleme zu erkennen und zu beheben, bevor sie zu schwerwiegenden Unterbrechungen und finanziellen Verlusten führen.

Trends hinsichtlich SCA

Die kontinuierliche Weiterentwicklung von Entwicklungsprozessen und die vermehrte Nutzung von Open-Source-Komponenten haben auch einen erheblichen Einfluss darauf, wie Software Composition Analyse sich zukünftig entwickelt. Die folgenden Trends zeichnen sich ab:

Erweiterte Funktionalitäten

1. Integration mit DevOps-Plattformen – Dies ermöglicht das automatische Scannen von Open-Source-Komponenten als Teil des Entwicklungsprozesses und stellt sicher, dass Schwachstellen so früh wie möglich im SDLC erkannt und behoben werden.
2. KI und maschinelles Lernen – Die Integration solcher Algorithmen in SCA-Tools könnte die Treffergenauigkeit verbessern und eine fundiertere Schwachstellenanalyse einschließlich Priorisierung, potenzieller Auswirkungen und vorgeschlagener Lösungen ermöglichen.
3. Verbesserte Compliance und Governance – Da immer neue Branchen- und Gesetzesvorgaben auftauchen, bekommen SCA-Tools ausgeklügeltere Funktionen für das Richtlinien- und Lizenzmanagement hinzu, um die Einhaltung interner Richtlinien und externer Vorschriften zu gewährleisten.
4. Erweiterung von Schwachstellen-Datenbanken – Vulnerability-Datenbanken bilden die Grundlage für SCA-Schwachstellenerkennung. Durch eine Erweiterung sowohl, was den Umfang als auch Genauigkeit angeht, können detaillierte Informationen über Kontext, Ausnutzbarkeit und Abhilfemaßnahmen für veröffentlichte CVEs in SCA-Tools einfließen.
5. Unterstützung weiterer Sprachen und Frameworks – Angesichts der Verbreitung neuer Programmiersprachen und Frameworks müssen SCA-Tools ihre Sprachunterstützung erweitern, um weiterhin als umfassende Lösung für Security Teams zu funktionieren.
6. Reporting und Visualisierung – Diese Funktionen werden immer wichtiger, da Unternehmen Ihre Effizienz hinsichtlich Sicherheitsprozessen weiter steigern müssen. Daher werden interaktive Dashboards, Echtzeit-Reporting und die Integration in führende DevSecOps-Plattformen wichtiger.

Konsolidierung von Einzellösungen

Neben diesen Trends gibt es die Entwicklung hin zur Konsolidierung von Einzellösungen. Statt eine Vielzahl unterschiedlicher Sicherheitstools mehrerer Anbietern zu nutzen, die womöglich auch widersprüchliche Ergebnisse ausspucken, wenden sich Unternehmen zu ganzheitlichen End-to-End-Lösungen.

Diese Konsolidierung von Sicherheitstools führt zu umfassenderer Sicherheit und effizienteren Abläufen. So beinhaltet eine umfassendes Vulnerability Scanning nicht nur SCA, sondern auch SAST- und DAST-Scanning.

JFrog’s SCA Lösung

JFrogs Ansatz zur Software Composition Analysis (SCA) basiert auf der Fähigkeit der JFrog Plattform, eine vollständige Rückverfolgbarkeit und Provenienz für alle Komponenten der  Software-Lieferkette zu bieten.
JFrog Artifactory, das zentrale Repository für alle Software-Artefakte, erfasst umfangreiche und detaillierte Metadaten für jede Komponente in der Plattform und macht sie vollständig rückverfolgbar. Dies ermöglicht es Unternehmen, alle transitiven Abhängigkeiten in Komponenten von Drittanbietern zu identifizieren und die erforderlichen Daten automatisch oder bei Bedarf in eine konforme Software Bill of Materials (SBOM) zu exportieren.

Die Sicherheitslösung von JFrog ist nativ in Artifactory integriert und ermöglicht ein schnelles und effizientes Scannen und Abhilfe-Maßnahmen im Kontext des aktuellen Software Inventars.
Dank JFrogs Contextual Analysis sparen DevSecOps-Teams wertvolle Zeit und können kritischste Schwachstellen priorisieren. Und zwar basierend auf ihrer Anwendbarkeit innerhalb der Umgebung, nicht nur aufgrund ihres CVSS-Score.

JFrog Advanced Security erweitert diese Features durch die Erkenntnisse des JFrog Security Research Team, was tiefe Einblicke in Risiken und Probleme, Auswirkungen auf Ihre Software-Applikation und konkrete Ratschläge zur Behebung liefert. Die JFrog-Plattform unterstützt DevSecOps bei Ihren Aufgaben mit priorisierten, kontextbezogenen Abhilfemaßnahmen.

Wenn Sie die JFrog Plattform selbst erleben möchten, vereinbaren Sie eine Demo, machen Sie eine Tour oder starten Sie jetzt mit einer kostenlosen Testversion durch.