Die Uhr des Art. 14 der Cyberresilienz-Verordnung beginnt an dem Tag zu laufen, an dem ein Hersteller Kenntnis von einer aktiven Ausnutzung erlangt, und ein einmal exportiertes Scan-Ergebnis kann nur den Tag des Exports datieren; hier sind die vier Eigenschaften, die das Ergebnis einer wiederkehrenden Prüfung braucht, bevor es als Nachweis bestehen kann.
Die Uhr des Art. 14 der Cyberresilienz-Verordnung beginnt an dem Tag zu laufen, an dem ein Hersteller Kenntnis von einer aktiven Ausnutzung erlangt, und ein einmal exportiertes Scan-Ergebnis kann nur den Tag des Exports datieren; hier sind die vier Eigenschaften, die das Ergebnis einer wiederkehrenden Prüfung braucht, bevor es als Nachweis bestehen kann.
Der Leitlinienentwurf der Kommission zur Cyberresilienz-Verordnung, dessen Inhalt sie am 27. Juli 2026 gebilligt hat und der erst nach seiner förmlichen Annahme gilt, widmet dem, was ein Hersteller schon wusste, einen einzigen Absatz. Der Entwurf liegt derzeit nur auf Englisch vor; Zitate daraus und aus anderen englischsprachigen Quellen stehen in diesem Beitrag im Original, jeweils mit einer sinngemässen deutschen Wiedergabe. Randnummer 217 sagt, ein Hersteller „is not required to report vulnerabilities of whose active exploitation it had already become aware before 11 September 2026“ (Sinngemäss: muss Schwachstellen nicht melden, von deren aktiver Ausnutzung er bereits vor dem 11. September 2026 Kenntnis erlangt hatte), und zwei Sätze später, dass eine Schwachstelle, die er vor diesem Datum kannte, ohne von einer Ausnutzung zu wissen, meldepflichtig wird, sobald die Ausnutzung bekannt wird. Das sind zwei Datumsangaben: der Tag, an dem Sie wussten, dass die Schwachstelle existiert, und der Tag, an dem Sie wussten, dass sie benutzt wird. Ab dem 11. September 2026 macht Art. 14 der Verordnung aus dem zweiten den Start einer Uhr. Ein an einem Tag exportiertes Scan-Ergebnis datiert, was Ihre Prüfungen an diesem Tag wussten, und nichts danach. Um diese Lücke geht es in diesem Beitrag.
Die Verordnung (EU) 2024/2847 staffelt ihren eigenen Geltungsbeginn. Art. 71(2): „Diese Verordnung gilt ab dem 11. Dezember 2027. Artikel 14 gilt jedoch ab dem 11. September 2026, und Kapitel IV (Artikel 35 bis 51) gilt ab dem 11. Juni 2026.“ Kapitel IV betrifft die Konformitätsbewertungsstellen; für einen Hersteller ist die einzige Pflicht, die im September scharf geschaltet wird, also Art. 14. Art. 69(3) erstreckt sie auf „alle Produkte mit digitalen Elementen, die in den Anwendungsbereich dieser Verordnung fallen und vor dem 11. Dezember 2027 in den Verkehr gebracht wurden“.
Art. 14(1) verpflichtet einen Hersteller, „jede aktiv ausgenutzte Schwachstelle, die in dem Produkt mit digitalen Elementen enthalten ist und von der er Kenntnis erlangt“, dem als Koordinator benannten CSIRT und der ENISA zu melden. Die Fristen stehen in Art. 14(2):
a) unverzüglich, in jedem Fall aber innerhalb von 24 Stunden, nachdem der Hersteller davon Kenntnis erlangt hat, eine Frühwarnung über eine aktiv ausgenutzte Schwachstelle […]; >b) sofern die einschlägigen Informationen nicht bereits vorgelegt wurden, unverzüglich, in jedem Fall aber innerhalb von 72 Stunden, nachdem der Hersteller Kenntnis von der aktiv ausgenutzten Schwachstelle erlangt hat, eine Meldung von Schwachstellen […]; >c) sofern die einschlägigen Informationen nicht bereits vorgelegt wurden, spätestens 14 Tage, nachdem eine Korrektur- oder Risikominderungsmaßnahme zur Verfügung steht, einen Abschlussbericht […]. >Art. 14(2), Verordnung (EU) 2024/2847
Zwei der drei laufen ab dem Moment, in dem der Hersteller „Kenntnis erlangt hat“; die dritte läuft ab dem Zeitpunkt, an dem eine Abhilfe verfügbar ist, und das ist ein anderes Ereignis.
„Aktiv ausgenutzt“ ist definiert. Art. 3(42): eine Schwachstelle, „zu der verlässliche Nachweise dafür vorliegen, dass ein böswilliger Akteur sie in einem System ohne Zustimmung des Systemeigners ausgenutzt hat“. Eine Zeile in einem Scanner-Bericht ist eine Schwachstelle; zu einer aktiv ausgenutzten wird sie, wenn verlässliche Nachweise einer Ausnutzung vorliegen. Rn. 210 des Leitlinienentwurfs ergänzt, dass die Meldepflicht, anders als die Schwachstellenbehandlung, nach dem Ende des Unterstützungszeitraums eines Produkts weiterläuft.
Die Leitlinien sind ein Entwurf. Die Begleitmitteilung, C(2026) 5252 final vom 27. Juli 2026, sagt über den Anhang, er „will be formally adopted by the Commission at a later date, when all language versions are available. It is only from that moment that it will apply.“ (Sinngemäss: Er wird von der Kommission zu einem späteren Zeitpunkt förmlich angenommen, wenn alle Sprachfassungen vorliegen; erst ab diesem Moment gilt er.) Ein Datum wird nicht genannt. Was folgt, ist die Lesart der Kommission nach heutigem Stand; Rn. 211 nennt als Zweck, Herstellern zu helfen, „determine the moment when the applicable reporting deadlines start“ (Sinngemäss: den Zeitpunkt zu bestimmen, an dem die anwendbaren Meldefristen beginnen).
Rn. 213 legt diesen Zeitpunkt hinter eine Bewertung:
The manufacturer is therefore to be regarded as having become aware when, after such an initial assessment, it has a reasonable degree of certainty that: (i) a vulnerability contained in its product with digital elements is being actively exploited […] >Sinngemäss: Der Hersteller ist demnach so zu betrachten, als habe er Kenntnis erlangt, wenn er nach einer solchen Erstbewertung ein hinreichendes Mass an Gewissheit darüber hat, dass (i) eine in seinem Produkt mit digitalen Elementen enthaltene Schwachstelle aktiv ausgenutzt wird […] >Leitlinienentwurf, Anhang Rn. 213, S. 74
Rn. 212 stellt diese Lesart neben Erwägungsgrund 31 der Durchführungsverordnung (EU) 2024/2690 und Abschnitt II(A) der Leitlinien 9/2022 zur Meldung von Verletzungen des Schutzes personenbezogener Daten, sodass sich die Lesarten aus NIS2 und DSGVO übertragen.
Dann die Trennung, mit der der Einstieg begann:
By contrast, the obligation does apply where the manufacturer was aware of a vulnerability before 11 September 2026 but was not, at that time, aware of any active exploitation of it (either because none had yet occurred or because the manufacturer had not become aware of it). If, after 11 September 2026, active exploitation subsequently occurs or the manufacturer becomes aware of it, the vulnerability is deemed an actively exploited one subject to the reporting obligation. >Sinngemäss: Dagegen gilt die Pflicht sehr wohl, wenn der Hersteller vor dem 11. September 2026 von einer Schwachstelle wusste, zu diesem Zeitpunkt aber keine Kenntnis von einer aktiven Ausnutzung hatte (entweder weil noch keine stattgefunden hatte oder weil der Hersteller nichts davon erfahren hatte). Kommt es nach dem 11. September 2026 zu einer aktiven Ausnutzung oder erlangt der Hersteller davon Kenntnis, gilt die Schwachstelle als aktiv ausgenutzt und unterliegt der Meldepflicht. >Leitlinienentwurf, Anhang Rn. 217, S. 75–76
Rn. 218 ergänzt, dass eine Schwachstelle einer Drittkomponente, die „cannot be exploited in its product with digital elements (e.g. because the vulnerable code is not reachable)“ (Sinngemäss: in seinem Produkt mit digitalen Elementen nicht ausgenutzt werden kann, etwa weil der verwundbare Code nicht erreichbar ist), ausserhalb der Meldepflicht liegt; die Behandlungspflichten aus Teil II gelten weiterhin, nach ihrem eigenen Zeitplan. Legt man die Randnummern zusammen, lautet die Frage, die ein Hersteller beantworten können muss: Wann haben die eigenen Prüfungen was zutage gefördert? Die Bewertung, die in der Kenntnis endet, beginnt mit dem, was das verdächtige Ereignis sichtbar gemacht hat.
Die Pflichten, die sich wie „führt eure Prüfungen aus“ lesen, sitzen in Art. 13 und Anhang I Teil II und gelten ab dem 11. Dezember 2027 (Art. 71(2), erster Satz). Für Produkte, die vor diesem Datum in Verkehr gebracht wurden, lässt Art. 69(2) sie „nur dann“ gelten, „wenn nach diesem Zeitpunkt diese Produkte einer wesentlichen Änderung unterliegen“. Rn. 210 des Leitlinienentwurfs nennt den Ausschluss für die Zeit vor 2027 ohne diesen Vorbehalt; verbindlich ist der Text im Amtsblatt, also zitiere ich Art. 69(2) für die Regel. Nichts in diesem Abschnitt ist am 11. September 2026 in Kraft.
Art. 13(7) verlangt, dass der Hersteller „systematisch und in einer der Art der Cybersicherheitsrisiken angemessenen Weise alle relevanten Cybersicherheitsaspekte des Produkts mit digitalen Elementen, einschließlich der Schwachstellen, von denen er Kenntnis erlangt“, dokumentiert. Art. 13(8) verlangt, dass Schwachstellen „während der erwarteten Produktlebensdauer und des Unterstützungszeitraums“ im Einklang mit Anhang I Teil II behandelt werden, dessen Nummer 3 vollständig lautet:
(3) die Sicherheit des Produkts mit digitalen Elementen regelmäßig und wirksam testen und überprüfen; >Anhang I, Teil II, Nummer 3, Verordnung (EU) 2024/2847
„Regelmäßig“ ist das Wort, das ein Team mit einem Scanner im Cron als „wöchentlich“ lesen wird. Der Leitlinienentwurf liest es anders:
Applying regular tests does not require the mechanical repetition, at fixed intervals, of an unchanged test campaign. It means regularly reviewing whether new input, such as newly identified threats or newly discovered vulnerabilities, requires the existing tests to be updated, and executing tests accordingly. >Sinngemäss: Regelmässige Tests anzuwenden verlangt nicht die mechanische Wiederholung einer unveränderten Testkampagne in festen Abständen. Es bedeutet, regelmässig zu prüfen, ob neuer Input, etwa neu erkannte Bedrohungen oder neu entdeckte Schwachstellen, eine Anpassung der bestehenden Tests erfordert, und die Tests entsprechend auszuführen. >Leitlinienentwurf, Anhang Rn. 238, S. 80
Rn. 239 bemisst Häufigkeit und Tiefe am Risikoprofil des Produkts und an dessen Entwicklung über die Zeit. Meine Lesart: „regelmäßig“ ist eine Pflicht, zu prüfen, wenn sich der Input ändert, und das Artefakt, das sie belegt, ist eines, das sagen kann, wann es erzeugt wurde und wie lange es gelten sollte. Ein undatiertes kann keines von beidem.
Angenommen, ein Dependency-Scan lief an einem Dienstag, wurde als PDF exportiert und in einen Nachweisordner gelegt. Er belegt, dass eine benannte Prüfung an diesem Datum lief, mit der Scanner-Version und der Advisory-Datenbank dieses Tages, und meldete, was sie meldete. Das ist der ganze Inhalt, und er ist nützlich: Er datiert, was Ihre eigenen Prüfungen bis zu diesem Dienstag zutage gefördert hatten.
Drei Dinge liegen ausserhalb dessen, was er belegt. Die Ausnutzung: Art. 3(42) verlangt verlässliche Nachweise dafür, dass ein böswilliger Akteur die Schwachstelle ausgenutzt hat, und ein Fund für sich ist dieser Nachweis nicht. Die Erreichbarkeit: der Test aus Rn. 218, ob die Schwachstelle einer Komponente überhaupt in Ihrem Produkt steckt. Die Zeit seither: ob die Prüfung am Mittwoch erneut lief, ob sich die Advisory-Daten geändert haben, ob der nächste Lauf den Fund noch gemacht hat. Der Ordner enthält eine Datei, die Änderungszeit der Datei ist der Upload, und das Datum des Laufs steht irgendwo im Inhalt, falls das Werkzeug es ausgegeben hat. Der Wert eines Scan-Artefakts ist genau sein Datum und das Fenster, das es abdecken sollte, und ein einzelnes undatiertes PDF beantwortet keine der beiden Hälften der Frage aus Rn. 217.
Nichts davon steht in der Verordnung oder im Leitlinienentwurf; keiner der beiden Texte verliert ein Wort über Scan-Ergebnisse. Was folgt, ist meine Ableitung.
Die erste Eigenschaft ist ein Erzeugungsdatum: der Moment, in dem die Prüfung lief, festgehalten am Artefakt selbst, getrennt von dem Moment, in dem jemand es hochgeladen hat.
Die zweite ist ein Aktualitätsfenster, ein Datum, nach dem das Artefakt nicht mehr zählt. Rn. 238 macht aus „regelmäßig“ eine Pflicht, bei verändertem Input zu prüfen; das Fenster ist also eine Obergrenze dafür, wie alt ein Ergebnis werden darf; das Laufintervall darunter ist, was das Risikoprofil rechtfertigt (Rn. 239).
Die dritte ist eine Ersetzungsregel, entschieden und aufgeschrieben: Entweder ersetzt das neueste Ergebnis das vorherige, oder es wird eine Historie geführt. Beides ist vertretbar; das Zweite ist die Aufbewahrungsfrage, die dieser Beitrag nicht löst.
Die vierte ist ein Secret-Gate, das läuft, bevor das Artefakt die Build-Umgebung verlässt. Die Analyse von Microsoft Security Research zur ChainDrop-Kompromittierung der Lieferkette über mehr als 400 npm-Pakete, veröffentlicht am 4. August 2026, beschreibt eine Payload, die aus einem Preinstall-Hook heraus lief. Weil „npm runs preinstall scripts before installation completes“ (Sinngemäss: npm Preinstall-Skripte ausführt, bevor die Installation abgeschlossen ist), konnte sie „on developer workstations and build runners before application tests or conventional security checks began“ ausgeführt werden (Sinngemäss: auf Entwickler-Workstations und Build-Runnern, bevor Anwendungstests oder herkömmliche Sicherheitsprüfungen begannen). Auf CI/CD-Systemen, so die Analyse, bleibt sie im laufenden Job und „collects credentials from local files, environment variables, command-line tools, and GitHub Actions runner memory“ (Sinngemäss: sammelt Zugangsdaten aus lokalen Dateien, Umgebungsvariablen, Kommandozeilenwerkzeugen und dem Arbeitsspeicher des GitHub-Actions-Runners). Ein auf einem Runner zusammengesetztes Artefakt trägt die Umgebung des Runners in sich, wenn der Befehl sie ausgibt, und eine Nachweisablage ist ein weiterer Ort, an dem ein Credential liegen kann, meist ausserhalb der Liste der Orte, von denen aus irgendjemand rotiert.
| Eigenschaft | Frage, die sie beantwortet | Was ohne sie bricht |
|---|---|---|
| Erzeugungsdatum | Wann hat unsere eigene Prüfung das zutage gefördert? (Art. 14(2); Rn. 217) | Das früheste Datum, das Sie zeigen können, ist das Upload-Datum. |
| Aktualitätsfenster | Soll dieses Ergebnis noch gelten? (Rn. 238) | Das Ergebnis vom letzten Jahr und das von letzter Woche sehen im Ordner gleich aus. |
| Ersetzungsregel | Welche Datei ist aktuell, und wird eine Historie geführt? (Art. 13(7); Art. 13(13) ist die andere Uhr) | Der Ordner wächst, und niemand kann sagen, welche Datei zählt. |
| Secret-Gate | Hat das Artefakt den Runner sauber verlassen? (ChainDrop) | Ein Credential reist in einem Bericht in eine Ablage, von der aus niemand rotiert. |
Ein Weg, einer wiederkehrenden Prüfung diese vier Eigenschaften zu geben, ist die CLI, die devguard auf npm als @devguardch/cli veröffentlicht und die sich selbst als evidence courier bezeichnet, als Kurier für Nachweise. devguard evidence push läuft, wenn Ihre CI oder Ihr Cron es aufruft, macht einen Durchgang über die in devguard.yml deklarierten Collectors und beendet sich; einen eigenen Zeitplan hat der Befehl nicht. Jeder Collector ist ein Befehl, den Sie ohnehin ausführen, oder ein auf dem Runner bereits installierter Scanner (Trivy, osv-scanner, grype oder npm audit); die CLI bringt keinen davon mit.
Bevor irgendein Collector läuft, prüft sie drei Dinge, ganz oder gar nicht: Der Schlüssel ist gültig, das Konto des Schlüssels ist Mitglied der Organisation, und jede Nachweisnummer in der Datei lässt sich auflösen. Ein fehlender Eintrag stoppt den Lauf; die CLI legt nie einen an.
Jede gepushte Datei wird mit dem Moment ihrer Erzeugung und dem Ende ihres Aktualitätsfensters gestempelt, 30 Tage, sofern der Collector nicht eine andere Dauer setzt oder never, was kein Fenster und keinen Eintrag auf der Fristen-Seite bedeutet. Die Ersetzungsregel lautet: Das Neueste ersetzt das Vorherige, pro Collector, ohne Historie; der Juli-Beitrag zu Aufbewahrung und Aktualität behandelt diese Regel und die zwei Datumsangaben an einem Eintrag. Das Secret-Gate läuft nach dem Befehl und vor jedem Upload, auch bei einem Dry Run. Es liest nur Textausgaben (binäre Artefakte werden übersprungen) und gleicht gegen einen kleinen, bewusst auf hohe Präzision ausgelegten Mustersatz ab: Cloud-Schlüssel, Header privater Schlüssel, bekannte Token-Formate und passwortartige Werte mit hoher Entropie. Ein Treffer blockiert den Upload dieses Collectors, die übrigen Collectors laufen weiter, und der Lauf endet mit einem Exit-Code ungleich null; eine Einstellung pro Collector oder --allow-secrets setzt das ausser Kraft.
Läuft ein Fenster ab, erscheint die Datei unter „Automatisierte Nachweise“ auf der Fristen-Seite. Die Personen in der Eigentümer-Rolle des Nachweises, falls er eine hat, werden in der App benachrichtigt, und per E-Mail, wo ihre E-Mail-Benachrichtigungen für Fristen eingeschaltet sind. Diese Benachrichtigung stammt aus der eigenen Fristenprüfung der App; die CLI hat also weiterhin keinen Scheduler. Ein Push ändert sonst nichts: Die Abdeckung des Controls, der Status des Nachweises und sein Review-Datum bleiben unangetastet.
[screenshot: evidence detail, a file badged Automated with its collector name]
Der Schlüssel, mit dem sich der Kurier authentifiziert, ist an das Konto gebunden, das ihn erstellt hat. Er handelt in jeder Organisation, der dieses Konto angehört, jeweils mit der Rolle des Kontos dort; es gibt keinen Nur-Lese-Schlüssel und keinen auf eine Organisation begrenzten Schlüssel. Ein CI-Secret, das ihn enthält, ist deshalb ein vollwertiges Credential für jede dieser Organisationen, und das ist die Klasse von Credential, um die es im ChainDrop-Absatz geht. Pushen können nur Eigentümer und Admins. Der Schlüssel eines Mitglieds besteht die Vorabprüfung, denn die prüft die Mitgliedschaft und nicht die Rolle. Abgewiesen wird er beim ersten Upload, nachdem die Collectors bereits gelaufen sind. Auf Ihrem eigenen Rechner legt devguard login den Schlüssel in einer Datei im Home-Verzeichnis ab, die nur Sie lesen können. Und die Grenze aus dem Juli: Ein aktueller Scan löst die Aktualität des Dokuments und nichts an der Aufbewahrung; die zehn Jahre aus Art. 13(13) gehören in den anderen Beitrag.
Geben Sie jedem Artefakt, das eine wiederkehrende Prüfung erzeugt, ein Erzeugungsdatum und ein Aktualitätsfenster. Entscheiden Sie schriftlich, ob das neueste Ergebnis das vorherige ersetzt oder eine Historie geführt wird, und welcher der zwei Uhren diese Entscheidung dient. Halten Sie Secrets aus dem Artefakt heraus, bevor es den Runner verlässt. Tun Sie diese drei Dinge, und das Ergebnis einer wiederkehrenden Prüfung kann für jeden beliebigen Tag zeigen, was Ihre eigenen Prüfungen bis dahin zutage gefördert hatten; ob verlässliche Nachweise einer Ausnutzung vorlagen, brauchte immer schon einen Menschen und eine Bewertung.
Die Einträge, die der Kurier befüllt, sind auf devguards Nachweis-Seite beschrieben.
Starten Sie kostenlos, bringen Sie Ihre Frameworks mit, und die Nachweise bleiben an der Arbeit, während sie ausgeliefert wird — ohne Setup-Reibung, ohne Feuerwehrübung in der Audit-Woche.
Starten Sie kostenlos, bringen Sie Ihre Frameworks mit, und die Nachweise bleiben an der Arbeit, während sie ausgeliefert wird — ohne Setup-Reibung, ohne Feuerwehrübung in der Audit-Woche.