Heutzutage besteht Software nur noch selten aus rein proprietären Komponenten, die alle in-house entwickelt worden sind. Selbst wenn es sich um proprietäre Software handelt, werden meist Open-Source-Komponenten, wie zum Beispiel in Programmbibliotheken, verwendet. Darüber hinaus können Bibliotheken über transitive Abhängigkeiten selbst auch wieder andere Bibliotheken verwenden.
Durch unsichere Lieferketten können Sicherheitslücken wie Log4J oder Spring4Shell in ein Produkt gelangen, und dazu führen, dass dieses unsicher wird. Vorfälle wie die Kompromittierung von Solarwinds Orion, welche über kompromittierte Updates tausende von Unternehmen mit Schadsoftware infiziert haben, verdeutlichen wie Unternehmen von Ihren Zuliefern insbesondere im Bezug auf die Informationssicherheit abhängig sind.
Wichtig ist daher, bei Software-Projekten die „Lieferkette“ (Supply Chain) der Software besser zu verstehen und transparent zu machen; denn es können leicht Sicherheitslücken oder sogar Hintertüren in externen Bibliotheken eingebaut worden sein. Diese Lücken können sich dann auf das gesamte Softwareprojekt auswirken.
Oftmals haben Entwickler keinen Überblick über alle verwendeten Komponenten und insbesondere transitive Abhängigkeiten sind häufig gar nicht bewusst, geschweige denn dort vorhandene Lücken (die dann nicht behoben werden).
Die Software-Supply-Chain birgt verschiedene Risiken und Angriffspunkte:
Risiken in der Software Supply Chain
Risikominimierung durch Software-Composition-Analysis (SCA)
Durch kontinuierliche Schwachstellenscans in der Anwendungsentwicklung können verwundbare Komponenten schnellstmöglich und automatisiert identifiziert werden
SCA-Tools inspizieren die verwendeten Pakete, Manifeste und Binärdateien einer Software, Container-Images und mehr und identifizieren die verwendeten Komponenten.
Kontinuerliche Überprüfung aller Komponenten
Die identifizierten Komponenten werden dann kontinuierlich mit Schwachstellendatenbanken abgeglichen, um Schwachstellen, etwa in Form von CVEs, zu erkennen. SCAs erkennen Schwachstellen in Komponenten, bevor die Software ausgeliefert wird und erkennen es, wenn neue Schwachstellen ältere Releases betreffen. Ebenso werden Lizenzen überprüft, um sicherzustellen dass nur solche verwendet werden, die mit Ihrem Lizenzmodell übereinstimmen.
Auf dem Markt sind verschiedene SCA-Tools erhältlich, die alle ihre spezifischen Stärken und Schwächen haben. OTARIS berät Sie herstellerunabhängig und findet das Tool, welches zu Ihren spezifischen Anforderungen und Projekten passt.
Interoperabilität durch SBOMs
Viele SCA-Tools können dann auch die Ergebnisse der Scans in einen SBOM kompilieren, und ermöglichen damit die weiterführende Verarbeitung durch zahlreiche weitere Open-Source-Tools und kommerzielle Tools.
SBOMs als Lösungansatz für eine automatisierte Softwareinventur
Wie Software-Bills-Of-Materials (SBOMs) Ihnen helfen, einen Überblick über Ihre Supply-Chain zu erhalten
Software Bills of Material (SBOMs) sind Listen mit den verwendeten Softwarebibliotheken, ihren Versionen, ihrer Herkunft, den (transitiven) Abhängigkeiten und den Relationen der Komponenten untereinander. Dies ist vergleichbar mit Stücklisten, die Informationen über Einzelteile enthalten, die in eine Maschine verbaut sind.
Vorteile von SBOMs
- SBOMs ermöglichen einen Überblick über verwendete Komponenten in einer Software
- Dadurch können Schwachstellen automatisiert erkannt werden und von Schwachstellen betroffene Produkte schnell identifiziert werden
- Die Daten werden in maschinenlesbaren und standardisierten Formaten gespeichert, was Automatisierung ermöglicht
- Ein SBOM ermöglicht Transparenz ohne die Preisgabe von Quellcode oder geistigem Eigentum
SBOMs sind zur Zeit relevanter denn je
SBOMs haben in Zusammenhang mit Sicherheitslücken wie Log4J oder Spring4Shell, welche millionen Systeme auf der Welt betroffen haben, deutlich an Relevanz gewonnen – vor allem im Zusammenhang mit der Executive Order 14028 der US Regierung, welche festschreibt, dass Zulieferer bestimmter kritischer Sektoren der USA eine SBOM liefern müssen. Damit ist davon auszugehen, dass sich immer mehr größere Softwarehersteller und auch Behörden sich entscheiden werden, von ihren Auftragnehmern Transparenz durch SBOMs zu verlangen.
Unsere Leistungen
OTARIS bietet Ihnen Beratungsleistungen im Themenumfeld der Software-Lieferkette und SBOMs an. So unterstützen wir Sie bei der Einrichtung eines Prozesses für abgesicherte Software-Lieferketten, bei der Einrichtung von Software-Composition-Analysis (SCA) und bei der Nutzung von Werkzeugen zum Erstellen und Verarbeiten von SBOMs. OTARIS berät Sie herstellerunabhängig und individuell.
Kontaktieren Sie uns heute
Wir beraten Sie in einem unverbindlichen Gespräch
Häufig gestellte Fragen (FAQ):
Bieten SBOMs einen Vorteil für Hacker, indem Sie die Komponenten einer Software offenlegen? Werden durch SBOMs interne Daten zu Betriebsinternen Programmen und Bibliotheken offengelegt?
Nein – denn in einem SBOM werden nur die Namen und Versionen von verwendeten Drittkomponenten aufgelistet, jedoch keine Details zu internen Implementierungen. Möchte ein Angreifer herausfinden, welche Softwarekomponenten in einer Anwendung verwendet werden, ist dies mittels automatisierten Reverse-Engineering-Tools ohnehin möglich.
Welche SBOM-Formate gibt es?
Die meisten SBOM-Tools arbeiten hauptsächlich mit den Formaten SPDX und CycloneDX, welche sich als Standards etabliert haben. Sowohl SPDX als auch CycloneDX lassen sich jeweils in verschiedenen Datenbeschreibungssprachen (z.B. JSON oder XML) ausdrücken.
Worauf bezieht sich ein SBOM? Was enthält ein SBOM?
In der Regel bezieht sich ein SBOM auf ein konkretes Software-Produkt. Das kann eine Anwendung sein, aber auch ein Container, konkrete Maschinen (z.B. ein Build-Server) oder etwas anderes.
Im SBOM sind Informationen über die enthaltenen Komponenten sowie deren Relationen zueinander enthalten. Welche Informationen das genau bedeutet, ist u.A. vom Format abhängig. Auf jeden Fall muss ein SBOM aber Namen und Versionen der Komponenten enthalten.