Weg mit der SBOM – Sicherheit der Software-Lieferkette

Es ist eine große Bewegung im Gange, um zu einer SBOM-orientierten IT-Welt überzugehen. SBOM steht für eine „Software Bill of Materials“. Die Idee dahinter ist, dass jede Software oder Dienstleistung mit einem Etikett versehen sein sollte, auf dem alle Softwarekomponenten aufgeführt sind, die zur Herstellung des Produkts gehören.

Auf diese Weise wird jede Schwachstelle in einer Komponente, die nicht behoben wird, für Kunden sichtbar. Andy Ellis, Advisory CISO bei Orca Security, erläutert die Vor- und Nachteile von SBOM (Software Bill of Materials) vor dem Hintergrund der Debatte um die Sicherheit der Software-Supply-Chain:

„Das SBOm-Konzept klingt simpel. Einfach nur die Software notieren, die beim Zusammenbau des Systems verwendet wurde!

„Nur“ ist das gefährlichste Wort in der Cybersicherheit. In jedem komplexen System gibt es den Impuls, ein viel einfacheres Modell zu verwenden, um das System zu beschreiben. Oftmals kann dies hilfreich sein, weil es das System einfacher macht, darüber nachzudenken. Leider sind Lösungen, die in einfachen Systemen anwendbar sind, in komplexeren Systemen meist nicht so einfach – und schon gar nicht so effektiv.

Software ist kein abgepacktes Lebensmittel

Das Modell der Kennzeichnung von Lebensmittelzutaten wird oft als Rechtfertigung für die Veröffentlichung von SBOMs herangezogen. Auch wenn die Lebensmittelversorgungskette noch so komplex ist, liegt der Zutatenliste Chemie zugrunde. Auch wenn Zucker noch so kompliziert ist (Dextrose, Saccharose usw.), gibt es letztendlich nur eine Handvoll Möglichkeiten, Zucker (oder zuckerfreie Süßstoffe) zu verwenden. Softwarekomponenten hingegen ändern sich ständig. Man stelle sich vor, man kaufe ein Lebensmittel und auf dem Zutatenetikett steht „gnusugar-12.17.64-bigpharma-5.2.4.a“, und morgen könnte sich das ändern in „gnusugar-12.17.66-bigpharma-5.2.4.b“. Für manche Menschen mag das nützlich sein, aber das ist ein Grad an Komplexität, der aus der Lebensmittelversorgungskette herausgenommen wird. Kunden bestehen nicht darauf, dass eine Zutatenliste die genaue Herkunft jeder Zutat enthält, aber die Herkunft ist ein Hauptziel von SBOMs.

Ein perverser Anreiz: Software soll wie ein abgepacktes Lebensmittel sein

Die Lieblingszutat des Autors beim Lebensmitteleinkauf ist „Gewürze“ (oder „künstliche und natürliche Aromastoffe“). Nach der Überprüfung auf Allergene ist dies die wichtigste Zutat, auf die er achtet (wie viel Schärfe hat es genau?), und doch herrscht hier keinerlei Transparenz. SBOMs haben auch einen eingebauten Fehler, der einen Ort schafft, um sich vor der Transparenz zu verstecken: in intern entwickelter Software. Die Software, die ein Unternehmen von Dritten bezieht, muss in den SBOMs auftauchen, und zwar in einer Art und Weise, die, so undurchsichtig die Formulierungen auch sein mögen, dennoch durchgängig entzifferbar ist. Aber was ist mit der Software, die ein Unternehmen selbst schreibt? Da sie proprietär ist, handelt es sich im Grunde um „Gewürze“.

Warum ist das wichtig? Ein Beispiel ist ein Softwareentwickler, der eine Open-Source-Software in seiner Komponente verwenden möchte. Wenn er das tut, muss er diese Unterkomponente für immer im Auge behalten und sich mit internen und externen Anfragen auseinandersetzen, warum er sie nicht kürzlich aktualisiert hat. Wenn Unternehmen stattdessen ihre eigene Version schreiben, muss nichts in die SBOM aufgenommen werden, selbst wenn sie nicht so gut funktioniert! Erscheint es unwahrscheinlich, dass ein Ingenieur diese Entscheidung treffen könnte? Man denke an die Ingenieure bei Volkswagen, die Dieselmotoren entwickeln. Produktmanager, denen in diesem Zusammenhang etwas Kopfschmerzen bereitet, werden Druck ausüben, der genau darauf ausgerichtet ist, „Komponenten von Drittanbietern nicht öffentlich anzuerkennen“.

Softwaredienste sind wie Restaurants

Der Kauf eines Softwaredienstes ist keineswegs mit dem Kauf eines verpackten Lebensmittels zu vergleichen, sondern mit der Inanspruchnahme einer Dienstleistung. Der Dienst selbst ist eine integrierte Lieferkette, die aus einer Reihe von Softwareprodukten besteht, und jedes dieser Produkte würde in den Anwendungsbereich einer Stückliste fallen. Man stelle sich eine Liste der Lebensmittelzutaten vor, die nicht nur die tatsächlichen Chemikalien in den Lebensmitteln enthält, sondern auch jedes Gerät in der Küche, jedes Kleidungsstück des Küchenpersonals sowie die persönlichen Hygieneprodukte, die jeder heute verwendet. Das gilt auch für die Lieferkette des Restaurants. Jeder der Lieferanten, von den nationalen Lebensmittelketten bis hin zu den örtlichen Bauernhöfen, müsste dem Restaurant dieselben Informationen zur Verfügung stellen. Das ist eine riesige Liste, die für den Verbraucher oft ohne Kontext ist.

Ein Verbraucher mit einer so umfangreichen Liste wird für die Unternehmen jedoch zu einem Kostenfaktor. Je größer die Liste der Informationen ist, die sie Kunden zur Verfügung stellen, desto höher sind die Kosten für die bloße Beantwortung möglicher Anfragen. Jeder Kunde hat vielleicht ein bestimmtes Spezialgebiet, und in diesem Bereich wird er sich wohl fühlen, wenn er die geschäftlichen Entscheidungen des Anbieters in Frage stellt, vor allem, wenn diese Entscheidungen für ihn sichtbar sind. Einige davon mögen gut gemeint sein („Warum gibt es irgendwo in Ihrer Lieferkette eine veraltete Version von OpenSSL?“), andere wiederum könnten einfach nur kleinliche Reibereien sein („Ich arbeite an Komponente X, warum haben Sie die konkurrierende Komponente Y in Ihrer Software verwendet!“). Und einige der Anfragen werden aus der Verwirrung herrühren. Reinigungsmittel im Essen wären giftig, aber völlig unbedenklich, wenn sie nur zum Reinigen des Küchenbodens verwendet würden. Wie aber kann ein Verbraucher das anhand einer Liste von Materialien feststellen?

Sind SBOMs etwas Schlimmes?

Ganz und gar nicht! Der Grenzwert einer äußerlich sichtbaren SBOM ist bestenfalls vernachlässigbar, schlimmstenfalls ist er negativ. Aber eine interne SBOM? Diese hat einen enormen Wert. Jedes Stück Software, das ein Unternehmen verwendet, sollte diesem Unternehmen bekannt sein. Sicherheitsverantwortliche sollten in der Lage sein, jede Teilkomponente zu identifizieren und zu verstehen, welche Schwachstellen in dieser Teilkomponente vorhanden sein könnten und wie relevant diese Schwachstellen für ihre Verwendung der Teilkomponente sind. Sie sollten wissen, wie gut ihre Entwicklungsteams problematische Software im Auge behalten und ob sie bei der Behebung von Problemen Prioritäten setzen, die der Risikotoleranz ihres Unternehmens entsprechen. Aber die Veröffentlichung dieser detaillierten Daten? Das wird teuer, sowohl in der Produktion als auch in der Pflege der Kundenbeziehungen, und bringt keinen erheblichen Nutzen, um die Softwarelieferkette sicher zu machen.“