PHP2Shell, SBOMs und der Cyber Resilience Act

PHP2Shell zeigt dabei eine zentrale Schwierigkeit moderner Softwarelieferketten und zugehöriger Kommunikationsabläufe auf. Oftmals wissen Anwender gar nicht genau, welche externen Abhängigkeiten, Komponenten, Bibliotheken oder Technologien im produktiven Einsatz befindliche Lösungen oder Software verwenden. Gerade bei PHP ist das teilweise gar nicht so offensichtlich. Die Schwachstellen der einzelnen verwendeten Komponenten werden an das endgültige Produkt vererbt. Wird eine Schwachstelle einer genutzten Teilkomponente entdeckt, erfahren Kunden davon gegebenenfalls gar nicht oder nur mit Verzögerung, wenn der Hersteller des übergeordneten Produktes sich mit einem Update meldet.

Stellen Sie sich vor: Das Modell der Reifen, mit denen Ihr Neuwagen ausgeliefert wurde, weist einen chargenbedingten Produktionsfehler auf, durch den die Reifen frühzeitig übermäßig porös werden und daher unverzüglich auszutauschen sind. Neben dem Hersteller Ihres Wagens liefern selbstverständlich auch andere Automobilhersteller ihre Neuwagen mit Reifen dieses Herstellers aus. Die erste Meldung über die Schwachstelle sollte vom Hersteller der Reifen erfolgen. Bis Ihr Automobilhersteller diese Meldung aber weiterreicht, kann wichtige Zeit vergehen. Welche Reifen Sie verwenden, können Sie für gewöhnlich auf dem Reifen selbst erkennen, sodass Sie nicht zwingend auf die Meldung des Automobilherstellers angewiesen sind und direkt auf den Reifenhersteller achten können.

Was hat das nun mit Software zu tun? Externe Komponenten einer Software lassen sich nicht so leicht erkennen, wie Hersteller und Modell der Reifen Ihres Autos. Eine Software Bill of Materials (SBOM) setzt an genau dieser Stelle an. Etwas vereinfacht handelt es sich bei einer SBOM um ein Verzeichnis aller von einem Softwareprodukt genutzten externen Bibliotheken, Komponenten oder Abhängigkeiten inkl. genutzter Version, das in einem standardisierten und nach Möglichkeit maschinenlesbaren Format vom Hersteller der Software bereitgestellt werden sollte. Für die Erstellung von SBOMs gibt es z.B. vom BSI die Technische Richtlinie TR-03183-2, die entsprechende Vorgaben beschreibt.

Eine SBOM stellt somit ein sofort verfügbares Software-Inventar spezifisch für ein bestimmtes im Einsatz befindliches Produkt dar. Die Vorteile liegen auf der Hand:

• Es muss nicht manuell oder in Rücksprache mit dem Hersteller überprüft werden, welche Drittkomponenten in der Software verwendet werden.
• Offenbart die SBOM eines Produkts z.B., dass es PHP in einer der von PHP2Shell betroffenen Versionen verwendet, könnten IT-Abteilungen sofort mit ersten Maßnahmen reagieren und müssen nicht auf Meldungen des Herstellers warten.
• In maschinenlesbarem Format kann der Abgleich von SBOMs mit Schwachstellendatenbanken automatisiert erfolgen.

Die Verwendung von SBOMs schafft also Klarheit im Notfall, wenn schnelles Reagieren elementar ist. Daher sollte es künftig ein zentraler Bestandteil von Beschaffungsprozessen für Software und andere digitale Produkte sein, eine solche Dokumentation zur Risikobeurteilung einzufordern oder zumindest darauf zu bestehen, dass der Hersteller eine entsprechende Dokumentation führt und bei Bedarf vorlegen kann. In Zukunft sind Hersteller zur Erstellung von SBOMs verpflichtet: Bis Ende 2027 soll der Cyber Resilience Act der EU in Kraft treten, der Hersteller sogenannter Produkte mit digitalen Elementen u.a. zur Erstellung einer SBOM verpflichtet.