Software-Lieferketten absichern, Teil 2 Risiken in der Software Supply Chain

Die Software-Lieferkette stellt für „digitaltransformierte“ Organisationen einen erheblichen Risikofaktor dar. Unternehmen müssen Gefahren aktiv entgegenwirken, zum Teil ist es bereits heute verpflichtend. Erfolgreiche Initiativen setzen bei der Risikobewertung an.

Laut aktuellen Zahlen von Synopsys hängt die durchschnittliche Softwareanwendung von mehr als einem halben Tausend (nein, das ist kein Tippfehler) quelloffenen Bibliotheken und Komponenten ab. Ein Anstieg um 77 Prozent hat sich in gerade einmal zwei Jahren abgespielt.

In 4.300 Sicherheitstests an 2.700 Softwarezielen, darunter Web- und mobilen Anwendungen, Quellcode-Dateien und Netzwerksystemen, die Synopsys im Jahre 2022 durchführte, konnte der Security-Anbieter bei 95 Prozent der Ziele aktive Verwundbarkeiten feststellen (eine Abnahme um moderate zwei Prozent im Vergleich zu den Ergebnissen des Vorjahres). Bei einem von fünf Systemen (20%) haben die Forscher hohe Risiken festgestellt, was einem Rückgang von zehn Prozent gegenüber dem Vorjahr entspricht. Kritische Sicherheitslücken kamen bei 4,5 Prozent der Ziele ans Tageslicht.

Laut Angaben von Cybersecurity Ventures wächst die Angriffsfläche von Anwendungen um durchschnittlich 111 Milliarden Zeilen Softwarecode pro Jahr. Für die Unternehmen malen diese Zahlen ein düsteres Bild einer Gefährdungslage, die leicht aus der Hand geraten kann. Die Unkenrufe werden immer lauter: „Wir müssen einen Weg finden, [ungepatchte Sicherheitslücken] unter Kontrolle zu bringen, denn wir bewegen uns in die falsche Richtung“, warnt Tim Mackey, leitender Sicherheitsstratege bei Synopsys.

„Diese Art von Komplexität schafft Fragilität,“ argumentiert er weiter. 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 unliebsame Überraschungen die Folge.

Open-Source-Abhängigkeiten sind ein großes Problem, insbesondere für JavaScript-Anwendungsframeworks. Bei einer Analyse von mehr als 45.000 aktiven Repositories stellte GitHub im Jahre 2020 beispielsweise fest, dass die durchschnittliche JavaScript-Anwendung „nur“ zehn direkte Abhängigkeiten hat. Diese Komponenten sind aber wiederum auf andere Bibliotheken angewiesen und so wächst der Baum von Abhängigkeiten auf gewaltige 683 separate Codebases. PHP-Anwendungen haben im Durchschnitt um die 70 Abhängigkeiten und Ruby 68, so der GitHub-Bericht.

Angriffe auf Abhängigkeiten

Jedes einzelne Glied einer Software-Lieferkette kann gefährdet sein, warnen die Sicherheitsexperten von Snyk. Die drei Hauptziele stellen Abhängigkeiten, Pipelines und die Kombination der beiden Elemente, Pipeline-Abhängigkeiten, dar. Um bösartigen Code in eine Anwendung einzuschleusen, können sich Angreifer ihre direkten oder indirekten Abhängigkeiten zu Nutze machen (die sogenannten transitiven Abhängigkeiten).

„Transitive Abhängigkeiten“ sind indirekte Interdependenzen, also solche, die durch andere Abhängigkeiten in einem Softwareprojekt eingeführt werden. Wenn die Komponente A von der Komponente B und B wiederum von C abhängt, dann ist C eine transitive Abhängigkeit für A. Mit anderen Worten: A ist indirekt von C abhängig.

98 Prozent aller Anwendungen im Umlauf verwenden Open Source. Vier von fünf Sicherheitslücken werden über transitive Abhängigkeiten eingeführt. Sechs von sieben Angriffen auf die Software-Lieferkette loten eben diese Schwachstellen transitiver Abhängigkeiten aus, glauben Sicherheitsforscher der Softwarespezialistin Sonatype.

Eine Supply-Chain-Attacke gegen Abhängigkeiten unterwandert typischerweise öffentlich zugängliche Open-Source-Pakete oder Container-Images, die zur Erstellung der betreffenden Software herangezogen werden. Entwickler nachgelagerter Projekte, die ein solches infiziertes Paket verwenden, ohne es zu ahnen, beziehen unwissentlich diesen bösartigen Code, integrieren ihn in ihre eigenen Projekte und vertreiben ihn an nachgelagerte Nutzer.

Ein Beispiel einer solchen Attacke ist unter der Bezeichnung „Dependency Confusion“ bekannt (Abhängigkeitenverwechslung a.k.a. Namensraum-Verwechslung). Bei dieser Art von Angriffen veröffentlichen Täter bösartige Pakete mit demselben Namen wie private Softwarepakete und kennzeichnen diese mit einer höheren Versionsnummer. Dadurch gelingt es ihnen, bösartigen Code einzuschleusen.

Angriffe auf Entwicklungs-Pipelines

Eine andere Methode kapert die Entwicklungs-Pipeline selbst. Dabei besteht das Ziel ebenfalls darin, bösartigen Code in die resultierende Anwendung einzuschleusen, doch diesmal manipulieren Angreifer nicht die Abhängigkeiten, sondern vielmehr jenen Code, der den Build-Prozess steuert.

Betroffen sind zum Beispiel CI-Skripte, Konfigurationsdateien von Build-Werkzeugen und andere Hilfsmittel sowie Infrastruktur-as-Code-Lösungen. Diese Attacke erlaubt es Angreifern, den Build-Prozess zu missbrauchen, um bösartigen Code einzubinden und an nachgelagerte Benutzer zu verteilen.

Angriffe auf Abhängigkeiten der Pipeline-Tools

Angriffe auf Pipeline-Abhängigkeiten zielen darauf ab, externe Interdependenzen der Build-Pipeline zu unterwandern. Dabei kann es sich beispielsweise um Plugins von Drittanbietern, Binärdateien von Werkzeugen oder die Build-Umgebung selbst handeln.

Ein prominentes Beispiel für die vernichtende Natur einer Attacke auf Pipeline-Abhängigkeiten lieferten Cybertäter mit ihrem Angriff auf das Technologieunternehmen Codecov im April 2021. Mit den Anmeldeinformationen aus einem fehlerhaft erzeugten Docker-Image von Codecov gelang es ihnen, in ein 1.900 Zeilen langes Skript namens "Bash Uploader" für GitHub eine Zeile bösartigen Code einzuschleusen und so eine Hintertür zu den Kundenorganisationen zu schaffen.

Wann immer ein Developer in diesen Organisationen das Codecov-Skript bezog und ausführte, wanderten sensible Daten wie Anmeldeinformationen, Geheimnisse und Schlüssel aus der CI-Umgebung des Opfers an einen von den Angreifern kontrollierten Server außerhalb der Infrastruktur der Kundenorganisation. Mehr als 29.000 Unternehmen nutzten die Plattform, um ihren eigenen Softwarecode zu testen.

Mit diesen und verwandten Methoden können Cyber-Täter unbemerkt in die Infrastruktur ihrer Opfer eindringen, Daten exfiltrieren und sonstigen Unheil anrichten. Um eine Verwundbarkeit schließen zu können, müssen die Unternehmen erst einmal überhaupt wissen, dass es sie gibt. Eine Software-Bestandsliste, die sogenannte SBOM, ist dafür unabdingbar.

Software Bill of Materials

Bei einer SBOM (kurz für Software Bill of Materials, eine Software-Bestandsliste) handelt es sich um eine formale, strukturierte Aufzeichnung der Komponenten eines Softwareprodukts und deren Beziehungen zueinander innerhalb der Softwarelieferkette. In den Vereinigten Staaten ist sie für Software-Schmieden Pflicht.

Seit der Veröffentlichung der Executive Order 14028 (SP 800-161 Rev. 1 vom 5. Mai 2022) durch die US-amerikanische Regierung 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 sogenannte Software Bill of Materials (SBOM) mitzuliefern.

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

SBOM-Standards: (k)eine Formsache

Die US-Telekommunikationsbehörde National Telecommunications and Information Administration (NTIA) hat eine Reihe an Minimalanforderungen für eine gültige SBOM ausgearbeitet. Die SBOM muss demnach in einem von drei standardisierten Formaten vorliegen, damit sie maschinenlesbar ist: SPDX (Software Package Data Exchange), CycloneDX oder SWID-Tags (Software Identification Tags).

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 drei Formate übermitteln. Unternehmen ohne besondere Compliance-Pflichten steht es im Gegensatz dazu frei, eine SBOM in einem anderen Format zu führen, von HTML-Markup über Text, Markdown, PDF bis hin zu CSV.

Eine SBOM bildet die Grundlage für die Bereitstellung erweiterter Funktionalität rund um Software, von Verwundbarkeitsscannern über Tools für das Lizenzmanagement und Compliance bis hin zu Werkzeugen rund um das Supply-Chain-Risikomanagement.

SPDX

Bei SPDX (kurz für Software Package Data Exchange) handelt es sich um einen internationalen offenen Standard zum Kommunizieren von SBOM-Informationen, einschließlich Komponenten, Lizenzen, Urheberrechtfallstricke und Sicherheitsreferenzen (ISO/IEC 5962:2021). Zu den treibenden Unterstützern zählen Unternehmen wie Siemens, SAP, VMware, Cisco, Google und die Eclipse Foundation.

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.

CycloneDX

CycloneDX ist ein leichtgewichtiger Full-Stack-Standard von der OWASP Foundation für eine SBOM mit erweiterten Fähigkeiten rund um umfassendes Risikomanagement der Technologie-Lieferkette. Die Spezifikation ist im Rahmen des Open Web Application Security Project (OWASP) entstanden und unterstützt vier Kategorien von Daten:

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

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

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

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

Konkret also:

• Software-Bestandsaufnahme (SBOM)

• Software-as-a-Service-Bestandsaufnahme (SaaSBOM)

• Hardware-Bestandsaufnahme (HBOM)

• Betriebs-Bestandsaufnahme (OBOM)

• Schwachstellen-Offenlegungsberichte (VDR)

• Vulnerability Exploitability eXchange (VEX)

Das CycloneDX-Projekt stellt unter anderem auch eine umfangreiche Sammlung von Tools und anderen Hilfsmitteln bereit.

SWID-Tagging

SWID steht für Software Identification Tag. Es handelt sich dabei um ein standardisiertes XML-Format, das die Komponenten eines Softwareprodukts identifiziert und kontextualisiert. Bei den sogenannten SWID-Tags handelt es sich um eine Art Metadaten zur Beschreibung von Softwarekomponenten und Verfolgung von Lizenzinformationen und Eigentumsverhältnissen von Code.

Dieses strukturierte Metadatenformat ist durch den ISO- und IEC-Standard ISO/IEC 19770-22 definiert. Er sieht für die verschiedenen Phasen der Softwareentwicklung- und -Bereitstellung (SDLC) vier Arten von Tags vor, und zwar:

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

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

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

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

SWID-Tags lassen sich unter anderem Dateien, Verzeichnissen und Anwendungen zuordnen. SWID-Tags bieten Organisationen eine transparente Möglichkeit, die auf ihren verwalteten Geräten installierte Software zu verfolgen. Sie sollen Unternehmen dabei helfen, genaue Softwareinventare zu erstellen, indem sie die Entdeckung, Identifizierung und Kontextualisierung von Software im gesamten Softwarelebenszyklus erleichtern.

Das NIST hat ein Validierungswerkzeug für SWID-Tags entwickelt, der die Konformität der Tags mit den in NISTIR 8060 definierten Anforderungen in verschiedenen Phasen des Softwarelebenszyklus überprüft.

Fazit

In Supply-Chain-Attacken nutzen die Angreifer die Software-Versorgungskette als Einfallstor in die Enterprise-IT oder -OT ihres Opfers. Fortgeschrittene persistente Bedrohungen, die sogenannten APTs (Advanced Persistent Threats), machen es den Unternehmen besonders schwer zu schaffen. Die resultierenden Angriffsversuche sind ausgeklügelter, fortdauernder und schwerer zu erkennen; sie unterwandern ganze Wertschöpfungsketten, die sich auf die betroffenen Softwareprodukte stützen.

Heutige Anwendungen bauen auf einer Vielzahl von Open-Source- und proprietären Quellpaketen auf und entstehen in Entwicklungspipelines mit Hilfe von vergleichbar verzwickten Tools Dritter. In Anbetracht dieser Komplexität kann es für Unternehmen schwierig sein, einen vollständigen Überblick über ihre Software-Lieferkette zu erhalten, geschweige denn über die Gesamtheit aller Risiken im Bilde zu sein.

Standardisierte Hilfsmittel zur Verwaltung von Softwarekomponenten wie die SBOM können Abhilfe schaffen. Sie bilden die Grundlage für Lösungen wie Verwundbarkeitsscanner, Lizenzmanagementwerkzeuge und andere fortschrittliche Werkzeuge zur Verwaltung der Softwarelieferkette.

(ID:49949708)