Cyber Resilience Act: Open Source ist nicht ausgenommen

05.08.2026

Thema: alle Beiträge zu Open Source

Die erste CRA-Pflicht greift am 11. September 2026, nicht 2027. Wer Hersteller ist, was die SBOM wirklich verlangt und warum offene Abhängigkeiten die Pflicht nicht kleiner machen, nur erfüllbar.

Inhaltsverzeichnis

Die erste Pflicht aus dem Cyber Resilience Act greift in gut fünf Wochen, nicht 2027.

Das ist der Satz, der in den meisten Gesprächen fehlt. Der CRA gilt als Thema für übermorgen, und die Jahreszahl, die alle im Kopf haben, ist 2027. Die stimmt auch, nur eben für den Hauptteil der Verordnung. Der erste scharfe Termin liegt davor.

Und der zweite verbreitete Satz, „Open Source ist davon ausgenommen”, stimmt in genau einer Lesart und in der wichtigsten nicht.

Die Antwort vorweg

Stand 1. August 2026, Verordnung (EU) 2024/2847:

Termin Was gilt ab dann
11. Juni 2026 Konformitätsbewertungsstellen können notifiziert werden
11. September 2026 Meldepflicht für aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle
11. Dezember 2027 Vollanwendung, also CE-Kennzeichnung, technische Dokumentation, SBOM

Und die Regel, um die es in diesem Beitrag geht:

Die Pflicht wandert nicht mit dem Code. Sie wandert mit dem Inverkehrbringen.

Wer offene Komponenten kommerziell in ein Produkt einbaut und dieses Produkt auf den EU-Markt bringt, ist Hersteller im Sinne des CRA. Unabhängig davon, wer den Code geschrieben hat und unter welcher Lizenz.

Was am 11. September 2026 beginnt

Ab diesem Tag greift Artikel 14. Hersteller eines Produkts mit digitalen Elementen müssen melden, und zwar zwei verschiedene Dinge auf zwei getrennten Wegen. In den meisten Zusammenfassungen wird daraus eine einzige Kette. Im Verordnungstext sind es zwei, mit unterschiedlichen Fristen am Ende.

Aktiv ausgenutzte Schwachstelle in deinem Produkt, Artikel 14 Absätze 1 bis 3:

Stufe Frist Inhalt
Frühwarnung 24 Stunden dass eine aktiv ausgenutzte Schwachstelle vorliegt, mehr nicht
Schwachstellenmeldung 72 Stunden betroffene Komponente, Einschätzung, erste Gegenmaßnahmen
Abschlussbericht 14 Tage, nachdem eine Abhilfemaßnahme verfügbar ist Beschreibung, Wirkung, Behebung

Schwerwiegender Sicherheitsvorfall, Artikel 14 Absätze 4 bis 6:

Stufe Frist Inhalt
Frühwarnung 24 Stunden dass ein schwerwiegender Vorfall vorliegt
Vorfallmeldung 72 Stunden Art des Vorfalls, erste Bewertung, Gegenmaßnahmen
Abschlussbericht ein Monat nach der Vorfallmeldung Ursache, Wirkung, ergriffene Maßnahmen

Der Unterschied steckt in der letzten Zeile, und er ist der Grund, warum ich beide Tabellen hinschreibe. Bei der Schwachstelle beginnt die Frist für den Abschlussbericht erst, wenn ein Patch verfügbar ist. Beim Vorfall läuft sie ab der eigenen Meldung, unabhängig davon, ob schon etwas behoben ist.

Vier Dinge daran werden regelmäßig unterschätzt.

Erstens ist die ENISA nicht der einzige Empfänger. Gemeldet wird gleichzeitig an den als Koordinator benannten CSIRT des betroffenen Mitgliedstaats und an die ENISA, über eine einheitliche Meldeplattform nach Artikel 16. In Deutschland ist der nationale CSIRT beim BSI angesiedelt. Wer im Prozess nur „Meldung an die ENISA” stehen hat, hat den halben Adressaten.

Zweitens gilt das unabhängig vom Sitz des Herstellers. Maßgeblich ist, ob das Produkt auf dem EU-Markt bereitgestellt wird, nicht wo es gebaut wurde.

Drittens trifft die Meldepflicht auch den Bestand. Das ist der Punkt, der die meisten überrascht. Für alles andere gibt es eine Schonfrist: Produkte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden, müssen die Anforderungen der Verordnung erst erfüllen, wenn sie ab diesem Tag wesentlich verändert werden, so steht es in Artikel 69 Absatz 2. Der folgende Absatz 3 nimmt Artikel 14 ausdrücklich von dieser Schonfrist aus. Die Meldepflicht gilt für alle Produkte im Anwendungsbereich, auch für die, die längst ausgeliefert sind und nur noch gepflegt werden. Wer glaubt, ihn treffe der CRA erst mit dem nächsten Release, hat diesen Absatz übersehen.

Viertens ist die 24-Stunden-Frist eine Prozessfrage, keine Technikfrage. Wer erst am Tag der ersten Meldung klärt, wer intern entscheidet, wer meldet und an welchen CSIRT, hat die Frist bereits verpasst. Das ist der Grund, warum dieser Termin jetzt relevant ist und nicht im September.

Wer Hersteller ist und wer nicht

Hier liegt die Verwechslung, aus der „Open Source ist ausgenommen” entsteht. Der CRA kennt drei Rollen, und nur eine davon trägt die volle Last.

Rolle Beispiel Pflichten
Nicht-kommerzieller Entwickler jemand veröffentlicht eine Bibliothek auf GitHub, ohne kommerzielle Absicht außerhalb des Herstellerbegriffs
Open-Source-Steward Stiftung oder Organisation, die offene Software dauerhaft unterstützt dokumentierte Sicherheitsleitlinie, Zusammenarbeit mit der Marktaufsicht, von Bußgeldern ausgenommen
Hersteller du, sobald du diese Software kommerziell in dein Produkt einbaust und in Verkehr bringst die volle Verordnung

Die Rolle des Open-Source-Stewards ist eine echte Neuerung. Sie steht in Artikel 24 und wurde geschaffen, weil der ursprüngliche Entwurf Stiftungen wie die Apache Software Foundation faktisch wie Hersteller behandelt hätte. Ein Steward muss eine nachweisbare Sicherheitsleitlinie haben und mit den Behörden kooperieren, kann für Verstöße gegen die Verordnung aber nicht mit Bußgeldern belegt werden. Das steht so ausdrücklich in Artikel 64 Absatz 10.

Was die Rolle nicht tut: Sie nimmt dir nichts ab. Wenn du ein Produkt verkaufst, das auf dieser Software aufsetzt, bleibt die Herstellerpflicht bei dir. Der Steward ist keine Haftungsübernahme, die du einkaufst, sondern die Anerkennung, dass jemand upstream Verantwortung trägt, ohne dein Produkt zu verkaufen.

Dass „offen” dabei nicht gleich „offen” ist, sondern an nachprüfbaren Kriterien hängt, steht in Open Source ist mehr als sichtbarer Quellcode. Für den CRA ist diese Unterscheidung keine Geschmacksfrage mehr, sondern entscheidet darüber, in welcher Zeile der Tabelle oben du stehst.

Was in die technische Dokumentation muss

Zum 11. Dezember 2027 kommt der Teil, der die meiste Arbeit macht. Anhang I Teil II Nummer 1 verlangt, dass Hersteller die Komponenten ihres Produkts identifizieren und dokumentieren, „einschließlich der Erstellung einer Software-Stückliste in einem gängigen, maschinenlesbaren Format, die mindestens die Abhängigkeiten der obersten Ebene abdeckt”.

Vier Punkte, die dabei oft falsch verstanden werden:

  1. Die SBOM muss nicht öffentlich sein. Sie gehört in die technische Dokumentation und wird der Marktaufsichtsbehörde auf begründetes Verlangen vorgelegt. Sie ist ein Nachweis, keine Veröffentlichung
  2. Es ist kein Format vorgeschrieben. Weder CycloneDX noch SPDX stehen in der Verordnung. Es gibt bislang weder eine harmonisierte Norm noch einen delegierten Rechtsakt dazu. In der Praxis nimmt man eines der beiden
  3. Mindestens die oberste Ebene. Das ist die Untergrenze, nicht das Ziel. Wer transitive Abhängigkeiten mitnimmt, erfüllt mehr als gefordert
  4. Eine SBOM ist kein Schwachstellenbericht. Sie sagt, was drin ist, nicht was kaputt ist. Die Verbindung zu CVEs stellt ein Scanner her, siehe Docker Scout oder Trivy

Eine SBOM in einem Kommando

Der praktische Teil ist unspektakulär, und das ist die gute Nachricht. Für ein Container-Image genügt ein Aufruf:

trivy image --format cyclonedx --output sbom.json nginx:1.27-alpine

Was dabei herauskommt, ist eine CycloneDX-Datei. Zählen lässt sie sich mit jq. Damit die Zahlen vergleichbar bleiben, hole ich beide in einem Durchgang aus derselben Menge, die Gesamtzahl der Einträge und die Zahl der Bibliotheken ohne Lizenzangabe:

jq '{eintraege:    (.components | length),
     bibliotheken: ([.components[] | select(.type=="library")] | length),
     ohne_lizenz:  ([.components[] | select(.type=="library" and (has("licenses")|not))] | length)}' sbom.json

{
  "eintraege": 69,
  "bibliotheken": 68,
  "ohne_lizenz": 0
}

Ein nginx auf Alpine, also das schlankeste, was im Alltag üblich ist, besteht aus 69 Einträgen: 68 Bibliotheken plus ein Eintrag vom Typ operating-system für die Distribution selbst. Das ist der Ausgangspunkt, nicht das Problem.

Der Unterschied zwischen den 69 und den 68 sieht nach Erbsenzählerei aus, ist aber genau die Art Detail, an der später die Prozentrechnung kippt. Wer „Einträge insgesamt” gegen „Bibliotheken ohne Lizenz” rechnet, vergleicht zwei verschiedene Grundgesamtheiten.

Dasselbe nginx, zwei Lieferketten

Interessant wird es beim Vergleich. Gleiche Software, gleicher Hersteller, gleicher Tag-Stand, nur ein anderes Basis-Image. Derselbe Befehl von oben, einmal gegen nginx:1.27:

Image Basis Einträge davon Bibliotheken Bibliotheken ohne Lizenzangabe
nginx:1.27-alpine Alpine 3.21.3 69 68 0
nginx:1.27 Debian 12.11 150 149 17

Gemessen am 1. August 2026 mit trivy 0.72.0, Ausgabeformat CycloneDX 1.7, die Digests stehen unter Quellen.

Zwei Befunde stecken darin.

Die Wahl des Basis-Images ist eine Entscheidung über die Größe deiner Lieferkette. Mehr als doppelt so viele Komponenten, ohne dass sich an deiner Anwendung eine Zeile geändert hätte. Das ist keine Aufforderung, blind auf Alpine zu wechseln, denn die Debian-Basis hat gute Gründe. Es ist die Aufforderung, die Entscheidung bewusst zu treffen, weil sie ab 2027 dokumentationspflichtig wird.

Und 17 Bibliotheken tragen keine Lizenzangabe. Nicht weil sie keine Lizenz hätten, sondern weil die Metadaten im Paket sie nicht maschinenlesbar transportieren. Die SBOM ist erzeugt, das Feld ist leer, und niemand wird davon wach.

Genau an dieser Stelle wird aus dem Compliance-Thema wieder ein Lizenzthema. Wer wissen will, was für seine Komponenten gilt, muss bei diesen 17 Einträgen selbst nachsehen. Das ist möglich, weil es offene Pakete sind. Es ist Arbeit, aber es ist möglich.

Die Probe aufs Exempel an meinem eigenen Image

Fremde Images zu vermessen ist billig. Also habe ich das Image genommen, das diese Webseite ausliefert, und dieselbe Frage daran gestellt: Steckt da eine SBOM drin?

Ein Hinweis vorweg, in eigener Sache. Ich pinne hier per Digest statt per :latest. Ein Beitrag über maschinenlesbare Nachweise sollte selbst nachweisbar sein, und :latest zeigt in vier Wochen auf ein anderes Artefakt. Dann stimmen die Zahlen unten nicht mehr, ohne dass jemand etwas gemerkt hätte. Das ist derselbe Gedanke wie beim Lock-File für Terraform-Provider: Ein Nachweis, der auf einen beweglichen Zeiger verweist, ist keiner.

docker buildx imagetools inspect \
  trutzio/trutzio@sha256:219bddd48d1b6a1908fd9c30e492b8bbc77f51f358cbff08283716f0f9845944 --raw

Die gute Nachricht zuerst: ja. Der Index verweist neben dem eigentlichen Image auf ein Attestation-Manifest, und darin liegen zwei in-toto-Belege, eine SBOM nach SPDX und eine Herkunftsattestierung nach SLSA:

# gekuerzt auf die beiden Belegtypen
"in-toto.io/predicate-type": "https://spdx.dev/Document"
"in-toto.io/predicate-type": "https://slsa.dev/provenance/v1"

Das ist kein Verdienst von mir, sondern der Standardweg von BuildKit. Wie solche Zusatz-Artefakte neben dem Image in der Registry liegen, steht im Beitrag zu OCI-Artefakten. Auslesen kann das jeder, ohne Anmeldung:

docker buildx imagetools inspect \
  trutzio/trutzio@sha256:219bddd48d1b6a1908fd9c30e492b8bbc77f51f358cbff08283716f0f9845944 \
  --format '{{ json .SBOM }}' > sbom.json
Merkmal Wert
Format SPDX 2.3, JSON
Erzeugt von syft 1.42.3 über buildkit 0.31.2
Einträge in packages 54
davon eindeutige Namen 28
erfasste Dateien 744
Basis dhi/nginx 1.30.0-debian13

Formal ist die CRA-Anforderung damit erfüllt: maschinenlesbares, gängiges Format, die Abhängigkeiten der obersten Ebene sind drin. Wer nur abhaken will, ist hier fertig.

Beim Nachsehen wird es interessanter.

Die 54 Einträge sind nicht 54 Bauteile. Nur 28 Namen sind eindeutig, der Rest ist doppelt erfasst, mit identischem Package-URL, aber zwei verschiedenen SPDX-Kennungen. nginx selbst taucht sogar dreimal auf, in drei Rollen:

pkg:docker/dhi/nginx@1.30.0-debian13    das Basis-Image
pkg:deb/nginx/nginx@1.30.0-1~trixie     das Debian-Paket
pkg:generic/nginx@1.30.0                die gefundene Binärdatei

Das ist kein Fehler, das sind drei Sichten auf dieselbe Sache. Aber wer die Zeilen zählt, um zu wissen, wie groß seine Lieferkette ist, zählt falsch.

Und dann der Teil, der wehtut. Vier Einträge haben weder licenseConcluded noch licenseDeclared:

jq -r '.SPDX.packages[]
  | select((.licenseConcluded//"NOASSERTION")=="NOASSERTION"
       and (.licenseDeclared//"NOASSERTION")=="NOASSERTION")
  | [.name, .SPDXID] | @tsv' sbom.json

dhi/nginx  SPDXRef-Package-UnknownPackage-dhi-nginx-dhi-nginx
nginx      SPDXRef-Package-binary-nginx-0534ac8865a9203e
nginx      SPDXRef-Package-deb-nginx-nginx
sbom       SPDXRef-DocumentRoot-Directory-sbom

Der vierte Eintrag ist ein gutes Beispiel dafür, warum Zeilenzählen nicht reicht. sbom ist gar keine Komponente, sondern der Wurzelknoten des Dokuments, den syft für das gescannte Verzeichnis anlegt. Erkennbar an der Kennung SPDXRef-DocumentRoot-Directory und an primaryPackagePurpose: FILE. Er steht in derselben Liste wie echte Pakete und wird von jeder naiven Auswertung mitgezählt.

Bleiben drei echte Einträge ohne Lizenzangabe. Jedes einzelne Debian-Systempaket in diesem Image trägt eine saubere Lizenzangabe. Ohne Angabe sind ausgerechnet diese drei nginx-Einträge, also die Software, um die es in dem Image überhaupt geht.

Genau das ist der Punkt aus dem vorigen Abschnitt, nur diesmal an meinem eigenen Artefakt: Die SBOM ist da, das Feld ist leer, und ohne gezieltes Nachsehen fällt es niemandem auf. Ein Häkchen bei „SBOM vorhanden” hätte ich guten Gewissens setzen können.

Zwei ehrliche Einordnungen gehören dazu. Erstens ist ein Webserver-Image, das meinen Blog ausliefert, kein Produkt mit digitalen Elementen, das ich auf dem EU-Markt in Verkehr bringe. Die Herstellerpflichten des CRA treffen mich hier nicht, das hier ist eine Übung, keine Compliance. Zweitens sagt eine fehlende Lizenzangabe in der SBOM nichts über die Lizenz von nginx aus, die ist bekannt und unstrittig. Fehlend ist die maschinenlesbare Aussage darüber, und nur die zählt, wenn jemand die Datei auswertet statt sie zu lesen.

Eine Randnotiz vom selben Messtag, die einen eigenen Beitrag wert war. Zur Meldepflicht gehört die Frage, welche Schwachstellen überhaupt bekannt sind, und dafür betreibt die EU seit Mai 2025 mit der EUVD eine eigene Datenbank, offen abrufbar, ohne Token, ausdrücklich als Baustein des CRA. Nur bindet sie kein verbreiteter Scanner ein: Derselbe Scan über dasselbe Debian-nginx liefert 504 CVE-Kennungen und null EUVD-Kennungen. Warum das inhaltlich kaum wehtut und als Befund über die eigene Werkzeugkette trotzdem zählt, nehme ich mir im nächsten Beitrag vor.

Warum die Liste noch keine Antwort ist

Der ehrliche Teil: Open Source macht das nicht automatisch leicht.

Eine Datei mit 150 Einträgen zu erzeugen dauert eine Minute. Sie zu verstehen ist etwas anderes. Welche dieser Komponenten läuft überhaupt in deinem Prozess? Welche liegt nur im Image herum, weil sie im Basis-Image steckt? Welche würdest du im Ernstfall selbst patchen können, und bei welcher wüsstest du nicht einmal, wo der Quellcode liegt?

Der CRA fragt danach nicht direkt. Aber jede Frist, die er setzt, setzt genau das voraus. Eine Frühwarnung binnen 24 Stunden schreibt niemand, der erst herausfinden muss, ob die betroffene Bibliothek in seinem Produkt überhaupt aktiv ist.

Die offene Lizenz gibt dir das Recht nachzusehen. Ob du dabei etwas siehst, entscheidet dein technisches Verständnis.

Die Pflicht ist gleich, die Fähigkeit nicht

Damit sind wir bei dem Punkt, um den es mir eigentlich geht.

Nimm zwei Produkte, die dieselbe Funktion erfüllen. Eines setzt auf eine offene Komponente, eines auf eine proprietäre Bibliothek eines Zulieferers. Am 11. September 2026 trifft beide dieselbe Meldepflicht, und ab Dezember 2027 dieselbe Dokumentationspflicht. Der CRA macht hier keinen Unterschied, und das ist richtig so.

Der Unterschied liegt woanders:

Frage im Ernstfall offene Abhängigkeit proprietäre Abhängigkeit
Was steckt drin selbst feststellbar Auskunft des Lieferanten nötig
Schwachstelle prüfen Quellcode lesen, nachbauen auf Advisory warten
Patch im Ernstfall selbst möglich nur der Hersteller
24-Stunden-Frist eigene Analyse reicht Reaktionszeit eines Dritten hängt drin

Die Pflicht ist bei beiden gleich. Die Fähigkeit, sie zu erfüllen, ist es nicht.

Das ist kein Argument dafür, alles Proprietäre auszubauen. Es ist ein Argument dafür, bei jeder Abhängigkeit zu wissen, in welcher der beiden Spalten man gerade steht, und diese Entscheidung nicht dem Zufall zu überlassen. Ab September ist sie mit einer Frist versehen.

Was du bis zum 11. September klären solltest

Der Termin ist ein Prozess-Termin, kein Technik-Termin. Vier Fragen, die vorher beantwortet sein müssen, weil man sie in 24 Stunden nicht mehr beantwortet:

  1. Bin ich Hersteller? Bringt meine Organisation ein Produkt mit digitalen Elementen kommerziell auf den EU-Markt? Wenn ja, für welche Produkte genau. Diese Liste ist die Grundlage für alles Weitere
  2. Wer entscheidet, dass gemeldet wird? Eine benannte Person mit Vertretung, erreichbar auch am Wochenende. Eine 24-Stunden-Frist, die an einer Urlaubsabwesenheit hängt, ist keine
  3. An wen geht die Meldung? Der koordinierende CSIRT des betroffenen Mitgliedstaats und die ENISA, über die einheitliche Plattform. Zugang und Zuständigkeit einmal vorher klären, nicht im Ernstfall
  4. Wo liegt die Komponentenliste, und ist sie aktuell? Nicht erst ab 2027 relevant. Ohne sie lässt sich die Frage „betrifft uns diese Schwachstelle” nicht in 24 Stunden beantworten

Punkt 4 ist der einzige, der Technik ist. Die anderen drei kosten einen Termin und eine Seite Text, und sie sind der Grund, warum dieser Beitrag jetzt erscheint und nicht im September.

Fazit

  1. Die erste CRA-Pflicht greift am 11. September 2026, nicht 2027. Sie betrifft die Meldung aktiv ausgenutzter Schwachstellen und schwerwiegender Vorfälle, in zwei getrennten Ketten, an CSIRT und ENISA. Und sie gilt auch für Produkte, die längst ausgeliefert sind
  2. Open Source ist nicht ausgenommen, sondern anders eingeordnet. Nicht-kommerzielle Entwickler stehen außerhalb, für Stewards gibt es eine mildere Rolle. Sobald du kommerziell in Verkehr bringst, bist du Hersteller
  3. Die Pflicht wandert nicht mit dem Code, sondern mit dem Inverkehrbringen
  4. Die SBOM ist ein Nachweis, keine Veröffentlichung. Maschinenlesbar, mindestens die oberste Ebene, kein Format vorgeschrieben
  5. Das Basis-Image entscheidet über die Größe deiner Lieferkette. Dasselbe nginx: 69 Einträge auf Alpine, 150 auf Debian, davon 17 Bibliotheken ohne Lizenzangabe
  6. Eine SBOM zu haben ist nicht dasselbe, wie sie zu verstehen. Die Liste erzeugt ein Kommando, die Antwort auf „betrifft uns das” nicht. In meinem eigenen Image sind 54 Einträge in Wahrheit 28 Bauteile, einer davon ist nicht einmal eine Komponente, und ausgerechnet nginx trägt keine Lizenzangabe

Jede dieser Fragen endet bei derselben: Was läuft da eigentlich in deinen Containern, und wer liefert es dir? Wer Docker und Kubernetes nicht nur bedient, sondern versteht, hat auf die Fragen des CRA schon die halbe Antwort. Praxisnahe Antworten auf die häufigsten Docker- und Kubernetes-Probleme gibt es in meinem Newsletter. Kein Spam, kein Beratersprech.

Quellen

© 2026 Trutz Software Consulting GmbH. CC BY 4.0: Dieser Text darf mit Namensnennung weiterverwendet und bearbeitet werden, auch kommerziell. Code-Beispiele darin stehen unter Apache 2.0. Ausgenommen sind Marke und Logo sowie gekennzeichnete Zitate Dritter. Was das genau heißt.

Newsletter

Erhalte praxisnahe Tutorials, Best Practices und echte Lösungen für die häufigsten DevOps-Probleme direkt in Dein Postfach.

Datenschutz: Deine E-Mail-Adresse wird DSGVO-konform in Deutschland gespeichert. Keine Spam, nur relevante Inhalte. Eine E-Mail alle 1 bis 2 Wochen.