Rezeptur für mehr Code-Sicherheit

Software Bill of Materials

IT-Sicherheit beginnt auf Codeebene. Um die Software-Supply-Chain transparenter und Anwendungen sicherer zu machen, müssen Entwickler bei der Verwendung von Open-Source-Software-(OSS-)Komponenten genau Buch führen. Gut, dass mit der Software Bill of Materials (SBOM) dafür bereits ein Template bereitsteht. 

Bei der Software-Entwicklung ist es ein bisschen wie beim Kochen: Verschiedene Codezeilen und Komponenten werden miteinander vermischt, bis am Ende eine neue Anwendung entsteht. Die richtige Rezeptur ist entscheidend – nicht nur für die Performance, sondern auch für die Sicherheit. Immerhin stammen die Zutaten aus verschiedenen Quellen, enthalten versteckte „Zusatzstoffe“, oder gelten als „hoch verarbeitete Lebensmittel“. Von Informationen über „Herkunftsland“, „biologischer Anbau“ und „Fairtrade“ ganz zu schweigen. In der Lebensmittelindustrie gibt es immer wieder Versuche, die Kennzeichnung auf Verpackungen zu verbessern und Lieferketten rückverfolgbar zu machen. Wie steht es aber um die Sicherheit und Transparenz im Software-Code?

Sicherheitsrisiko von Open Source Software (OSS) 

Wäre Software ein Rezept, stände Open Source ganz oben auf der Einkaufsliste. Open-Source-Software-(OSS-)Komponenten machen bis zu 80 Prozent des Codes in kommerziellen Anwendungen aus. Kaum ein Entwicklerteam, das nicht auf bestehende Komponenten zurückgreift, um schneller und effektiver zu arbeiten. Dabei bleibt die Dokumentation der Bausteine leider oft außen vor. Finden sich dann zu einem späteren Zeitpunkt Schwachstellen oder Lizenzverstöße, lässt sich nur sehr schwer zurückverfolgen, wo und wie der betroffene Code in die Software Supply Chain gelangt ist und welche Anwendungen betroffen sind.

Unternehmen fehlt es an Transparenz: Im Rahmen von Software-Audits wertete Revenera mehr als 2,6 Milliarden Codezeilen aus und entdeckte dabei insgesamt 230.000 kritische Fälle. Im Durchschnitt stießen die Analysten alle 11.500 Codezeilen auf einen Compliance-Verstoß, eine Sicherheitsschwachstelle oder Ähnliches. Das eigentlich Fatale: 83 Prozent der in den Audits aufgedeckten Risiken war den Unternehmen im Vorfeld der Untersuchung nicht bekannt. Oder um beim Vergleich zu bleiben: Vielen wurde ein Gericht vorgesetzt, von dem nicht einmal der Koch den Großteil seiner Zutaten kannte.

SBOM: Stückliste für die Software-Industrie

In den letzten Jahren hat sich die Softwarebranche daher gezwungenermaßen mit der Verbesserung der Open-Source-Governance auseinandergesetzt. Im Mittelpunkt vieler Compliance-Programme steht dabei die Software Bill of Materials (SBOM). Die SBOM bezeichnet die vollständige Dokumentation aller in einer Software eingesetzten Code-Komponenten einschließlich Lizenzierung, Versionen und Herkunft. Dabei geht es nicht nur darum, die einzelnen Komponenten zu kennen, sondern auch deren Zusammensetzung – angefangen bei Paketen und Abhängigkeiten über Binärdateien ohne Manifest-Dateien, Multimedia-Dateien, Bilder/Icons, Codecs und Copy/Paste-Codes bis hin zu den von Entwicklern genutzten Source Libraries und Drittanbieter-Bibliotheken.

Sicherheit als Wettbewerbsfaktor

Software-Anbieter, denen ein solcher Einblick in den eigenen, intern entwickelten Code fehlt, müssen über kurz oder lang mit fehlendem Kundenvertrauen sowie Wettbewerbsnachteilen rechnen. Schon jetzt pochen viele Unternehmen beim Kauf von Softwareprodukten auf die Offenlegung des Codes. Oft wird die SBOM sogar als Teil der Service-Level-Verträge (SLAs) vertraglich festgesetzt. Wer als Anbieter mit der US-Regierung Geschäfte machen will, muss seit Mai 2021 eine Software-BOM für jedes Produkt bereitstellen. Die EU-Kommission geht mit ihrer Open-Source-Software-Strategie 2020–2023 in eine ähnliche Richtung. Und auch einflussreiche Branchenverbände und Behörden, wie die FDA (The Food and Drug Administration) in den USA sowie die GENIVI Alliance und die Automotive Grade Linux (AGL), machen sich für die SBOM stark. Angetrieben wird diese Entwicklung vor allem durch die Flut von Cyberattacken, bei denen Angreifer versuchen, über die Codeebene Systeme zu infiltrieren. Open-Source-basierte Schwachstellen wie Log4Shell haben eindrücklich verdeutlicht, dass Softwarelieferketten geschützt und überwacht sein wollen. So hatten allein im letzten Jahr fast zwei Drittel (64 Prozent) der Unternehmen mit Angriffen auf die Softwarelieferkette zu kämpfen.

Vier Best Practices bei der SBOM-Erstellung

Die gute Nachricht: Das Framework rund um die automatisierte und kollaborative Erstellung der Software-BOM verbessert sich zunehmend. Eine wichtige Anlaufstelle ist zum Beispiel das ISO-zertifiziert OpenChain-Project. Anerkannte Standardformate (zum Beispiel SPDX, CycloneDX, SWID) helfen Entwicklern darüber hinaus, Informationen einheitlich zu dokumentieren und zu teilen. Darüber hinaus sollten Unternehmen einige grundlegende Best Practices in den Erstellungsprozess von SBOM implementieren.

1. Automatisierung und Zusammenarbeit

Ein zentrales Kriterium der SBOM ist ihre Aufbereitung. Der Datensatz sollte nicht nur formal und abfragbar, sondern auch maschinenlesbar sein. Der Grund: Nur so lässt sich die nötige Automatisierung beim Erstellen sowie beim Durchsuchen einer SBOM realisieren. Softwareprodukte sind komplex und legen mit jeder neuen Version und jedem neuen Update an Code-Umfang zu. Wer sich hier manuell an das Auflisten von Code-Fragmenten und Abhängigkeiten macht, läuft nicht nur Gefahr, kontinuierlich einen Schritt hinter dem aktuellen Entwicklungsstand der Anwendung zu bleiben. Es passieren auch Fehler.

Entwicklerteams mangelt es schlichtweg an Ressourcen. Zudem fehlt es oft an spezifischem Wissen, was die Open Source-Lizenzierung und sichere Codierungsverfahren angeht. Entwickler sind zudem nicht im Alleingang für die Software-BOM verantwortlich. Im Gegenteil, die Software-BOM setzt die Mitarbeit von Rechtsexperten, Produktmanagern und Sicherheitsteams voraus. Automatisierte Software Composition Analysis-Tools unterstützen diesen kollaborativen Ansatz, scannen den Code, gleichen die gefundenen Komponenten mit externen Quellen (zum Beispiel Open-Source-Wissensdatenbanken) ab und erstellen eine detaillierte Auflistung für alle Stakeholder.

2. Kontinuierliche Überprüfung und Aktualisierung

Selbst bei vollständiger Automatisierung braucht die Erstellung einer SBOM Zeit. Die Aktualisierung der Software-Stückliste wird daher von den wenigsten Anbietern täglich durchgeführt, sondern erfolgt in regelmäßigen Abständen und/oder zu bestimmten Anlässen (zum Beispiel Veröffentlichung einer Schwachstelle, neues Release). Wie häufig es zu SBOM-Updates kommt, hängt sowohl von der Anwendung selbst, als auch vom Unternehmen ab. Wichtige Faktoren sind unter anderem die Anzahl der Releases, die Größe des IT-Portfolios, die vorhandenen Ressourcen sowie die SBOM-Expertise. Auch mit dem Kunden vertraglich vereinbarte Services sowie Compliance-Richtlinien sind entscheidend. Wie oft auch immer Unternehmen ihre Software-Stücklisten aktualisieren, in jedem Fall heißt es, klare Prozesse und Best Practices bezüglich der Rollenverteilung und der Terminierung zu definieren und zu implementieren. Die SBOM sollte dabei weniger als Ad-hoc-Instrument verstanden werden, sondern als fester Bestandteil der Entwicklungsarbeit bzw. der IT-Sicherheit.

3. Zentralisierte Teams: OSPO und OSRB

Um ein entsprechendes, SBOM-konformes Framework aufzustellen, braucht es dezidierte Teams in Unternehmen. Im sogenannten Open Source Program Office (OSPO) beispielsweise arbeiten Vertreter aus den Bereichen Recht, Technik, Produkt und Sicherheit zusammen, um ganzheitliche Strategien intern zu implementieren (Inbound-Use-Case) und Code innerhalb von Open-Source-Projekten in die Community einzubringen (Outbound-Use-Case). Die Aufgabe von Open Source Review Boards (OSRB) besteht darin, diese Prozesse kontinuierlich zu verfeinern. Gemeinsam mit dem Entwicklungsteam wird daran gearbeitet, die Nutzung von Open Source und Drittanbieter-Code zu dokumentieren und zu überwachen. Auch hier sollten idealerweise Stakeholder aus den jeweiligen Rechts-, Entwicklungs-, Sicherheits-, IT- und Führungsteams zusammenkommen.

4. Integration in die Threat Intelligence

Die Software-BOM versteht sich als Sicherheitsinstrument und sollte dementsprechend in die unternehmensübergreifende IT-Sicherheit integriert werden. Das gilt insbesondere für die Threat Intelligence. Bekanntgewordene Schwachstellen, geleakte Code-Fragmente und im Darknet angebotene Exploits stellen unmittelbare Bedrohungen für Anwendungen dar. Software-Anbieter müssen im Ernstfall in der Lage sein, das Risiko für ihre eigenen Produkte einzuschätzen. Die SBOM liefert hier die Informationsgrundlage für einen schnellen Abgleich. Sind Anwendungen betroffen, schlagen die Systeme automatisch Alarm und helfen in der Regel auch, Maßnahmen zur Mitigation (zum Beispiel Patches) zu priorisieren und durchzuführen. Gleichzeitig können Software-Anbieter ihre Kunden informieren und besorgte Anfragen bezüglich möglicher Sicherheitsrisiken souverän beantworten.