Open-Source-Sicherheitslücken: Wie SBOMs Code-Abhängigkeiten aufdecken
Praxisinterview: Schwachstellen in Open-Source-Paketen werden gravierender – doch SBOMs helfen. Wir erklären, wie sie funktionieren und welche Tools es gibt.
Spätestens mit Log4Shell haben Unternehmen erkannt, dass mit dem Einsatz von Open-Source-Paketen in ihrer Software die Gefahr unentdeckter Schwachstellen einhergeht. Jedoch sind Entwickler diesen Sicherheitslücken nicht schutzlos ausgeliefert, denn Software Bills of Materials versprechen Abhilfe. Wie diese funktionieren und welche Werkzeuge es gibt, erklärt iX-Titelautor Udo Schneider im Interview.
Eine Software Bills of Materials soll vor unbekannten Sicherheitslücken in Open-Source-Paketen schützen. Wie genau soll das funktionieren?
Jede Software kann Sicherheitslücken enthalten, die zum Build-Zeitpunkt nicht bekannt sind. Software Bills of Materials (SBOMs) enthalten jedoch die „eingefrorenen“ Versionsstände der Abhängigkeiten. Werden also nach dem Build-Zeitpunkt Lücken in den eingesetzten Abhängigkeiten bekannt, so kann man sowohl als Nutzer als auch als Hersteller der Software sehr schnell prüfen, ob man betroffen ist, und das Risiko abschätzen. Darüber hinaus können Minderungsmaßnahmen im Code getroffen werden beziehungsweise die verwundbare Abhängigkeit durch eine neue Version ohne diese Lücke ersetzt werden. Dies erfordert natürlich, dass die Nutzer auch neue Versionen einspielen.
SBOMs verhindern also nicht dank hellseherischer Fähigkeiten den Einsatz von Komponenten, die irgendwann einmal Lücken enthalten werden. Vielmehr sind sie die Grundlage, zum Build-Zeitpunkt unbekannte Lücken nach Bekanntwerden der Lücken erkennen, abschätzen und deren Auswirkungen mindern oder durch neue Versionen beseitigen zu können.
Eine SBOM anzulegen und zu pflegen, ist aufwendig. Ist es denn realistisch, dass sich solche Software-Stücklisten im großen Stil durchsetzen?
SBOMs manuell anzulegen und zu pflegen, ist in der Tat illusorisch. Selbst kleine Software-Projekte haben schnell eine deutlich zweistellige Anzahl von (indirekten) Abhängigkeiten. Hier empfiehlt sich die Nutzung von Werkzeugen, die automatisiert Abhängigkeiten extrahieren und als Build-Artefakt (SBOM-Datei) ablegen.
Obwohl dies als Best-Practice empfohlen wird, besteht keine (gesetzliche) Pflicht SBOMs zu erstellen und auszuliefern. Insbesondere im Bereich kritischer Systeme fordern aber immer mehr Betreiber vertraglich SBOMs in ihren Lieferketten. Auch gibt es zum Beispiel in den USA bei kritischen Systemen beziehungsweise bei Ausschreibungen der öffentlichen Hand die gesetzliche Anforderung, SBOMs bereitzustellen. Im deutschen und europäischen Rechtsrahmen gibt es diese gesetzlichen Anforderungen noch nicht. Verfolgt man aber die Diskussionen in Arbeitsgruppen und Gremien, ist auch in Europa mittelfristig mit entsprechenden gesetzlichen Anforderungen zu rechnen.
Und selbst wenn man nicht Teil einer kritischen Lieferkette ist, sollte man damit rechnen, dass (Groß-)Kunden SBOMs langfristig als K.-o.-Kriterium bei der Auswahl von Lieferanten bei Ausschreibungen sehen werden. Man tut also gut daran, sich jetzt in Ruhe mit dem Thema auseinanderzusetzen. Ist man hingegen gezwungen, „mal eben schnell“ SBOM-Prozesse zu etablieren, hat dies ähnliche Erfolgschancen wie „mal eben schnell“ eine hundertprozentige Unit-Test-Abdeckung zu erzielen…
Händisch eine SBOM auf dem aktuellen Stand zu halten, ist also kaum möglich. Welche Werkzeuge sollten sich Entwickler ansehen?
Für Entwickler gibt es zwei(-einhalb) Typen von Werkzeugen, die bei der automatischen Pflege von SBOMs helfen:
- Als erster Typ Werkzeuge, die auf Quelltextebene beziehungsweise eingebunden in den Build-Prozess Abhängigkeiten extrahieren und optional ein Mapping auf entsprechende Sicherheitslücken ermöglichen. Beispiele hierfür sind snyk sowie eingebaute Funktionen von SCM Plattformen wie GitHub oder GitLab.
- Als zweiter Typ Werkzeuge, die Abhängigkeiten aus Build-Artefakten extrahieren. Dies können ausführbare Dateien, Firmware-Images oder Container sein. Beispielhaft seien hier grype, tern oder trivy genannt. All diesen Werkzeugen gemein ist, dass sie unter Umständen nicht alle Abhängigkeiten erkennen können. Sei es, weil Paketformate/Programmiersprachen nicht unterstützt werden oder diese Informationen zum Beispiel bei statisch gelinkten Binaries oder Firmware-Images nicht mehr extrahierbar sind.
- Als verbleibender halber Typ gibt es Werkzeuge, die selber keine SBOMs erzeugen, sondern helfen, mit diesen zu hantieren. Dies ist zum Beispiel das Tool CycloneDX CLI, welches einem erlaubt, SBOMs zu konvertieren (JSON ↔ XML), zu vereinigen (zum Beispiel zwischen JavaScript-Frontend-Code mit einem Java-Backend) oder zwischen verschiedenen SBOM Formaten (CycloneDX, SPDX) zu übersetzen.
Eine gute Auflistung von Werkzeugen findet man auf den Seiten von CycloneDX und SPDX. Auch ein Blick bei GitHub oder GitLab kann hilfreich sein, da dort Werkzeuge und Best-Practices der jeweiligen Pipelines dokumentiert sind, die in den meisten Fällen ebenfalls Open Source sind oder auf Open-Source-Projekte zurückgreifen.
Schlussendlich übrig bleiben Werkzeuge, die SBOMs verwalten. Diese sind weniger im Entwicklungs-, sondern eher im SecOps-Bereich zu sehen, aber nicht minder wichtig. Neben kommerziellen Tools, die SBOMs verwalten oder dies als Zusatzfunktion zu Asset- und Lizenzmanagement anbieten, sei hier als Open-Source-Software DependencyTrack von OWASP zu nennen. Es ermöglicht sowohl die manuelle Verwaltung von SBOMs als auch die automatisierte Einbindung in CI/CD-Pipelines. SBOMs werden dabei kontinuierlich im Hintergrund gegen Sicherheitslücken geprüft und entsprechende Treffer via Mail, Chat und SMS alarmiert.
Udo, vielen Dank für die Antworten. Einen ausführlichen Artikel zu SBOM-Werkzeugen sowie zu Angriffen auf die Softwarelieferkette finden sich in der neuen Oktober-iX.
In der Serie „Drei Fragen und Antworten“ will die iX die heutigen Herausforderungen der IT auf den Punkt bringen – egal ob es sich um den Blick des Anwenders vorm PC, die Sicht des Managers oder den Alltag eines Administrators handelt. Haben Sie Anregungen aus Ihrer tagtäglichen Praxis oder der Ihrer Nutzer? Wessen Tipps zu welchem Thema würden Sie gerne kurz und knackig lesen? Dann schreiben Sie uns gerne oder hinterlassen Sie einen Kommentar im Forum.
(fo)