In den letzten Jahren hat sich die Software-Stückliste (SBOM) zu einem Schlüsselelement der Softwaresicherheit und des Risikomanagements in der Software-Lieferkette entwickelt.
Wir sprachen mit Tim Mackey, Leiter der Software-Lieferkettenrisikostrategie unter Synopsys, um mehr über die Vorteile und Herausforderungen von SBOMs zu erfahren.
BN: Was war die wichtigste Erkenntnis, die sich aus der Log4shell-Schwachstelle ergeben hat?
TM: Die Erfahrungen mit Log4Shell haben gezeigt, dass die Verwendung von Open Source in Unternehmen allgegenwärtig war. Selbst bei kommerzieller Software wurden Open-Source-Komponenten als Abhängigkeiten gefunden. Dadurch wurde deutlicher, dass Open-Source-Projekte von externen Freiwilligen erstellt und gepflegt werden und nicht von ihren eigenen Mitarbeitern oder kommerziellen Drittanbietern. Dies bedeutete, dass der IT jegliche Kontrolle über die Verwendung von Open-Source-Software innerhalb kommerzieller Software fehlte – selbst wenn sie über ausgereifte Open-Source-Governance-Prozesse für Open-Source-Software verfügte, die sie direkt heruntergeladen und verwendet haben, oder die im Rahmen ihrer Bemühungen zur Entwicklung kundenspezifischer Software verwendet wurde.
BN: Was müssen Organisationen über Open Source verstehen, um besser auf die einzigartigen Herausforderungen vorbereitet zu sein, die es mit sich bringt?
TM: Der erste Schritt ist Oft wird einfach erkannt, dass Sie Open Source verwenden, und von dort aus können Sie einen praktikablen Governance-Workflow definieren. Da Open-Source-Teams nicht wissen, wer ihren Code heruntergeladen hat, haben Sie keinen Push-Mechanismus für Updates; Du hast einen Zugmechanismus. Wenn also ein Projekt effektiv aufgegeben wird oder am Ende seiner gewarteten Lebensdauer ist, würden wir uns freuen, wenn diese Betreuer gehen und sagen: „Hey, ich bin mit diesem Projekt fertig“, und eine nette kleine Notiz darauf anbringen es wird keine neuen Updates geben, aber das passiert normalerweise nicht.
Jetzt ist es ein separates Problem,”aufgegebene”und”abgeschlossene”Projekte zu identifizieren. Sie können diese Entscheidung nicht treffen, wenn Sie sich nicht mit dem Projekt beschäftigen. Wenn Sie also nicht wussten, dass Sie ein Projekt verwenden, stellen Sie diese Fragen. Und das ist wirklich das große erste Teil des Puzzles – akzeptieren Sie, dass Sie Open Source haben, akzeptieren Sie, dass es anders gehandhabt wird, und führen Sie einen Prozess ein, der die Beteiligung an diesen Projekten beinhaltet.
Besonders herausfordernd wird es, wenn Sie sagen, drei oder vier Ebenen tief in der Abhängigkeit oder der Lieferantenkette, von denen Sie vielleicht nicht unbedingt wissen, dass Sie Open-Source-Code ausführen. Das ist eine der Lehren aus der gesamten Log4j-Erfahrung, die Leute wussten nicht, dass es dieses Ding namens Log4j gibt, bevor das Problem auftrat.
BN: Was genau ist ein SBOM?
TM: Eine SBOM ist im Grunde eine Datei, die die von einer Anwendung verwendeten Bibliotheken auflistet. Es ist eine Schlüsselkomponente eines Governance-Plans, der nicht nur die Nutzung von Open Source in einer Software-Lieferkette umfasst, sondern auch zu einem Ankerpunkt für andere betriebliche Elemente wird. Das heute am häufigsten diskutierte operative Element ist die Verwendung von SBOM, um Schwachstellen innerhalb von Komponenten in der Softwarelieferkette für die jeweilige Anwendung zu kommunizieren.
BN: Reicht eine SBOM allein aus, um sie zu mindern Sicherheits-und Lizenzrisiken von Open Source?
TM: Nein. Da ein SBOM in einer Executive Order enthalten war, wurde viel Aufmerksamkeit darauf gerichtet: „Ich muss gehen und ein SBOM haben.’Aus praktischen Gründen erstellen heute viele Organisationen SBOMs und es ist einfach eine Stückliste, die besagt:”Ich habe diese Komponenten, die von dieser Stelle stammen, und dies ist die Version davon.”
Das ist es eigentlich eine statische Sache. Es stellt dar, wie diese Software aussah, als sie ausgeliefert wurde. In dieser Hinsicht ist es fantastisch, aber es wird Ihnen nicht sagen, ob es sicherer oder weniger sicher ist als etwas anderes. Es sagt Ihnen genau, wie diese Zutatenliste für diese bestimmte Software aussieht, und das ist, wo die Leute ein bisschen ausgetrickst werden. Das SBOM, über das alle reden, ist nicht dieses magische Einhorn – es ist Teil eines Arbeitsablaufs, der innerhalb von Unternehmen implementiert werden muss.
Das „SB“ in SBOM bedeutet nicht Silberkugel.
p>
Das Problem ist, dass SBOM-Daten in einen Arbeitsablauf gelangen müssen. Die Leute, die am Empfängerende des SBOM sind, könnten sagen: „Hier, ich habe diese Datei, mit der ich nicht weiß, was ich damit anfangen soll“, und das spricht für einen Workflow – eine Reihe von Prozessen, die Unternehmen benötigen herauszufinden.
Mit anderen Worten, das Wissen, das von SBOMs bereitgestellt wird, ist offensichtlich wertvoll, aber wenn Ihr Unternehmen keinen Prozess hat, um es zu nutzen, dann gibt es nur minimalen Nutzen aus einem SBOM und den zugehörigen Schwachstelleninformationen. Dieser fehlende Prozess ist die größte Herausforderung, denn Beschaffungsteams können zwar SBOMs von allen ihren Lieferanten anfordern, aber wenn es keinen klar definierten Prozess gibt, um auf die Informationen in der SBOM zu reagieren, dann ist alles, was passiert ist, Sie habe jetzt eine weitere Datei in einem Verzeichnis.
BN: Wie könnte ein erfolgreicher, gut definierter Prozess aussehen, um Wert aus SBOMs zu ziehen?
TM: Alle Organisationen haben eine IT-Abteilung, die für die Wartung der Patches in der Software innerhalb dieser Organisation verantwortlich ist. Jede Software ist aus Komponenten aufgebaut. Das wissen wir aus dem Synopsys OSSRA-Bericht Open-Source-Nutzung innerhalb kommerzieller Software beträgt durchschnittlich 78 Prozent. Sie wissen also, dass es Open-Source-Komponenten geben wird, die aktualisiert werden müssen. Die SBOM kommuniziert diese Informationen, wenn sie an das von der IT verwaltete Asset angehängt ist.
Wenn es nun an der Zeit ist, dass eine neue Schwachstelle offengelegt wird, ist die IT in der Lage, dieses SBOM-Verwaltungssystem abzufragen und sagen:”A-ha-ich habe das, aber woher kommt mein Pflaster?”Der Patch stammt aus den Herkunftsinformationen der SBOM – das ist die Rolle einer SBOM. Es soll Ihnen nicht sagen, dass Sie eine neue Schwachstelle haben – es ist ein Dokument, das genau beschreibt, was in diesem Artefakt ist, das Sie auszuführen versuchen, und jetzt können Sie die richtigen Dinge tun, wenn Sie diesen Workflow haben.
BN: Welche Anforderungen muss eine SBOM erfüllen?
TM: Um nützlich zu sein, muss eine SBOM sowohl genau als auch vollständig sein, und das sind zwei verschiedene Probleme, die aber eines lösen, ist auf die Auflösung des anderen angewiesen.
Zunächst müssen alle externen Bibliotheken, die in einer Anwendung verpackt sind, protokolliert werden, damit eine SBOM vollständig ist, einschließlich Open-Source-Software, kommerzieller Bibliotheken von Drittanbietern und jeglicher durch sie eingeführter Software ein Drittvertrag. Idealerweise wird die SBOM aus dem Quellcode einer Anwendung gezogen, obwohl dies ein schwieriger Prozess sein kann, je nachdem, wie der Build-Prozess der Anwendung definiert ist. Beispielsweise benötigen Sie möglicherweise zwei verschiedene SBOMs, wenn Sie eine Anwendung für zwei verschiedene Plattformen kompilieren. eine für Windows und eine für Linux.
Ebenso ist es wichtig, dass Komponenten genau identifiziert werden und alles von ihrem Ursprungspunkt bis zu ihrer Version erkennen. Eine SBOM von Erstanbietern, die aus dem Quellcode der Anwendung abgerufen wird, ist am genauesten, aber es gibt auch SBOMs von Drittanbietern. In diesem Fall wird die Anwendung und nicht der Quellcode gescannt. Dies könnte zu fehlenden Informationen führen, da Sie nicht in der Lage sind, die genaue Version der Bibliothek zu bestimmen; Daher eignet sich diese Methode nur, wenn Erstanbieter-SBOMs nicht verfügbar sind, oder als Mittel zur doppelten Überprüfung der Erstanbieter-SBOM.
BN: Was sehen Sie für die Zukunft von SBOMs? Open-Source-Schwachstellen und allgemeine Risiken in der Software-Lieferkette angehen?
TM: Wir stehen noch ganz am Anfang der SBOM-Ära. Die meisten Anbieter arbeiten immer noch daran, SBOMs zu erstellen, und das wird auf absehbare Zeit so bleiben. Obwohl ein Anbieter in der Lage ist, eine SBOM bereitzustellen, ist dies zwar ein Indikator für Open-Source-Sicherheitsgeschick, aber nicht der einzige Indikator. Wichtig ist, dass, wenn eine Organisation eine SBOM von einem Anbieter anfordert, aber keinen Workflow hat, um diese SBOM zu verarbeiten und daraus einen Wert abzuleiten, die Bereitstellung von SBOMs durch einen Anbieter zusätzliche Kosten ohne Nutzen bringt.
Interessanterweise sind viele gescheitert um festzustellen, dass die Sicherheitsanwendungsfälle für SBOMs häufig mit dem übereinstimmen, was Software Composition Analysis (SCA)-Lösungen bereits bieten. SBOMs sind am nützlichsten als Teil einer Gesamtrisikominderungsstrategie. Dies impliziert dann, dass Prozesse vorhanden sind, um das durch eine SBOM vermittelte Risiko zu messen, und dann einige Prozesse, um dieses Risiko zu mindern.
Bildnachweis: Momius/depositphotos.com