Zwischen beiden Terminen liegen fünfzehn Monate, in denen der CRA laut Warden faktisch keine Sicherheits-, sondern eine Sichtbarkeitsanforderung ist. Er verweist auf ActiveState-CEO Abby Kearns, die kürzlich über genau diese Lücke geschrieben hat, und stimmt ihr zu: Die Frage „Was haben wir ausgeliefert, und wann haben wir zuerst von einem Problem damit erfahren?" beantworten Compliance-Teams im September nicht zum ersten Mal.
Jeder Open-Source-Maintainer mit einem Disclosure-Prozess beantwortet sie bereits heute – informell, unter Druck und mit selbst zusammengebautem Werkzeug, weil niemand ein passendes gebaut hat. Wardens These: Was heute die informelle Realität von Freiwilligen ist, wird zur operativen Realität der gesamten Softwarebranche.
Ein Vorbild für das erwartbare Gedränge sieht er in der US-Executive-Order 14028 von 2021, die Software Bills of Materials (SBOM) von Bundeslieferanten verlangte. Viele Organisationen erzeugten die SBOM wie jedes andere Compliance-Artefakt: einmal, unter Fristdruck, korrekt für den Moment der Erstellung und veraltet, sobald jemand erneut danach fragte. Ein Dokument vom vergangenen März sage nichts darüber aus, was heute läuft, sondern nur, was im März lief. Der CRA sei an dieser Stelle deutlicher: Artikel 13 verlangt eine aktuelle SBOM.
Dass es dabei nicht um Randfälle geht, belegt Warden mit dem Open Source Security and Risk Analysis Report 2026 von Black Duck: 98 Prozent der Anwendungen enthalten Open-Source-Komponenten. Nahezu jeder Hersteller, der in die EU verkauft, muss die Herkunftsfrage also beantworten – und zwar mit laufender juristischer Uhr. Die Branchenzahlen zur Behebungsdauer stimmen ihn nicht zuversichtlich: Laut dem Vulnerability Statistics Report 2026 von Edgescan dauert es im Schnitt rund 55 Tage, bis eine hoch oder kritisch eingestufte Anwendungsschwachstelle behoben ist. Genau in der Spanne zwischen dieser Basislinie und den Fristen von 24 beziehungsweise 72 Stunden aus den Meldepflichten nach Artikel 14 (Europäische Kommission) werde sich die Durchsetzung abspielen.
Warden beschreibt zwei Wege, diese Lücke zu schließen. Einige Organisationen bauen die Fähigkeit intern auf: Sie instrumentieren ihre Pipelines so, dass SBOMs automatisch neu erzeugt werden, etablieren einen dokumentierten Prozess zur Schwachstellenbehandlung mit benannter Verantwortung und behandeln Herkunftsnachweise als Eigenschaft der Software-Lieferkette statt als Bericht, den man unter Prüfungsdruck zusammenstellt. Andere entscheiden, dass das Nachvollziehen der Herkunft jeder konsumierten Open-Source-Komponente über sämtliche Sprach-Ökosysteme hinweg keine Kernkompetenz ist, und beziehen stattdessen bereits geprüfte und attestierte Komponenten, sodass die Frage vor dem Build beantwortet ist.
Beides funktioniere, riskant sei nur, im vierzehnten Monat festzustellen, dass hinter „Wir werden compliant sein" kein „Wir können die Frage im Ernstfall tatsächlich beantworten" steht. ActiveState bewirbt dafür seine Curated Catalogs: Open-Source-Komponenten aus zwölf Sprach-Ökosystemen mit unveränderlicher Herkunftsangabe zur Build-Zeit und vertraglichen Service-Level-Zusagen – fünf Werktage bei kritischem Schweregrad, sobald ein Upstream-Fix existiert, zehn bei hohem, dreißig für den Rest.
Wie streng ENISA den Wortlaut von Artikel 14 im ersten Jahr durchsetzen wird, weiß Warden nach eigenen Angaben nicht; er misstraue jedem, der das mit Bestimmtheit behaupte. Sein praktischer Vorschlag: ein vor sechs Monaten ausgeliefertes Produkt auswählen und messen, wie lange jemand braucht, um dessen Inhalt und den Zeitpunkt der ersten Kenntnis vom letzten kritischen CVE zu nennen. Dauert das länger als 72 Stunden, sei die Antwort bereits gefunden.