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

  • Lizenzprobleme
    Schleichen sich Komponenten mit restriktiven Lizenzen wie GPL in Ihren Code ein, verletzen Sie unter Umständen das Lizenzrecht, wenn Sie Ihre Software nicht Open-Source stellen.
  • Sicherheitslücken
    Beinhaltet eine verwendete Softwarebibliothek oder eine transitive Abhängigkeit eine Sicherheitslücke kann auch Ihre Software verwundbar werden.
  • Hintertüren und Malware
    Über Drittsoftware können Hintertüren und Schadcode, wodurch Ihre Software infiziert und als Einfallstor für Angreifer genutzt werden kann.
  • Compliance
    Bei der Vielzahl an externen Abhängigkeiten ist es leicht, den Überblick über die Herkunft der einzelnen Komponenten zu verlieren. Wenn Sie bei der Wahl Ihrer Zulieferer auf Eckdaten wie geographische Herkunft oder Firmen-Blacklists achten, kann dies zum Problem werden.
  • Kompromittierungen
    Durch die Kompromittierung des Entwicklungsprozesses, z.B. durch Kompromittierung von Updateservern, CI/CD-Pipelines oder Version-Control-Systemen, können Ihre Produkte und Systeme direkt infiziert werden. Werden keine ausreichenden digitalen Signaturen verwendet, können Pakete und Dateien von Angreifern unbemerkt verändert werden.
  • End-Of-Life
    Wird Software nicht mehr gewartet, sei es aufgrund von Insolvenz eines Betriebs oder fehlendem Engagement bei Open-Source-Projekten, werden neue Sicherheitslücken meist nicht mehr gepatcht. Abhängigkeiten zu End-Of-Life-Softwareprojekten sind daher als Sicherheitsrisiko zu betrachten.

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.