{"id":17785,"date":"2026-09-11T15:38:03","date_gmt":"2026-09-11T22:38:03","guid":{"rendered":"https:\/\/www.omnitrust.com\/blog\/eu-cra-tales-from-the-trenches-9-open-source-software-ist-jetzt-ein-thema-fuer-die-unternehmensleitung\/"},"modified":"2026-09-11T15:38:03","modified_gmt":"2026-09-11T22:38:03","slug":"eu-cra-tales-from-the-trenches-9-open-source-software-ist-jetzt-ein-thema-fuer-die-unternehmensleitung","status":"publish","type":"post","link":"https:\/\/www.omnitrust.com\/de\/blog\/eu-cra-tales-from-the-trenches-9-open-source-software-ist-jetzt-ein-thema-fuer-die-unternehmensleitung\/","title":{"rendered":"EU CRA Tales From The Trenches #9 \u2013 Open-Source-Software ist jetzt ein Thema f\u00fcr die Unternehmensleitung"},"content":{"rendered":"

Dieser Beitrag ist der neunte Teil unserer Blogserie Tales From the Trenches: CRA Lessons Learned <\/em>. Ziel dieser Serie ist es, Herstellern, Softwareanbietern und Anbietern vernetzter Produkte die praktischen Realit\u00e4ten bei der Umsetzung von CRA-Compliance-Programmen n\u00e4herzubringen. Dabei greifen wir auf Erkenntnisse aus der Zusammenarbeit mit unseren Kunden und aus Gespr\u00e4chen mit Branchenf\u00fchrern zur\u00fcck. Organisationen lernen zunehmend, dass nachhaltige Compliance Governance, Transparenz, Verantwortlichkeit und Lifecycle-Management-F\u00e4higkeiten erfordert, die weit \u00fcber klassische Cybersecurity-Aktivit\u00e4ten hinausgehen. Ein sicheres Produkt zu bauen, reicht f\u00fcr CRA-Compliance nicht aus.<\/p>\n

 <\/p>\n

Warum der Cyber Resilience Act Risiken in der Software-Lieferkette zur Priorit\u00e4t f\u00fcr F\u00fchrungskr\u00e4fte macht<\/h2>\n

Jahrelang galt der Einsatz von Open-Source-Software weitgehend als Engineering-Entscheidung.<\/p>\n

Entwickler w\u00e4hlten Bibliotheken aus. Architekten genehmigten Frameworks. Sicherheitsteams verfolgten Schwachstellen. Produktteams konzentrierten sich auf Funktionalit\u00e4t und Liefertermine. Die meisten F\u00fchrungskr\u00e4fte mussten sich kaum mit den Hunderten von Open-Source-Komponenten besch\u00e4ftigen, die in ihren Produkten stecken.<\/p>\n

Diese Zeiten sind vorbei.<\/p>\n

Der Cyber Resilience Act (CRA) der Europ\u00e4ischen Union ver\u00e4ndert die Sicht von Organisationen auf Software-Lieferketten \u2013 einschlie\u00dflich Open-Source-Software. Was fr\u00fcher vor allem als technisches Thema betrachtet wurde, wird zunehmend zu einer Frage von Gesch\u00e4ft, Compliance und Governance.<\/p>\n

Warum Open Source anders ist<\/em><\/strong><\/p>\n

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.<\/p>\n

Von Organisationen wird zunehmend erwartet, dass sie die Software in ihren Produkten verstehen, Transparenz \u00fcber Abh\u00e4ngigkeiten wahren, schnell auf Schwachstellen reagieren und \u00fcber den gesamten Produktlebenszyklus hinweg fortlaufende Governance nachweisen. Unter dem CRA gilt dies nicht nur f\u00fcr intern entwickelte oder von kommerziellen Anbietern lizenzierte Software, sondern auch f\u00fcr Open Source.<\/p>\n

Dadurch verlagern sich Diskussionen \u00fcber Open-Source-Software aus den Engineering-Teams in F\u00fchrungssitzungen, Compliance-Reviews, Pr\u00fcfungsaussch\u00fcsse und Vorstandsetagen. Das Problem ist nicht, dass Open Source grunds\u00e4tzlich riskant w\u00e4re. Das Problem sind Transparenz und Verantwortlichkeit.<\/p>\n

Erkenntnisse f\u00fcr F\u00fchrungskr\u00e4fte<\/h2>\n

Eine zentrale Erkenntnis aus CRA-Readiness-Programmen lautet: Risiken in der Software-Lieferkette sind zu Gesch\u00e4ftsrisiken geworden. Historisch konzentrierten sich Unternehmen darauf, ob Open Source die Entwicklung beschleunigt, Kosten reduziert oder die Produktfunktionalit\u00e4t verbessert.<\/p>\n

Vorst\u00e4nde sollten nicht nur fragen, welche Open-Source-Komponenten in ihren Produkten genutzt werden. Sie m\u00fcssen auch ber\u00fccksichtigen, welchen Einfluss diese Komponenten auf die CRA-Compliance haben. Dazu geh\u00f6rt zu kl\u00e4ren, ob Projekte aktiv gepflegt werden, wie reif sie sind, ob sie kommerziell unterst\u00fctzt werden, ob Prozesse f\u00fcr Schwachstellenmeldungen bestehen, wie schnell Schwachstellen behoben werden und ob nicht mehr unterst\u00fctzte oder aufgegebene Komponenten weiterhin in ausgelieferten Produkten enthalten sind. Gibt es Support-L\u00fccken, m\u00fcssen Unternehmen feststellen, ob sie diese intern schlie\u00dfen k\u00f6nnen. In manchen F\u00e4llen haben sich gro\u00dfe Unternehmen entschieden, Open-Source-Projekten beizutreten oder sie zu unterst\u00fctzen, um nachhaltige Prozesse f\u00fcr Schwachstellenmeldung und -behebung aufzubauen.<\/p>\n

Das sind keine reinen Engineering-Fragen. Es sind Governance- und Managementfragen. Unter dem CRA m\u00fcssen Organisationen Transparenz \u00fcber Softwareabh\u00e4ngigkeiten nachweisen, Prozesse zum Schwachstellenmanagement betreiben, koordinierte Offenlegung unterst\u00fctzen und Belege f\u00fcr laufende Cybersecurity-Governance liefern.<\/p>\n

Viele F\u00fchrungsteams erkennen deshalb, dass der Einsatz von Open-Source-Software regulatorische Compliance, Kundenvertrauen, Produktsicherheit, Markenreputation und langfristige Support-Verpflichtungen unmittelbar beeinflusst.<\/p>\n

Warum Open Source zu einer CRA-Herausforderung geworden ist<\/h2>\n

Open-Source-Software selbst ist nicht das Problem. Moderne Softwareentwicklung w\u00e4re ohne sie nahezu unm\u00f6glich. Die Herausforderung besteht darin, dass viele Open-Source-Projekte keinen kommerziellen Support, keine garantierte Wartung und keine Service-Level-Zusagen bieten.<\/p>\n

Schwachstellen k\u00f6nnen mehrere Produkte betreffen<\/em><\/strong><\/p>\n

Eine Schwachstelle in einer weit verbreiteten Open-Source-Komponente kann Hunderte Produkte \u00fcber mehrere Gesch\u00e4ftsbereiche hinweg betreffen. Unternehmen m\u00fcssen betroffene Produkte, Versionen, Kundenexposition und verf\u00fcgbare Gegenma\u00dfnahmen schnell identifizieren k\u00f6nnen.<\/p>\n

Fehlt die Transparenz, steigen die Reaktionszeiten drastisch.<\/p>\n

Langfristiger Support schafft Verantwortung<\/em><\/strong><\/p>\n

Der CRA betont die Verantwortung \u00fcber den Lebenszyklus hinweg. Unternehmen m\u00fcssen Softwareabh\u00e4ngigkeiten w\u00e4hrend der gesamten unterst\u00fctzten Lebensdauer eines Produkts verwalten k\u00f6nnen. Das wirft schwierige Fragen zu Open Source auf: Werden nicht mehr unterst\u00fctzte 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\u00fcr kritische Komponenten anbieten?<\/p>\n

Weit verbreiteter Einsatz von Open-Source-Software<\/em><\/strong><\/p>\n

Organisationen sind zunehmend von Open Source abh\u00e4ngig. Wenn Menschen an Open Source denken, kommen ihnen meist gro\u00dfe Projekte wie OpenSSL, Linux oder PostgreSQL in den Sinn. Tats\u00e4chlich sind diese nur die Spitze des Eisbergs.<\/p>\n

Eine einzelne Anwendung enth\u00e4lt 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\u00e4ngen.<\/p>\n

Beispiele aus der Praxis<\/em><\/strong><\/p>\n

Wie bei intern entwickelter Software ist auch die Transparenz \u00fcber die Nutzung von Open Source f\u00fcr viele Organisationen schwierig. Wird eine kritische Schwachstelle in einer weit verbreiteten Bibliothek ver\u00f6ffentlicht, fragen Sicherheitsteams sofort, ob diese Komponente in den eigenen Produkten enthalten ist.<\/p>\n

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

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\u00f6nnen. Der Hersteller muss seine Exposition oft selbst bestimmen.<\/p>\n

Best Practices f\u00fcr das Management von Open-Source-Risiken unter dem CRA<\/h2>\n

Praktisch alle Unternehmen nutzen Open-Source-Software in ihren Produkten, auch wenn die F\u00fchrungsebene sich dessen nicht bewusst ist. Als ersten Schritt sollten CRA-Compliance-Teams formale Akzeptanzkriterien f\u00fcr den Einsatz von Open Source definieren. Wichtige Kriterien sind Projektreife, Aktivit\u00e4t der Maintainer, Release-Takt, Sicherheitshistorie, Governance-Modell, Lizenzierung, Testpraktiken und langfristige Tragf\u00e4higkeit.<\/p>\n

Das ist ein wichtiger Schritt, aber Akzeptanzkriterien wirken vor allem f\u00fcr die Zukunft. Sie helfen bei neuen Entwicklungsprojekten, l\u00f6sen aber nicht die Nutzung von Open Source in Legacy-Produkten. F\u00fcr CRA-konforme Open-Source-Risikoprogramme sind weitere Ma\u00dfnahmen n\u00f6tig.<\/p>\n

Umfassende SBOMs pflegen<\/em><\/strong><\/p>\n

Unternehmen m\u00fcssen SBOMs \u00fcber den gesamten Produktlebenszyklus hinweg pflegen und aktualisieren und sicherstellen, dass jeder Einsatz von Open-Source-Software dokumentiert und \u00fcberwacht wird. Sobald die genutzten Projekte identifiziert sind, m\u00fcssen Unternehmen planen, wie sie diese L\u00f6sungen verwalten und unterst\u00fctzen, um CRA-Compliance zu erreichen.<\/p>\n

Support- und Migrationspl\u00e4ne festlegen<\/em><\/strong><\/p>\n

Sobald ein Inventar der genutzten Open-Source-L\u00f6sungen vorliegt, muss gekl\u00e4rt werden, wie diese Komponenten unterst\u00fctzt werden. Unternehmen k\u00f6nnen einzelne Komponenten abl\u00f6sen, Unterst\u00fctzung von Drittanbietern suchen oder den Support selbst \u00fcbernehmen.<\/p>\n

Wegen der starken Abh\u00e4ngigkeit von Open Source befinden sich viele Unternehmen in einer schwierigen Lage. Eine Migration ist h\u00e4ufig nicht praktikabel, interner Support aber ebenso wenig. Manche Unternehmen unterst\u00fctzen deshalb kritische Open-Source-Projekte finanziell. In anderen F\u00e4llen schlie\u00dfen sie Vertr\u00e4ge mit Dienstleistern, die Support f\u00fcr die betreffenden Bibliotheken anbieten.<\/p>\n

Schwachstellen kontinuierlich \u00fcberwachen<\/em><\/strong><\/p>\n

Organisationen sollten neue Schwachstellen fortlaufend mit Softwareinventaren und eingesetzten Produkten abgleichen. Automatisierung kann die Reaktionsgeschwindigkeit deutlich erh\u00f6hen.<\/p>\n

H\u00e4ufige Fallstricke<\/h2>\n

Bei CRA-Readiness-Initiativen treten wiederkehrende Fehler auf.<\/p>\n

Alle Open-Source-Projekte gleich behandeln<\/em><\/strong><\/p>\n

Es gibt Tausende weit verbreitete Open-Source-Projekte \u2013 von Projekten einzelner Entwickler bis zu gro\u00dfen, gut finanzierten Initiativen. Die Linux Foundation verf\u00fcgt beispielsweise \u00fcber ein Jahresbudget von mehr als 300 Millionen US-Dollar und unterst\u00fctzt \u00fcber 1.300 unterschiedliche Open-Source-Projekte.<\/p>\n

Angesichts der Anzahl, Gr\u00f6\u00dfe und Nutzung der Projekte \u00fcberrascht es nicht, dass Qualit\u00e4t und Support stark variieren.<\/p>\n

Beliebtheit mit Qualit\u00e4t gleichsetzen<\/em><\/strong><\/p>\n

Eine hohe Verbreitung garantiert weder h\u00f6here Qualit\u00e4t noch geringeres Sicherheitsrisiko. In manchen F\u00e4llen gilt das Gegenteil. Beliebte Projekte ziehen mehr Entwickler an, was zu uneinheitlicher Codequalit\u00e4t, erschwerter Pr\u00fcfung und Testung von \u00c4nderungen sowie hohem Druck f\u00fcr neue Funktionen f\u00fchren kann. Das kann die Codequalit\u00e4t beeintr\u00e4chtigen und unerwartete Schwachstellen verursachen.<\/p>\n

Gro\u00dfe, komplexe und weit verbreitete Projekte sind zudem attraktive Ziele f\u00fcr Angreifer. Da der Quellcode \u00f6ffentlich verf\u00fcgbar ist, k\u00f6nnen Angreifer ihn nach ausnutzbaren Schwachstellen durchsuchen. Neue KI-Werkzeuge, die Code automatisiert auf Schwachstellen pr\u00fcfen, erh\u00f6hen dieses Risiko zus\u00e4tzlich. Angreifer k\u00f6nnen auch versuchen, sich als legitime Entwickler auszugeben und versteckte Backdoors oder Schwachstellen einzuschleusen. In gro\u00dfen Projekten mit vielen Beteiligten steigt das Risiko, dass b\u00f6sartiger Code unbemerkt aufgenommen wird.<\/p>\n

Auf nicht unterst\u00fctzte Projekte vertrauen<\/em><\/strong><\/p>\n

Viele Open-Source-Projekte werden aktiv weiterentwickelt, aber l\u00e4ngst nicht alle. Manche werden von Einzelpersonen oder kleinen Teams zur L\u00f6sung eines konkreten Problems geschaffen. Ist das Projekt abgeschlossen, wenden sich die Entwickler h\u00e4ufig anderen Aufgaben zu und pflegen die urspr\u00fcngliche Codebasis nicht weiter.<\/p>\n

F\u00fcr Unternehmen, die solche Projekte einsetzen, entsteht ein langfristiges Compliance-Risiko \u2013 besonders bei kritischen und langlebigen Produkten. Eine Schwachstelle kann lange nach Aufgabe des Projekts entdeckt werden. Unternehmen mit der betroffenen Komponente m\u00fcssen das Problem dann selbst l\u00f6sen. Je nach Komplexit\u00e4t ist das eine gro\u00dfe Herausforderung. M\u00f6glicherweise fehlen intern die n\u00f6tigen Kenntnisse. Selbst mit entsprechenden F\u00e4higkeiten k\u00f6nnen Wochen vergehen, bis eine fremde Codebasis verstanden, der Fehler analysiert und eine L\u00f6sung entworfen ist.<\/p>\n

SBOMs als reine Compliance-Dokumente behandeln<\/em><\/strong><\/p>\n

SBOMs sollten operative Werkzeuge sein, die Schwachstellenmanagement, Produkttransparenz und Lifecycle Governance unterst\u00fctzen. Sie sind wichtige Compliance-Dokumentation, aber nur der Ausgangspunkt.<\/p>\n

Ma\u00dfnahmen f\u00fcr OEMs und Softwareanbieter<\/h2>\n

Organisationen, die Open-Source-Software in ihren CRA-Readiness-Programmen angemessen ber\u00fccksichtigen m\u00f6chten, sollten folgende Ma\u00dfnahmen erw\u00e4gen.<\/p>\n

Sofortige Priorit\u00e4ten<\/em><\/strong><\/p>\n

    \n
  1. Richtlinien f\u00fcr den Einsatz von Open-Source-Software festlegen.<\/li>\n
  2. Vollst\u00e4ndige Inventare aller Open-Source-Komponenten in allen Produkten erstellen.<\/li>\n
  3. Freigegebene Open-Source-Projekte f\u00fcr die weitere Nutzung identifizieren.<\/li>\n
  4. Migrationspl\u00e4ne erstellen, um nicht unterst\u00fctzte, aufgegebene oder als hochriskant eingestufte Projekte abzul\u00f6sen.<\/li>\n
  5. Programme zur \u00dcberwachung von Schwachstellen in verwendeten Open-Source-Komponenten einf\u00fchren.<\/li>\n
  6. Reaktionspl\u00e4ne f\u00fcr Schwachstellen in verwendeten Open-Source-Komponenten erstellen. Dazu kann geh\u00f6ren, kommerzielle Support-Anbieter zu finden oder interne Ressourcen f\u00fcr den Support aufzubauen.<\/li>\n
  7. Erw\u00e4gen, f\u00fcr das Unternehmen kritische Open-Source-Projekte aktiv zu unterst\u00fctzen.<\/li>\n
  8. Klare Verantwortlichkeit f\u00fcr die Nutzung von Open-Source-Software im Unternehmen zuweisen.<\/li>\n
  9. Richtlinien zur Open-Source-Nutzung und Pl\u00e4ne zur Schwachstellenbehebung dokumentieren.<\/li>\n<\/ol>\n

    Open-Source-Software wird bleiben. Organisationen ben\u00f6tigen jedoch kontinuierliche Transparenz \u00fcber die Softwarekomponenten in ihren Produkten und die daraus entstehenden Risiken. Wenn sich Produkte, Abh\u00e4ngigkeiten und Schwachstellen ver\u00e4ndern, muss sich auch dieses Verst\u00e4ndnis mitentwickeln.<\/p>\n

    Wie OmniTrust Certify helfen kann<\/h3>\n

    Open-Source-Software wird bleiben. Organisationen ben\u00f6tigen jedoch kontinuierliche Transparenz \u00fcber die Softwarekomponenten in ihren Produkten und die daraus entstehenden Risiken. Wenn sich Produkte, Abh\u00e4ngigkeiten und Schwachstellen ver\u00e4ndern, muss sich auch dieses Verst\u00e4ndnis mitentwickeln.<\/p>\n

    OmniTrust Certify<\/a> erstellt ein lebendes Produktprofil, das Softwarezusammensetzung, Schwachstellen, Cyberrisiken, regulatorische Anforderungen, Kontrollen und Nachweise \u00fcber den gesamten Produktlebenszyklus hinweg verbindet.<\/p>\n

    Mit OmniTrust Certify k\u00f6nnen Organisationen:<\/p>\n