SBOMs: Was sie sind und warum Organisationen sie brauchen

Im Zuge von Cyberangriffen, Hacks und Ransomware wollen und müssen Unternehmen ihre Software program-Lieferketten bereinigen.

Dabei greifen sie zunehmend auf ein wertvolles Visibility-Device zurück: die Software program Invoice of Supplies (SBOM).

Wie von der Cybersecurity and Infrastructure Safety Company (CISA) festgestellt, haben sich SBOMs „als ein wichtiger Baustein in der Softwaresicherheit und im Risikomanagement der Softwarelieferkette herauskristallisiert“.

Was ist eine SBOM?

Wenn Sie in der Konstruktion oder Fertigung gearbeitet haben, sind Sie bereits mit einer Stückliste oder Stückliste vertraut, die eine Liste aller Teile ist, die zur Herstellung eines bestimmten Produkts benötigt werden – von Rohmaterialien bis hin zu Unterkomponenten und allem dazwischen mit Mengen von jedem, die für ein fertiges Produkt benötigt werden. Eine SBOM ist additionally eine Stückliste für Software program. CISA definiert eine SBOM als „verschachteltes Inventar, eine Liste von Bestandteilen“, aus denen Softwarekomponenten bestehen.

Nach Angaben des US-Handelsministeriums sollten SBOMs eine vollständige, formal strukturierte, maschinenlesbare Liste dieser Komponenten sowie Bibliotheken und Module bieten, die zum Erstellen der Software program erforderlich sind, die Lieferkettenbeziehungen zwischen ihnen und ihre jeweiligen Schwachstellen. Insbesondere bieten SBOMs einen Einblick in die Zusammensetzung von Software program, die mit Open-Supply-Software program und kommerzieller Software program von Drittanbietern erstellt wurde.

Bidens Government Order on Enhancing the Nation’s Cybersecurity diente als eine Artwork Weckruf für föderale Softwareanbieter, wenn es um SBOMs geht. Sie müssen sie nun umsetzen und sich an die darin enthaltenen Mindestelemente halten.

Und viele Experten drängen non-public Softwareanbieter zunehmend dazu, dasselbe zu tun.

Warum sie umsetzen?

Beim Schreiben (idealerweise sicherer) Anwendungen überprüfen Entwickler den von ihnen geschriebenen Code, um sicherzustellen, dass keine Logikfehler oder Programmierfehler vorliegen. Dennoch sind die heutigen Anwendungen oft ein Konglomerat aus proprietärem Code sowie Open-Supply- und Drittanbieter-Komponenten – eine Anwendung kann beispielsweise eine Mischung aus Dutzenden solcher Komponenten sein.

Die Sichtbarkeit dieser kommerziellen und Open-Supply-Software program von Drittanbietern kann jedoch eingeschränkt sein. Und Angreifer nutzen dies zunehmend aus, indem sie auf Schwachstellen abzielen, die Unternehmen in Bibliotheken von Drittanbietern nicht aufdecken können, weil sie nicht vollständig sichtbar sind. Dies führte zu Vorfällen wie der Log4j-Schwachstelle und dem Angriff auf die Softwarelieferkette von SolarWinds.

Eine jährliche Umfrage des Synopsis Cybersecurity Analysis Heart unter 2.409 Codebasen ergab, dass 97 % Open-Supply-Komponenten enthielten. Es zeigte sich auch, dass 81 % dieser Codebasen mindestens eine bekannte Open-Supply-Schwachstelle aufwiesen und dass 53 % Lizenzkonflikte enthielten.

Da Organisationen für ihre Softwareentwicklungsketten verantwortlich sind – proprietärer, Open-Supply- und Drittanbietercode gleichermaßen –, suchen Sicherheits- und Risikomanagementführer nach Lösungen, die nicht nur dazu beitragen, das Produktsicherheitsrisiko und das Lieferkettenrisiko zu mindern, sondern auch die Zeit bis zur Umsetzung verkürzen. laut Gartners 2022 Innovation Perception for SBOMs Report, die Reaktion auf Vorfälle zu automatisieren und bei Compliance-Anforderungen zu helfen.

„SBOMs stellen einen entscheidenden ersten Schritt dar, um Schwachstellen und Schwachstellen in Ihren Produkten und den Geräten zu entdecken, die Sie von Ihrer Softwarelieferkette beziehen“, schreiben die Autoren des Berichts Manjunath Bhat, Dale Gardner und Mark Horvath. SBOMs ermöglichen es Unternehmen, die riesigen Mengen an Code, die sie erstellen, verbrauchen und betreiben, „risikofreier“ zu machen.

SBOMs „verbessern die Sichtbarkeit, Transparenz, Sicherheit und Integrität von proprietärem und Open-Supply-Code in Softwarelieferketten“, heißt es in dem Bericht. Das Unternehmen rät führenden Softwareentwicklern, das Device während des gesamten Lebenszyklus der Softwarebereitstellung zu integrieren.

Laut dem Forschungsteam der Linux Basis bereitet die Verbesserung der Softwarequalität Unternehmen besser darauf vor, gegnerische Angriffe nach neuen Offenlegungen von Open-Supply-Schwachstellen wie denen im Zusammenhang mit Log4j zu vereiteln.

Auch laut Linux-Forschung:

• 51 % der Unternehmen geben an, dass SBOMs Entwicklern das Verständnis von Abhängigkeiten zwischen Komponenten in einer Anwendung erleichtern.
• 49 % sagen, dass SBOMs die Überwachung von Komponenten auf Schwachstellen erleichtern.
• 44 % sagen, dass SBOMs die Verwaltung der Lizenz-Compliance erleichtern.

Sie sind „ein wesentliches Werkzeug in Ihrer Sicherheits- und Compliance-Toolbox“, wie Bhat, Gardner und Horvath von Gartner behaupten. „Sie helfen dabei, die Softwareintegrität kontinuierlich zu überprüfen und die Beteiligten auf Sicherheitslücken und Richtlinienverstöße aufmerksam zu machen.“

Anwendungsfall erklärt

Angesichts der Tatsache, dass eine SBOM Komponenten enthält, die in einer Anwendung verwendet werden, ist die erste zu beantwortende Frage, warum eine Organisation diese Informationen benötigt, erklärte Tim Mackey, leitender Sicherheitsstratege bei Synopsys. Oft lautet die Antwort, dass sie nicht Opfer eines Angriffs im Log4Shell-Stil werden wollen, sagte er.

Diese einfache Patch-Administration-Anweisung impliziert additionally, dass ein Prozess existiert, der die gesamte Software program auf die Verwendung von Log4j analysiert und diese Verwendung dann einer Datenbank mit anfälligen Versionen von Log4j zuordnet. Wenn die in der Anwendung gefundene Model von Log4j als anfällig erkannt wird, wird eine Benachrichtigung an Programmierer gesendet und das Drawback im Idealfall behoben.

Aber „dieser gesamte Workflow bricht zusammen“, sagte er, wenn es Software program gibt, die nicht analysiert wurde, wenn die Schwachstellendatenbank veraltet ist oder wenn es ein Drawback bei der Zuordnung identifizierter Versionen zu anfälligen Versionen gibt.

Mackey unterstreicht die Tatsache, dass ein Unternehmen eine SBOM benötigt, es sei denn, ein Unternehmen kann sicher sagen, dass seine Patch-Administration-Prozesse die gesamte Software program abdecken.

„Ohne solche Informationen“, sagte er, „ist es für jede Organisation sehr schwierig, sich gegen Cyberangriffe zu verteidigen, die auf Softwarekomponenten von Drittanbietern abzielen.“

Eine wachsende Unternehmenspraxis

Laut Gartner werden bis 2025 60 % der Unternehmen, die Software program für kritische Infrastrukturen entwickeln oder beschaffen, SBOMs in ihrer Software program-Engineering-Praxis vorschreiben und standardisieren. Das entspricht einer Steigerung von rund 20 % gegenüber 2022.

Das Forschungsteam der Linux Basis enthüllte, dass 78 % der Unternehmen damit rechnen, SBOMs im Jahr 2022 zu produzieren oder zu konsumieren – ein Anstieg von 66 % gegenüber 2021. Das Staff berichtete auch, dass ein zusätzlicher Branchenkonsens und Regierungsrichtlinien die Einführung und Implementierung von SBOM weiter vorantreiben werden.

Es entstehen immer mehr Anbieter, die Unternehmen beim Aufbau von SBOMs unterstützen. Dazu gehören Anchore, Mend, Rezilion, Aqua und Synopsys.

Der erhöhte Nutzen von SCAs

Aber während es nach Bidens Befehl erneutes Interesse an SBOMs gibt, ist das Konzept auf dem Sicherheitsmarkt für Software program-Kompositionsanalysen (SCA) seit Jahren weit verbreitet, behauptete Mackey. Anbieter auf dem Markt verwenden SBOMs, um ungepatchte Open-Supply-Schwachstellen zu identifizieren.

Auch der SBOM-Workflow ist häufig in SCA-Instruments zu finden. Der SCA-Markt ist ein ausgereifter Markt mit vielen Anbietern, sagte Mackey.

Obwohl das Konzept einer SBOM „stark im Fokus“ steht, wird nicht immer anerkannt, dass eine SBOM einfach eine Datei ist, die die Elemente auflistet, aus denen eine Anwendung besteht.

Es enthält keine Informationen zu Schwachstellen, Funktionalität, Wartungsfreundlichkeit oder gar dem Alter der Komponente. Diese Informationen müssen aus anderen Quellen stammen, die von Instruments wie SCAs aufgedeckt werden, sagte er, und sie müssen auch von Arbeitsabläufen unterstützt werden.

Einfach ausgedrückt: „Ohne diese Quellen und Arbeitsabläufe ist eine SBOM nicht effektiver, als jemandem, der nicht weiß, dass er das Öl in seinem Auto regelmäßig wechseln muss, die chemische Zusammensetzung des Motoröls mitzuteilen“, sagte Mackey.