Ein Code-Verzeichnis von Abhängigkeiten Was ist SBOM - Software Bill of Materials?

Anbieter zum Thema

Rosenberger-OSI GmbH & Co. OHG

VMware Global Inc Zweigndl. Deutschland

Schwarz IT KG

SYNOPSYS GmbH

Flexera Software GmbH

Die Zielsetzung „Schotten dicht“ beißt sich schon länger in der Unternehmens-IT mit den harten Realitäten der allgegenwärtigen Konnektivität. Wer auf Nummer sicher gehen will, muss sich mit den Verwundbarkeiten der eigenen Software-Versorgungskette auseinandersetzen. Ein standardisiertes Hilfsmittel mit dem Akronym SBOM – Software Bill of Materials – soll dies erleichtern.

Seit der Veröffentlichung der „Executive Order 14028“ durch die US-amerikanische Regierung am 12. Mai 2021 müssen Unternehmen, die Produkte oder Services mit Software an US-Behörden liefern, die Verantwortung für ihre Software-Versorgungskette übernehmen und diesbezüglich eine Reihe von strengen Vorschriften erfüllen. Es besteht fortan unter anderem die Verpflichtung, ergänzend zu jedem Produkt die so genannte Software Bill of Materials (SBOM) mitzuliefern.

SBOM (Software Bill of Materials) ist ein Inventar einer Codebasis, einschließlich aller identifizierbaren Komponenten samt ihrer Lizenz- und Versionsinformationen sowie Angaben zu eventuell vorhandenen Sicherheitslücken. SBOM soll helfen, den Softwarecode samt bekannter Bugs und lizenzrechtlicher Fallstricke in der Codebasis zu inventarisieren, um so die Risiken von Supply-Chain-Verwundbarkeiten auszumerzen.

Die US-Telekommunikationsbehörde National Telecommunications and Information Administration (NTIA) hat ja auch schon eine Reihe an Minimalanforderungen für eine gültige SBOM ausgearbeitet. Mangelware sind momentan noch aber geeignete Tools (siehe: weiter unten).

Wo gehobelt wird

Die Allgegenwärtigkeit von Software versetzt digitalisierte Unternehmen in einen chronischen Bedrohungszustand. Supply-Chain-Attacken häufen sich. Laut Angaben der NCC Group hat die Anzahl von Angriffen gegen Unternehmen aus der Software-Versorgungskette der betroffenen Organisationen heraus zwischen dem Juli und dem Dezember 2021 um 51 Prozent zugenommen.

In Supply-Chain-Attacken nutzen die Angreifer die Software-Versorgungskette ihres Opfers als Einfallstor in die Enterprise-IT. Cyber-Täter machen sich hierzu eine Vielzahl von Tricks zu Nutze, um betroffene Entwickler hinters Licht zu führen, darunter:

• Namensraumverwechslung (auch bekannt als Dependency Confusion): Cyber-Täter vertreiben gefälschte Bibliotheken in einer neueren Version als die offiziell veröffentlichte über frei zugängliche Repos wie „npmjs“; bestimmte Build-Tools holen sich dann ungefragt die neuere, absichtlich bösartige Version der betreffenden Bibliothek und schon sind die resultierenden Softwareprojekte kompromittiert;

• Typosquatting: Dieser indirekte Angriffsvektor macht sich ansonsten harmlose Tippfehler zu Nutze, die Entwicklern bei der Suche nach beliebten Komponenten auf Grund von Unachtsamkeit gerne unterlaufen; bösartige Bibliotheken ersetzen so unbemerkt ihre legitimen Varianten;

• Brandjacking ist die unbefugte Nachahmung des Branding einer Organisation mit dem Ziel, Entwickler darauf aufbauender Projekte hinter den Ofen zu locken.

Mit diesen und verwandten Methoden können Cyber-Täter mehr oder weniger unbemerkt in die Infrastruktur ihrer Opfer eindringen, Daten exfiltrieren oder sonstigen Unheil anrichten und ungeschoren davonkommen. Open-Source-Projekte scheinen bei Cyber-Tätern besonders beliebt.

Sonatype hat im Jahr 2021 einen Anstieg der Angriffe auf die Software-Lieferkette von Unternehmen aus vorgelagerten Open-Source-Ökosystemen heraus um astronomische 650 Prozent festgestellt. Die gleiche Statistik im Jahr davor lag bei 430 Prozent.

Heutige Anwendungen bauen in der Regel auf vielen einzelnen Softwarekomponenten auf, die oft aus einer Vielzahl von Open-Source- und proprietären Quellpaketen stammen. In Anbetracht dieser Komplexität kann es für Unternehmen schwierig sein, einen vollständigen Überblick über die Softwarelieferkette zu erhalten. SBOM soll Klarheit schaffen.

Die Software-Versorgungskette hat sich zu einem nicht zu unterschätzenden Angriffsvektor gegen die Unternehmens-IT gemausert. Das Aufkommen von IoT und IIoT hat die Sachlage noch einmal verschärft.

Aktuelle Zahlen

Laut aktuellen Zahlen von Synopsys hängt die durchschnittliche Software-Anwendung von mehr als einem halben Tausend quelloffenen Bibliotheken und Komponenten ab (nein, das ist kein Tippfehler: von einem halben Tausend). Das ist ein Anstieg um 77 Prozent in nur zwei Jahren.

Einen noch größeren Sprung konnte das Team von Revenera zwischen 2019 und 2020 beobachten, als die Anzahl von quelloffenen Softwarekomponenten in auditierten Unternehmen um 200 Prozent gegenüber Vorjahr zunahm. Den letzten großen Sprung davor um „gerade einmal“ 122 Prozent in zwei Jahren konnten die Forscher zwischen 2014 und 2016 feststellen, als sich Paketmanager mit ihren Features rund um die Verwaltung von Abhängigkeiten in Build-Umgebungen auf breiter Front durchsetzen konnten. Revenera ist eine Unternehmenssparte der Flexera-Gruppe und Anbieter von Werkzeugen zur Verwaltung von quelloffenem Code in der Softwareentwicklung.

Mit der wachsenden Verzwicktheit der typischen Codebasis nehmen auch die Cyber-Risiken zu. Die Zahl der neu gemeldeten Zero-Day-Exploits sei in nur sechs Jahren rund siebenfach gestiegen, von durchschnittlich einer solchen Verwundbarkeit pro Woche im Jahr 2015 auf eine pro Tag im Jahr 2021, warnen die Analysten von Cybersecurity Ventures.

Doch damit nicht genug: Die Angriffsfläche für Anwendungen wächst weiter vor sich hin. Laut Angaben von Cybersecurity Ventures wächst sie von Jahr zu Jahr um je durchschnittlich 111 Milliarden Zeilen Softwarecode.

Für die Unternehmen malen diese Zahlen ein düsteres Bild einer Gefährdungslage, die leicht aus der Hand geraten kann.

Die Unkenrufe der Experten werden immer lauter

Tim Mackey, leitender Sicherheitsstratege bei Synopsys, fordert: „Wir müssen einen Weg finden, [ungepatchte Sicherheitslücken] unter Kontrolle zu bringen; denn wir bewegen uns in die falsche Richtung. Er argumentiert: „Diese Art von Komplexität schafft Fragilität.“ Sie führe nämlich dazu, dass die Entwicklerteams das Verhalten ihres Codes möglicherweise nicht adäquat verstünden, und wann immer es der Fall sei, seien aus seiner Sicht unter bestimmten ungewohnten Randbedingungen extrem unliebsame Überraschungen die Folge.

Open-Source-Abhängigkeiten sind ein Problem insbesondere für Javascript-Anwendungs-Frameworks. Bei einer Analyse von mehr als 45.000 aktiven Repositories stellte Github im Jahre 2020 beispielsweise fest, dass die durchschnittliche Javascript-Anwendung zwar zehn direkte Abhängigkeiten hat, diese Komponenten aber auf andere Bibliotheken angewiesen sind und so wächst der Baum von Abhängigkeiten auf gewaltige 683 separate Codebases. PHP-Anwendungen haben im Durchschnitt so um die 70 Abhängigkeiten und Ruby 68, so der Github-Bericht.

Um eine Verwundbarkeit schließen zu können, müssen die Unternehmen erst einmal überhaupt wissen, dass es sie gibt. Ein SBOM ist dafür unabdingbar.

SBOM-Standards: (k)eine Formsache

Unternehmen können SBOMs in einer Reihe verschiedener Formate erstellen, von HTML-Markup über Text, Markdown, PDF und CSV zu Dateiformaten, die speziell für die Bereitstellung von SBOMs entwickelt wurden: SPDX (Software Package Data Exchange), Software Identification (SWID) Tags und Cyclone DX.

Unternehmen, die ihre Produkte an die US-Bundesregierung verkaufen (und folglich an die Bestimmungen der Cybersecurity Executive Order der Biden-Administration gebunden sind), müssen ihre SBOMs in einem dieser letzteren drei Formate übermitteln.

• SPDX ist ein Projekt der Linux Foundation und ein internationaler offener Standard (ISO/IEC 5962:2021).

• SPDX erfasst Daten in Bezug auf die Herkunft, Lizenzbedingungen und die Sicherheit von Code.

• SWID steht für Software Identification Tag. Es handelt es sich dabei um ein standardisiertes XML-Format, das die Komponenten eines Softwareprodukts identifiziert und kontextualisiert.

Es gibt vier Arten von SWID-Tags, die an verschiedenen Punkten des Software-Entwicklungszyklus (SDLC) zum Tragen kommen:

• 1. Corpus-Tags identifizieren und beschreiben Softwarekomponenten in einem Zustand vor der Installation; sie dienen als Hilfsmittel für Software-Installationswerkzeuge und -prozesse;

• 2. Primary-Tags dienen zur Identifizierung und Kontextualisierung von Softwareprodukten nach der Installation;

• 3. Patch-Tags identifizieren und beschreiben Software-Aktualisierungen (im Gegensatz zum Kernprodukt selbst).

• 4. Ergänzende Tags geben Software-Benutzern und Software-Management-Tools die Möglichkeit, hilfreiche Kontextinformationen von lokalem Nutzen hinzuzufügen, darunter Lizenzschlüssel und Kontaktinformationen.

CycloneDX ist ein leichtgewichtiger SBOM-Standard für den Einsatz im Zusammenhang mit der Anwendungssicherheit und der Analyse von Komponenten in der Softwarelieferkette. Es ist im Rahmen des Open Web Application Security Project (OWASP) entstanden. Es unterstützt vier Kategorien von Daten:

• BOM-Metadaten: Informationen über die Anwendung beziehungsweise das Produkt selbst, darunter den Lieferanten, den Hersteller, die betreffende Produktkomponente und alle Werkzeuge, die zur Erstellung des SBOM verwendet werden;

• Komponenten: Ein vollständiges Inventar von proprietären und quelloffenen Komponenten, einschließlich relevanter Lizenzierungsinformationen;

• Dienste: Externe APIs, welche die betreffende Softwarekomponente aufrufen kann, einschließlich der URIs der Endpunkte, Authentifizierungsanforderungen und Angaben zu Vertrauensgrenzen;

• Abhängigkeiten, darunter sowohl direkte als auch transitive Beziehungen mit anderen Codebasen.

SBOM bildet die Grundlage für die Bereitstellung erweiterter Funktionalität rund um Software, von Verwundbarkeits-Scannern über Tools für das Lizenz-Management und Compliance bis hin zu Werkzeugen rund um das Supply-Chain-Risiko-Management.

SBOM-Werkzeuge

Um ein SBOM zu berechnen, kommen so genannte SCA-Werkzeuge (SCA = Software Composition Analysis) zum Tragen, also Tools für die Analyse der Softwarezusammensetzung. Das intelligente Berechnen von BOMs (Bill of Materials) aus Softwarecode bildet die Grundlage für Lösungen wie Verwundbarkeitsscanner und Lizenz-Management-Werkzeuge.

Im Rahmen dem Projekt namens Automated Compliance Tooling Project unter der Schirmherrschaft der Linux Foundation entsteht eines Sammlung quelloffener Referenz-Toolchain(s) für die automatische Erstellung und Verwendung von SBOMs zur Unterstützung der Lizenzeinhaltung, des Schwachstellen-Managements und anderer Richtlinien. Die quelloffenen Gemeinden der Projekte „Fossology“, „Tern“, „OSS Review Toolkit“, „Reuse Software“, „Scan Code“ und „SPDX“ ziehen gemeinsam an einem Strang.

* Das Autorenduo Anna Kobylinska und Filipe Pereia Martins arbeitet für McKinley Denali Inc. (USA).

(ID:48414325)