SBOM: Softwarestücklisten erfolgreich einsetzen

Die Herausforderungen bei Softwarestücklisten

Ab hier wird die Situation aber erheblich schwieriger, wenn es um den Einsatz von Log4j in dritt-, viert- oder gar fünftgradigen Abhängigkeiten geht. Würde ein IT-Sicherheitsteam wirklich herausfinden können, wenn eine im Unternehmen eingesetzte Bibliothek eine API (Application Programming Interface) aufruft, das in einem Framework läuft, das ein geteiltes Objekt nutzt, das wiederum mit einer statischen Library verlinkt ist, die anfällig gegen Log4Shell ist? Die Antwort auf diese Frage lautet wahrscheinlich nein. Außer es wurde ein erheblicher Zeitaufwand betrieben, um sich umfassend zu informieren. Aber wer ist dazu schon in der Lage?

Darüber hinaus müssen auch die Geschwindigkeit bei der Entwicklung von Software und die immer häufiger durchgeführten kleineren oder größeren Änderungen berücksichtigt werden. DevOps-Prozesse sowie die Einführung von CD/CD (Continous Integration, Continous Delivery) haben einen starken Einfluss darauf, wie schnell Software heutzutage programmiert und wie schnell sie auf dem Markt veröffentlicht wird. Jede neue Version und jedes neue Update kann die bisherigen Abhängigkeiten wieder über den Haufen werfen.

Deswegen kann jedes neue Release für Änderungen der in einer Software enthaltenen Komponenten und der mitgelieferten Packages sorgen. Auch das immer wieder bei Open-Source-Software zu hörende Mantra, eine Lösung so schnell wie möglich und so oft wie möglich zu veröffentlichen, hat zu einer deutlichen Beschleunigung vieler Release-Zyklen geführt. Jede dieser neuen Versionen bringt jedoch möglicherweise wichtige Änderungen für die bereits genutzten Abhängigkeiten und neue Inhalte mit sich.

Softwarestücklisten sind daher keine Tätigkeit frei nach dem Motto „Fire and Forget!“. Bestimmte Elemente müssen dabei sorgfältig durchgedacht und geplant werden. Das gilt ganz besonders, wenn es um den Einsatz von SBOMs in einer hoch skalierbaren Umgebung geht. Insbesondere sind davon Softwarehersteller betroffen, die SBOMs für ihre Kunden oder für Regulierungsbehörden erstellen, aber auch Firmen, die Softwarestücklisten einsetzen, um einen Überblick über die Lieferketten in den von ihnen eingesetzten Anwendungen zu erhalten.

Setzen Sie deshalb auf die im Folgenden beschriebenen drei Maßnahmen, wenn es um das Skalieren von SBOM-relevanten Prozessen geht.

1. Vorteile der Automatisierung zum Aktualisieren und Organisieren von SBOMs

Wenn es um das Erstellen von Softwarestücklisten geht, ist Automatisierung heutzutage unverzichtbar. Schon einzelne Software-Packages können äußerst kompliziert aufgebaut sein. Wie bereits erwähnt, haben die meisten Abhängigkeiten wiederum eigene Abhängigkeiten und immer so weiter. Selbst eine vermeintlich einfache Software kann Hunderte oder gar Tausende von Abhängigkeiten enthalten. Sie alle manuell zu organisieren ist eine echte Herkulesaufgabe.

Standards für Softwarestücklisten wie CycloneDX, Software Package Data Exchange (SPDX) oder vordefinierte Tags zur Identifizierung (Software Identification Tags) von Software setzen ebenfalls auf Automatisierung. Ihre Formate sind nicht nur maschinenlesbar, sie ermöglichen auch die Verschachtelung von Einträgen, um ihre Aufgabe zu erfüllen. In Situationen, in denen bereits automatisierte Prozesse vorhanden sind wie etwa als Teil der DevOps-Toolchain oder einer CD/CD-Pipeline sollten Sie daher einen zusätzlichen automatischen Schritt einführen. Ein Beispiel dafür ist der Einsatz eines speziellen SCA-Tools (Software Composition Analysis) jedes Mal, nachdem eine neue Build-Version erstellt wurde. Das hat den Vorteil, dass jede neue Build-Version eines Produkts automatisch zur Analyse der aktuell enthaltenen Abhängigkeiten genutzt wird.

2. Manuelle Reviews zur Verbesserung der Genauigkeit

Maßgeblich entscheidend für den Nutzen einer Softwarestückliste ist natürlich ihre Genauigkeit. Oft sind die durch ein SCA-Tool und andere Analysen erfassten Daten aber noch nicht ausreichend. Fremde Software, die von einem Programm benötigt wird, um ausgeführt zu werden, die aber selbst nicht Teil der Codebasis ist, kann mit diesen automatischen Tools nicht gefunden werden. Das wirkt sich negativ auf die Genauigkeit der Analysen aus.

Nehmen wir nur als Beispiel einen in Python programmierten Code, der für ein Framework wie Django erstellt wurde. Ein SCA-Tool oder auch ein Werkzeug zum Static Application Security Testing wird die enthaltenen spezifischen Bibliotheken und Module durchaus aufspüren, die von Python benötigt werden. Das gilt aber, abhängig vom genutzten Tool, möglicherweise nicht für Django selbst als ebenfalls wichtige Abhängigkeit. Sie sollten daher einen Plan für Situationen wie diese vorbereitet haben.

So könnten Sie beispielsweise eine für Menschen verständliche Zusatzinformation mitliefern, die als Ergänzung alle benötigten Hinweise auf weitere Komponenten enthält. Das ist vergleichbar mit dem allgemein einführenden Abschnitt in Sicherheitsdatenblättern oder Mitteilungen über die Gefährlichkeit bestimmter Stoffe. Auf diese Weise verfügen die zuständigen Teams über die Daten der automatisch erkannten Module, aber auch über Informationen über weniger offensichtliche Abhängigkeiten und Annahmen bezüglich der Nutzung einer Software, die das für Maschinen lesbare Dokument begleiten. Das ist nicht nur für den Leser, sondern auch später für die Security-Admins hilfreich, wenn und falls sich Annahmen oder die Nutzung ändern.

3. Softwarestücklisten in der Praxis umsetzbar und zugänglicher machen

Unternehmen, die Softwarestücklisten in ihrem Betrieb einsetzen, brauchen Informationen, die sowohl leicht zugänglich als auch in der Praxis umsetzbar sind. Viele von Anbietern bereitgestellten SBOMs wurden aber in letzter Zeit aus berechtigten Gründen kritisiert. Sie seien nicht nutzbar, außerdem würden sie zu sehr auf der Sicht der Hersteller basieren. Manche Anbieter seien zudem nicht gewillt, ausreichend Informationen mit ihren Kunden zu teilen. Die Liste der Kritikpunkte ist lang und wird auch immer länger. Die genannten Punkte stehen auch in direktem Zusammenhang mit der Zugänglichkeit einer Softwarestückliste.

Als potenzieller Nutzer von SBOM-Daten sollten Sie bereits über einen Plan zur Nutzung dieser Informationen verfügen, bevor Sie eine solche Liste anfordern. Stellen Sie sich vor, was passieren würde, wenn Sie Softwarestücklisten für jede von Ihnen eingesetzte Software erhalten würden. Oder was wäre, wenn die Anbieter tatsächlich Updates für jedes einzelne Release ihrer Produkte aussenden würden, geschweige denn von kleineren Aktualisierungen. Die Sicherheitsteams in Ihrem Unternehmen wären wohl nicht mehr in der Lage, diese Daten noch sinnvoll einzusetzen.

Um die bereitgestellten Informationen richtig zu nutzen, müssen sie elektronisch analysiert werden können. Da es unterschiedliche Standards für diese Aufgabe gibt, darf der dafür benötigte Aufwand nicht unterschätzt werden. Erschwerend kommt hinzu, dass auch die Hersteller ihre durch Menschen lesbaren Berichte und Spreadsheets auf unterschiedlichste Art und Weise erstellen. Wenn Ihre Mitarbeiter die Daten in einem für sie verständlichen Format benötigen, dann sollten Sie sich auf die Suche nach Tools machen, mit denen Sie die Daten auswerten können.

In den meisten Fällen benötigen Sie zudem eine wie auch immer geartete Form der Integration in bereits genutzte Systeme und Prozesse. Das sind etwa Systeme zur Inventarisierung, zum Asset Tracking sowie Software-Registries. Die Mitarbeiter können dann damit herausfinden, welches der von Ihnen eingesetzten Produkte eine bestimmte anfällige Abhängigkeit hat. Noch besser ist es, wenn auch gleich noch eine Verbindung zum bereits vorhandenen Ticketing- oder einem anderen Arbeitsnachweis-System geschaffen werden kann. Dann können automatisch Tickets zum Aktualisieren und Patchen erstellt werden, sobald eine neue gefährliche Schwachstelle entdeckt wurde.