Python-Projekt. Bibliothek fehlt. Mal eben nachinstallieren…. so der Plan.
Was dann passiert zeigt, wie absurd manche Qualitätsansprüche sind: ich möchte eine einzige Bibliothek installieren und die lädt dann über 100 weitere Bibliotheken automatisch mit dazu.
Schön – alles ist in der Software BOM vermerkt, alles ist nachvollziehbar dokumentiert. Nimmt mir ne Menge Arbeit ab.
Aber hey – wer kennt das ganze Zeug denn wirklich, was hier einfach mal so nachgeladen wird? Wer hat sich angesehen, dass alle diese Komponenten auch “in Ordnung” sind und keinen Unfug treiben?
Ach so – das meiste ist Open Source? Na dann ist’s ja gut.
Nope. Auch nicht. Nur weil etwas quelloffen ist, heißt es noch lange nicht, dass es auch gut ist. Oder dass das irgendwann mal irgendwer überprüft hat.
Auch wenn es Organisationen, Stiftungen, Communities gibt, die regelmäßig Audits auf bestimmten (und nur sehr wenigen ausgewählten) Open Source Projekten durchführen – die Grauzone ist riesig.
Nun werden wir aber seitens des Gesetzgebers aufgefordert, eine SBOM für unsere Software bereitzustellen und zu dokumentieren. Das ist ein richtiger, wichtiger und absolut sinnvoller Schritt. Löst aber noch kein Problem.
Denn erst, wenn wir mit dieser SBOM arbeiten, sie analysieren, Risiken einordnen und ggfs. auch mal selbst einen Blick in die verwendeten Komponenten werfen, entsteht daraus das, was man eigentlich haben möchte:
Digitale Souveränität – mit bewussten Risiken und Nebenwirkungen.
#informatikersindcool #oleolesupersbom #opensourcealleinemachtnichtglücklich
