Dieser Beitrag ist der neunte Teil unserer Blogserie Tales From the Trenches: CRA Lessons Learned . Ziel dieser Serie ist es, Herstellern, Softwareanbietern und Anbietern vernetzter Produkte die praktischen Realitäten bei der Umsetzung von CRA-Compliance-Programmen näherzubringen. Dabei greifen wir auf Erkenntnisse aus der Zusammenarbeit mit unseren Kunden und aus Gesprächen mit Branchenführern zurück. Organisationen lernen zunehmend, dass nachhaltige Compliance Governance, Transparenz, Verantwortlichkeit und Lifecycle-Management-Fähigkeiten erfordert, die weit über klassische Cybersecurity-Aktivitäten hinausgehen. Ein sicheres Produkt zu bauen, reicht für CRA-Compliance nicht aus.

 

Warum der Cyber Resilience Act Risiken in der Software-Lieferkette zur Priorität für Führungskräfte macht

Jahrelang galt der Einsatz von Open-Source-Software weitgehend als Engineering-Entscheidung.

Entwickler wählten Bibliotheken aus. Architekten genehmigten Frameworks. Sicherheitsteams verfolgten Schwachstellen. Produktteams konzentrierten sich auf Funktionalität und Liefertermine. Die meisten Führungskräfte mussten sich kaum mit den Hunderten von Open-Source-Komponenten beschäftigen, die in ihren Produkten stecken.

Diese Zeiten sind vorbei.

Der Cyber Resilience Act (CRA) der Europäischen Union verändert die Sicht von Organisationen auf Software-Lieferketten – einschließlich Open-Source-Software. Was früher vor allem als technisches Thema betrachtet wurde, wird zunehmend zu einer Frage von Geschäft, Compliance und Governance.

Warum Open Source anders ist

Open-Source-Software treibt praktisch jedes vernetzte Produkt an. Anders als bei kommerzieller Software haben Hersteller in der Regel keine vertragliche Beziehung zu den Entwicklern, die diese Software erstellen und pflegen. Viele Open-Source-Projekte bieten keinen kommerziellen Support, keine garantierte Wartung und keine Service-Level-Zusagen.

Von Organisationen wird zunehmend erwartet, dass sie die Software in ihren Produkten verstehen, Transparenz über Abhängigkeiten wahren, schnell auf Schwachstellen reagieren und über den gesamten Produktlebenszyklus hinweg fortlaufende Governance nachweisen. Unter dem CRA gilt dies nicht nur für intern entwickelte oder von kommerziellen Anbietern lizenzierte Software, sondern auch für Open Source.

Dadurch verlagern sich Diskussionen über Open-Source-Software aus den Engineering-Teams in Führungssitzungen, Compliance-Reviews, Prüfungsausschüsse und Vorstandsetagen. Das Problem ist nicht, dass Open Source grundsätzlich riskant wäre. Das Problem sind Transparenz und Verantwortlichkeit.

Erkenntnisse für Führungskräfte

Eine zentrale Erkenntnis aus CRA-Readiness-Programmen lautet: Risiken in der Software-Lieferkette sind zu Geschäftsrisiken geworden. Historisch konzentrierten sich Unternehmen darauf, ob Open Source die Entwicklung beschleunigt, Kosten reduziert oder die Produktfunktionalität verbessert.

Vorstände sollten nicht nur fragen, welche Open-Source-Komponenten in ihren Produkten genutzt werden. Sie müssen auch berücksichtigen, welchen Einfluss diese Komponenten auf die CRA-Compliance haben. Dazu gehört zu klären, ob Projekte aktiv gepflegt werden, wie reif sie sind, ob sie kommerziell unterstützt werden, ob Prozesse für Schwachstellenmeldungen bestehen, wie schnell Schwachstellen behoben werden und ob nicht mehr unterstützte oder aufgegebene Komponenten weiterhin in ausgelieferten Produkten enthalten sind. Gibt es Support-Lücken, müssen Unternehmen feststellen, ob sie diese intern schließen können. In manchen Fällen haben sich große Unternehmen entschieden, Open-Source-Projekten beizutreten oder sie zu unterstützen, um nachhaltige Prozesse für Schwachstellenmeldung und -behebung aufzubauen.

Das sind keine reinen Engineering-Fragen. Es sind Governance- und Managementfragen. Unter dem CRA müssen Organisationen Transparenz über Softwareabhängigkeiten nachweisen, Prozesse zum Schwachstellenmanagement betreiben, koordinierte Offenlegung unterstützen und Belege für laufende Cybersecurity-Governance liefern.

Viele Führungsteams erkennen deshalb, dass der Einsatz von Open-Source-Software regulatorische Compliance, Kundenvertrauen, Produktsicherheit, Markenreputation und langfristige Support-Verpflichtungen unmittelbar beeinflusst.

Warum Open Source zu einer CRA-Herausforderung geworden ist

Open-Source-Software selbst ist nicht das Problem. Moderne Softwareentwicklung wäre ohne sie nahezu unmöglich. Die Herausforderung besteht darin, dass viele Open-Source-Projekte keinen kommerziellen Support, keine garantierte Wartung und keine Service-Level-Zusagen bieten.

Schwachstellen können mehrere Produkte betreffen

Eine Schwachstelle in einer weit verbreiteten Open-Source-Komponente kann Hunderte Produkte über mehrere Geschäftsbereiche hinweg betreffen. Unternehmen müssen betroffene Produkte, Versionen, Kundenexposition und verfügbare Gegenmaßnahmen schnell identifizieren können.

Fehlt die Transparenz, steigen die Reaktionszeiten drastisch.

Langfristiger Support schafft Verantwortung

Der CRA betont die Verantwortung über den Lebenszyklus hinweg. Unternehmen müssen Softwareabhängigkeiten während der gesamten unterstützten Lebensdauer eines Produkts verwalten können. Das wirft schwierige Fragen zu Open Source auf: Werden nicht mehr unterstützte oder aufgegebene Projekte eingesetzt? Wie werden Schwachstellen verfolgt? Wie kann das Unternehmen Schwachstellen in Open-Source-Software beheben? Kann es die Software selbst aktualisieren? Oder lassen sich Dienstleister oder Unternehmen finden, die langfristigen Support für kritische Komponenten anbieten?

Weit verbreiteter Einsatz von Open-Source-Software

Organisationen sind zunehmend von Open Source abhängig. Wenn Menschen an Open Source denken, kommen ihnen meist große Projekte wie OpenSSL, Linux oder PostgreSQL in den Sinn. Tatsächlich sind diese nur die Spitze des Eisbergs.

Eine einzelne Anwendung enthält typischerweise Laufzeitbibliotheken von Programmiersprachen, Entwicklungsframeworks (Spring, .NET-OSS-Pakete, React, Angular usw.), kryptografische Bibliotheken, Netzwerkbibliotheken, Build-Tools, JSON/XML-Parser und Logging-Frameworks. Jede dieser Komponenten kann wiederum von Dutzenden weiteren Paketen abhängen.

Beispiele aus der Praxis

Wie bei intern entwickelter Software ist auch die Transparenz über die Nutzung von Open Source für viele Organisationen schwierig. Wird eine kritische Schwachstelle in einer weit verbreiteten Bibliothek veröffentlicht, fragen Sicherheitsteams sofort, ob diese Komponente in den eigenen Produkten enthalten ist.

Die Antwort sollte einfach sein. Ohne zentrale und vollständige Dokumentation ist sie es oft nicht. Jedes Engineering-Team muss Code-Repositories, Dokumentationssysteme und Entwicklungsumgebungen durchsuchen, um die Betroffenheit festzustellen. Das kann Tage dauern – ein ernstes Problem angesichts der 24-Stunden-Meldepflicht des CRA.

Hinzu kommt die Natur von Open-Source-Projekten. Es gibt keinen vertraglich gebundenen Lieferanten, von dem Unternehmen Informationen zur Softwarezusammensetzung und zu Schwachstellen verlangen können. Der Hersteller muss seine Exposition oft selbst bestimmen.

Best Practices für das Management von Open-Source-Risiken unter dem CRA

Praktisch alle Unternehmen nutzen Open-Source-Software in ihren Produkten, auch wenn die Führungsebene sich dessen nicht bewusst ist. Als ersten Schritt sollten CRA-Compliance-Teams formale Akzeptanzkriterien für den Einsatz von Open Source definieren. Wichtige Kriterien sind Projektreife, Aktivität der Maintainer, Release-Takt, Sicherheitshistorie, Governance-Modell, Lizenzierung, Testpraktiken und langfristige Tragfähigkeit.

Das ist ein wichtiger Schritt, aber Akzeptanzkriterien wirken vor allem für die Zukunft. Sie helfen bei neuen Entwicklungsprojekten, lösen aber nicht die Nutzung von Open Source in Legacy-Produkten. Für CRA-konforme Open-Source-Risikoprogramme sind weitere Maßnahmen nötig.

Umfassende SBOMs pflegen

Unternehmen müssen SBOMs über den gesamten Produktlebenszyklus hinweg pflegen und aktualisieren und sicherstellen, dass jeder Einsatz von Open-Source-Software dokumentiert und überwacht wird. Sobald die genutzten Projekte identifiziert sind, müssen Unternehmen planen, wie sie diese Lösungen verwalten und unterstützen, um CRA-Compliance zu erreichen.

Support- und Migrationspläne festlegen

Sobald ein Inventar der genutzten Open-Source-Lösungen vorliegt, muss geklärt werden, wie diese Komponenten unterstützt werden. Unternehmen können einzelne Komponenten ablösen, Unterstützung von Drittanbietern suchen oder den Support selbst übernehmen.

Wegen der starken Abhängigkeit von Open Source befinden sich viele Unternehmen in einer schwierigen Lage. Eine Migration ist häufig nicht praktikabel, interner Support aber ebenso wenig. Manche Unternehmen unterstützen deshalb kritische Open-Source-Projekte finanziell. In anderen Fällen schließen sie Verträge mit Dienstleistern, die Support für die betreffenden Bibliotheken anbieten.

Schwachstellen kontinuierlich überwachen

Organisationen sollten neue Schwachstellen fortlaufend mit Softwareinventaren und eingesetzten Produkten abgleichen. Automatisierung kann die Reaktionsgeschwindigkeit deutlich erhöhen.

Häufige Fallstricke

Bei CRA-Readiness-Initiativen treten wiederkehrende Fehler auf.

Alle Open-Source-Projekte gleich behandeln

Es gibt Tausende weit verbreitete Open-Source-Projekte – von Projekten einzelner Entwickler bis zu großen, gut finanzierten Initiativen. Die Linux Foundation verfügt beispielsweise über ein Jahresbudget von mehr als 300 Millionen US-Dollar und unterstützt über 1.300 unterschiedliche Open-Source-Projekte.

Angesichts der Anzahl, Größe und Nutzung der Projekte überrascht es nicht, dass Qualität und Support stark variieren.

Beliebtheit mit Qualität gleichsetzen

Eine hohe Verbreitung garantiert weder höhere Qualität noch geringeres Sicherheitsrisiko. In manchen Fällen gilt das Gegenteil. Beliebte Projekte ziehen mehr Entwickler an, was zu uneinheitlicher Codequalität, erschwerter Prüfung und Testung von Änderungen sowie hohem Druck für neue Funktionen führen kann. Das kann die Codequalität beeinträchtigen und unerwartete Schwachstellen verursachen.

Große, komplexe und weit verbreitete Projekte sind zudem attraktive Ziele für Angreifer. Da der Quellcode öffentlich verfügbar ist, können Angreifer ihn nach ausnutzbaren Schwachstellen durchsuchen. Neue KI-Werkzeuge, die Code automatisiert auf Schwachstellen prüfen, erhöhen dieses Risiko zusätzlich. Angreifer können auch versuchen, sich als legitime Entwickler auszugeben und versteckte Backdoors oder Schwachstellen einzuschleusen. In großen Projekten mit vielen Beteiligten steigt das Risiko, dass bösartiger Code unbemerkt aufgenommen wird.

Auf nicht unterstützte Projekte vertrauen

Viele Open-Source-Projekte werden aktiv weiterentwickelt, aber längst nicht alle. Manche werden von Einzelpersonen oder kleinen Teams zur Lösung eines konkreten Problems geschaffen. Ist das Projekt abgeschlossen, wenden sich die Entwickler häufig anderen Aufgaben zu und pflegen die ursprüngliche Codebasis nicht weiter.

Für Unternehmen, die solche Projekte einsetzen, entsteht ein langfristiges Compliance-Risiko – besonders bei kritischen und langlebigen Produkten. Eine Schwachstelle kann lange nach Aufgabe des Projekts entdeckt werden. Unternehmen mit der betroffenen Komponente müssen das Problem dann selbst lösen. Je nach Komplexität ist das eine große Herausforderung. Möglicherweise fehlen intern die nötigen Kenntnisse. Selbst mit entsprechenden Fähigkeiten können Wochen vergehen, bis eine fremde Codebasis verstanden, der Fehler analysiert und eine Lösung entworfen ist.

SBOMs als reine Compliance-Dokumente behandeln

SBOMs sollten operative Werkzeuge sein, die Schwachstellenmanagement, Produkttransparenz und Lifecycle Governance unterstützen. Sie sind wichtige Compliance-Dokumentation, aber nur der Ausgangspunkt.

Maßnahmen für OEMs und Softwareanbieter

Organisationen, die Open-Source-Software in ihren CRA-Readiness-Programmen angemessen berücksichtigen möchten, sollten folgende Maßnahmen erwägen.

Sofortige Prioritäten

  1. Richtlinien für den Einsatz von Open-Source-Software festlegen.
  2. Vollständige Inventare aller Open-Source-Komponenten in allen Produkten erstellen.
  3. Freigegebene Open-Source-Projekte für die weitere Nutzung identifizieren.
  4. Migrationspläne erstellen, um nicht unterstützte, aufgegebene oder als hochriskant eingestufte Projekte abzulösen.
  5. Programme zur Überwachung von Schwachstellen in verwendeten Open-Source-Komponenten einführen.
  6. Reaktionspläne für Schwachstellen in verwendeten Open-Source-Komponenten erstellen. Dazu kann gehören, kommerzielle Support-Anbieter zu finden oder interne Ressourcen für den Support aufzubauen.
  7. Erwägen, für das Unternehmen kritische Open-Source-Projekte aktiv zu unterstützen.
  8. Klare Verantwortlichkeit für die Nutzung von Open-Source-Software im Unternehmen zuweisen.
  9. Richtlinien zur Open-Source-Nutzung und Pläne zur Schwachstellenbehebung dokumentieren.

Open-Source-Software wird bleiben. Organisationen benötigen jedoch kontinuierliche Transparenz über die Softwarekomponenten in ihren Produkten und die daraus entstehenden Risiken. Wenn sich Produkte, Abhängigkeiten und Schwachstellen verändern, muss sich auch dieses Verständnis mitentwickeln.

Wie OmniTrust Certify helfen kann

Open-Source-Software wird bleiben. Organisationen benötigen jedoch kontinuierliche Transparenz über die Softwarekomponenten in ihren Produkten und die daraus entstehenden Risiken. Wenn sich Produkte, Abhängigkeiten und Schwachstellen verändern, muss sich auch dieses Verständnis mitentwickeln.

OmniTrust Certify erstellt ein lebendes Produktprofil, das Softwarezusammensetzung, Schwachstellen, Cyberrisiken, regulatorische Anforderungen, Kontrollen und Nachweise über den gesamten Produktlebenszyklus hinweg verbindet.

Mit OmniTrust Certify können Organisationen:

  • SBOMs aus Quellcode, Binärdateien oder Firmware erzeugen oder vorhandene SBOMs einlesen
  • Open-Source- und Drittanbieter-Komponenten sowie Abhängigkeiten identifizieren
  • Neue Schwachstelleninformationen kontinuierlich überwachen und neue Schwachstellen betroffenen Produkten zuordnen
  • Bewerten, wie identifizierte Schwachstellen das Cybersecurity-Risiko eines Produkts beeinflussen
  • Prüfung, Behandlung, Minderung und Nachweise zu Schwachstellen nachverfolgen
  • Produkte gegen CRA-Anforderungen und weitere geltende Vorschriften und Standards bewerten
  • Kontinuierlich neu bewerten, wenn sich Produkte, Komponenten, Schwachstellen oder Anforderungen ändern

Anstatt eine SBOM als statisches Compliance-Dokument zu behandeln, verbindet Certify sie mit einem lebenden Produktdatensatz, der Unternehmen zeigt, was in ihren Produkten enthalten ist, was verwundbar ist, welche Risiken bestehen und welche Maßnahmen erforderlich sind.

Zusammenfassung: Open-Source-Software bleibt einer der größten Innovationstreiber. Der CRA rät nicht von ihrer Nutzung ab, verlangt jedoch einen verantwortungsvollen Umgang damit. Anders als bei kommerzieller Software übernehmen Organisationen Verantwortung, ohne vollständige Kontrolle zu besitzen. Erfolgreiche Hersteller werden nicht nur wissen, welche Open-Source-Software sie einsetzen, sondern auch Reife, Zustand, Supportfähigkeit und laufende Sicherheitslage jeder kritischen Abhängigkeit verstehen. Genau deshalb ist Open Source zu einem Thema für die Unternehmensleitung geworden.

Abonnieren Sie den Blog auf unserer Blog-Startseite, um über weitere Beiträge dieser Serie informiert zu werden. Weiter geht es mit „Blog #10: Bewertung ist einfach. Behebung ist schwer.“