1. Einleitung
1.1 Funktion dieser Serie
Der Sinn einer Compliance liegt darin, in Übereinstimmung mit den Gesetzen zu arbeiten und Folgen wie z.B. Schadensersatzansprüche zu vermeiden.
Die Compliance von Open Source kann in zwei Richtungen erfolgen.
Einmal in die Richtung der IT-Sicherheit und einmal im Hinblick auf die rechtliche Compliance.
1.2 IT-Sicherheit
Es gibt heute schon und es entstehen immer mehr Richtlinien auf der Ebene der best practises, die aus der Sicht der Cyberresilliance (wir erinnern uns, OSS kommt meist über das Internet) einen Scan der Software unter technischen Gesichtspunkten fordern. Das BSI plant eine Risikobewertung für die Komponenten, die dann nur entsprechend einem bestimmten Used Case eingesetzt werden sollen. Außerdem will das BSI dann Sicherheitswarnungen herausgeben, die bestimmte Komponenten erfassen und die bewirken sollen, dass auf diese Art und Weise eine Alarmmeldung zur Meidung eines Flächenbrandes führt.
SBOM
Spätestens, nachdem das BSI mit der TR 03183 „Cyber Resilliance Anforderung“ Anforderungen für eine SBOM (Software Bill of Material) veröffentlich hat, ist der Begriff SBOM bekannt geworden.
Die SBOM ist das Inhaltsverzeichnis des Systems, welches aufzeigt, was die eigenen und was die Drittkomponenten sind. Das BSI verfolgt mit der SBOM die Absicht, eine Leitlinie der Dokumentation zu erstellen, die der Produktsicherheit dient. Man schaue sich die Anforderungen unter den Punkten 5.2 und 5.3 der RL an. Der CRA verweist zwar nicht auf die SBOM, das BSI will diese Informationen aber für die Konformitätserklärungen verwenden. Und auch im Rahmen der Einhaltung der IT-Sicherheitsgesetze wie insb. der NIS-2-RL wird man sich – sofern man Leistungen in der /über die Cloud anbietet – mit der SBOM auseinandersetzen, die strukturell so aufgebaut ist wie es das BSI fordert. Einfach deshalb, weil das BSI die Autorität und die Macht hat, einen Standard zu setzen, auf den sich dann die meisten beziehen.
