Der Cyber Resilience Act (CRA) und das Management von Open Source

Open Source ist allgegenwärtig: Kaum ein Produkt kommt heute ohne digitale Komponenten aus, von elektrischen Zahnbürsten, Babymonitoren bis hin zu Smartwatches. Weniger offensichtlich für viele Benutzer ist das Sicherheitsrisiko, das solche Produkte und die inbegriffene Software darstellen können.

Der neue europäische Cyber Resilience Act zielt darauf ab, dass Verbraucher sichere Produkte erhalten. Die Verordnung wurde in der EU-Cybersicherheitsstrategie 2020 angekündigt und ergänzt andere Rechtsvorschriften in diesem Bereich, insbesondere den NIS2-Rahmen (zweite EU -Richtlinie zur Netzwerk- und Informationssicherheit). Die CRA-Vereinbarung wurde im März 2024 vom Europäischen Parlament förmlich angenommen.

Die CRA deckt ein breites Spektrum von Anforderungen an „Produkte mit digitalen Elementen“ ab. Dies sind alle Soft- und Hardwareprodukte sowie „Remote“-Datenverarbeitungslösungen, ohne die eine beabsichtigte Funktion des jeweiligen Produkts mit digitalen Elementen nicht ausgeführt werden könnte. Die Anforderungen umfassen unter anderem:

• Die Cybersicherheit wird in der Planungs-, Entwurfs-, Entwicklungs-, Produktions-, Liefer- und Wartungsphase berücksichtigt.
• Alle Cybersicherheitsrisiken werden dokumentiert.
• Hersteller müssen aktiv ausgenutzte Schwachstellen und Zwischenfälle melden.
• Nach dem Verkauf eines Produkts müssen die Hersteller sicherstellen, dass während der voraussichtlichen Lebensdauer des Produkts oder während eines Zeitraums von fünf Jahren eventuelle Schwachstellen wirksam beseitigt werden.
• Klare und verständliche Anweisungen für die Verwendung von Produkten mit digitalen Elementen.

Mit dem Cyber Resilience Act (CRA) hat die Europäische Union Regulierung für die Themen Cybersicherheit, IKT-Risiken und digitale operationale Resilienz geschaffen. Die zentrale Forderung lautet:

Alle Bestandteile der Software müssen kontinuierlich auf Sicherheitslücken geprüft werden!

Anbieter von kommerziell vertriebenen Produkten müssen die Pflichten aus der Verordnung erfüllen. Open Source Entwickler wurden von dem Anwendungsbereich der Verordnung ausgenommen. Die Pflichten darauf bezogen sind erst zu erfüllen, wenn Open Source als Bestandteil eines „Produkts mit digitalen Elementen“ kommerziell genutzt wird.

Beispiel

Ein Unternehmen „Agentur Abenteuerlich“ verbaut Chips als Bestandteile seines Produkts. Das Unternehmen muss sich darauf verlassen können, dass diese sicher konzipiert sind und benötigt für eine gewisse Zeit Sicherheitsupdates vom Lieferanten „Büro Besserwisser“, um die Sicherheit entlang der Lieferkette zu gewährleisten. Nach dem CRA muss das Büro Besserwisser nachweisen, dass es bei Entwicklung und Produktion EU-harmonisierte Cybersicherheitsnormen eingehalten hat. Das wird über eine sogenannte Software-Stückliste (SBOM) dokumentiert. Der Lieferant muss auch Schwachstellen dokumentieren, von denen er Kenntnis erlangt hat. Vor Inverkehrbringen des Chips muss er ein Konformitätsbewertungsverfahren durchführen, erst dann darf die CE-Kennzeichnung angebracht werden. Die Agentur Abenteuerlich muss auch für ihren Teil der Lieferkette all dies tun. Beide Unternehmen müssen auch nach Inverkehrbringen von Chip und Produkt Updates bereitstellen sowie Melde- und Informationspflichten erfüllen; Agentur Abenteuerlich hat dafür zu sorgen dass dies mit geeigneten Verträgen auch für alle Lieferanten gewährleistet ist.

Die Software-Stückliste SBOM

Die kommerziellen Bestandteile einer SBOM lassen sich in der Regel leicht ermitteln: Anhand der Liste der Lieferanten sind die kommerziellen Bestandteile schnell aufgefunden. Schwieriger ist dies mit den Open-Source-Bestandteilen: „Unter freier und quelloffener Software ist eine Software zu verstehen, deren Quellcode offen geteilt wird und in deren Lizenz alle erforderlichen Rechte vorgesehen sind, um sie frei zugänglich, nutzbar, veränderbar und weiterverteilbar zu machen.“ (Punkt Nr. 18., Standpunkt des Europäischen Parlaments vom 12. März 2024)

Gerade bei Open Source besteht jedoch ein wesentliches Risiko für Sicherheitslücken, insbesondere bei Projekten, die keine aktive Community besitzen oder nur von einzelnen Maintainern betreut werden.

Das BSI hat bereits eine technische Richtlinie mit den Minimalangaben einer SBOM erstellt.

Um die SBOM aufzubauen gibt es mittlerweile eine Vielzahl von kommerziellen und freien Werkzeugen. Einige versprechen eine SBOM in wenigen Minuten zu erstellen – hierbei werden in der Regel dann nur die Hauptkomponenten und Abhängigkeiten in einem Repository ausgelesen. Das Problem hierbei ist, dass diese SBOM in der Regel weder vollständig noch korrekt ist. Nach unserer Erfahrung gibt es kein Werkzeug, welches bei beliebigen Softwareprojekten alle Tätigkeiten zur Erstellung einer korrekten, ausführlichen und belastbaren SBOM zu kommen automatisch durchführen kann. Hierzu bedarf es eines „Open Source Auditors“, welcher die in Werkzeugen gefunden Indizien validiert, recherchiert und gegebenenfalls ergänzt. Oft verstecken sich Open-Source-Komponenten innerhalb einer größeren Komponente, oder Entwickler haben nur einzelne Bruchstücke eines anderen Open-Source-Projekte kopiert. Hinweise darauf können Copyright-Hinweise, E-Mail-Adressen oder URLs im Code sein. Manche Kennzeichnungen in Open-Source-Projekten sind auch einfach offensichtlich falsch, insbesondere in maven oder github.

Eine SBOM zu erstellen ist nicht einfach. Die folgende Grafik zeigt einen Vergleich zwischen der Anzahl der vom Entwicklungsteam bekannten Open Source Komponenten (grau), zu der Anzahl der Komponenten die tatsächlich nach einem ausführlichen Scan gefunden wurden (rot):

Durch den steigenden Einsatz von KI in der Softwareentwicklung wird ein weiterer rapider Anstieg der genutzten Open-Source-Fragmente vorhergesagt.

Ist eine vollständige SBOM einmal erstellt, kann sie leicht automatisiert nach neuen bekannten Sicherheitslücken überprüft werden. Allerdings erfordern Änderungen an den Software-Komponenten beizeiten eine aktualisierte SBOM.

Die Software Lieferkette („software supply chain“)

Eine vollständige SBOM deckt alle Bestandteile über die gesamte Software-Lieferkette ab. Nicht nur die selbst komponierte Software muss geprüft werden, auch alle von Lieferanten gelieferten Elemente, und Komponenten von deren Lieferanten. Da Software in der Regel kompiliert und nicht einsehbar geliefert wird, sind Subunternehmer und Lieferanten in der Pflicht ebenfalls eine aussagekräftige SBOM zu liefern. Dies muss daher von Unternehmen eingefordert werden.

Fazit

Eine aussagekräftige und belastbare Software-Stückliste ist ein elementarer Baustein um den Cyber-Resilience-Act (CRA) erfüllen zu können. Mit ihr können alle Bestandteile der Software kontinuierlich auf Sicherheitslücken geprüft werden! Gerne unterstützt Sie Bitsea bei der Erarbeitung derselben, sowie allen weiteren Tätigkeiten zum Management von Open Source.