Lieferketten-Resilienz in der Software – die berühmte „Software-BOM“. Eigentlich mit dem Ziel, nachvollziehen zu können, welche Komponenten in einem Software-Produkt verwendet werden, durch den CRA (Cyber Resilience Act) gefordert und eine wichtige Sache.
Aber: wie soll Software „sicher“ werden, nur wenn ich auf einmal deren Lieferkette kenne?
Die Annahme, man könne rein durch die Dokumentation der BOM mehr Sicherheit „in die Software“ bekommen, greift zu kurz!
In einem ersten Schritt entsteht mehr Sicherheit ausschließlich dadurch, dass man mehr weiß – also überhaupt mal eine Ahnung davon hat, wie viele 1000e (ja, echt) Bibliotheken und Drittkomponenten eingesetzt werden, damit ein Programm X läuft.
Im zweiten Schritt wird man feststellen, dass viele der Bibliotheken veraltet sind, aktualisiert werden müssten oder gar nicht verwendet werden – dadurch würde Software dann tatsächlich technisch sicherer. Aber das ist auch eine Menge Arbeit, nicht nur der Umbau, sondern vor allem auch der anschließend zwingend erforderliche Komplett-Test der Software.
Bei kommerziellen Bibliotheken oder Produkten in der Lieferkette können wir außerdem Lizenzen, AGB’s und SLA’s prüfen und die Vertrauenswürdigkeit des Herstellers bewerten. Kommen wir da zu einem negativen Ergebnis oder liegen Lizenzverletzungen vor, müssen Komponenten komplett getauscht werden. Iiih bäh…
Und dann noch die „Gretchenfrage“: was halten wir von Open Source?
Open Source ist zwar öffentlich einsehbar, aber dadurch alleine doch noch nicht „sicher“. Jeder kann sein Projekt auf Github veröffentlichen, unter eine Open Source Lizenz stellen und Sie dürfen das nutzen.
Denn „Open Source“ ist per se kein Qualitätskriterium, sondern nur eine Lizenz!
Die Qualität von Open Source entsteht dadurch, dass sich eine Community bildet, mehrere Leute das Projekt bearbeiten und nutzen, Fehler via Schwarmintelligenz gefunden und (hoffentlich) ausgebessert werden. Je größer das Projekt, je häufiger eingesetzt, desto wahrscheinlicher ist das auch. Bestrebungen, wie die OpenSSF Scorecard oder Best Practice Badges können helfen, sind aber nicht weit genug verbreitet.
Nur… hat das alles schon mal jemand für „unser“ Projekt geprüft? Oder „reicht“ es uns in der Lieferkette, wenn da „Open Source“ steht? Und – wer kann das überhaupt prüfen?
Wenn wir Cyber Resilienz wirklich ernst nehmen, dann müssen wir uns m.E. eine Ebene tiefer bewegen und nicht nur die Software-BOM aufstellen, sondern auch deren Inhalt bewerten – bis hin zum punktuellen Code- und Qualitäts-Review ausgewählter Open Source Komponenten. Nur dann können wir potenzielle Problem- oder Angriffsstellen identifizieren, eine ehrliche Bedrohungsanalyse vornehmen und das Risiko für ein Produkt oder Unternehmen einschätzen.
Gerade unter Berücksichtigung der aktuellen Geopolitischen Lage, sollten wir das Thema allerdings sehr, sehr ernst nehmen.