Stand vom 13. September 2026. Die EU-Cyber-Resilience-Verordnung (Verordnung (EU) 2024/2847) legt Cybersicherheitsanforderungen für Produkte mit digitalen Elementen fest, die auf dem Unionsmarkt bereitgestellt werden. Die praktische Leitlinie der Kommission wurde am 27. Juli 2026 veröffentlicht. Meldepflichten im Zusammenhang mit dem Gesetz gelten ab dem 11. September 2026; die Hauptanforderungen für Produkte gelten ab dem 11. Dezember 2027. Dieser Leitfaden richtet sich an Softwareentwickler, deren Produkte möglicherweise betroffen sind, nicht an Juristen für Konformitätsbewertungen.
Zuerst Ehrlichkeit beim Anwendungsbereich: Der CRA ist kein Ersatz für SOC 2, ISO 27001 oder die DSGVO. Es handelt sich nicht um eine weitere Compliance-Checkbox für Bots. Viele CRA-Pflichten betreffen Hersteller, Dokumentation und Prozesse nach der Markteinführung. Nur ein Teil davon kann in einem typischen Anwendungs-Pull-Request sichtbar werden: Aktualität von Abhängigkeiten und SBOMs, Meldewege für Schwachstellen sowie Sicherheitskontrollen, die als toter Code entfernt werden. Falls Ihr Rechts- oder Produktteam noch nicht bestätigt hat, dass der CRA für Ihre Produkte gilt, brechen Sie hier ab und fragen Sie nach.
Was wann in Kraft tritt (Entwicklerkalender)
Ab dem 11. September 2026 gelten Meldepflichten im Zusammenhang mit dem Schwachstellen- und Vorfallsmeldesystem des CRA für Hersteller gemäß den in der Verordnung und den Leitlinien der Kommission festgelegten Fristen. Ab dem 11. Dezember 2027 gelten die wichtigsten Cybersicherheitsanforderungen für Produkte (einschließlich Secure-by-Design-Erwartungen, Prozesse zur Schwachstellenbehandlung und SBOM-Transparenz für Produkte mit digitalen Elementen) breiter. Die genaue Klassifizierung Ihres Produkts (Standard, wichtig, kritisch) ist eine rechtliche und produktbezogene Frage, die nicht durch ein Code-Review entschieden wird.
Behandeln Sie diese Daten als Planungsanker. Falls Korrekturen im Amtsblatt der EU oder weitere Leitlinien diese verschieben, überprüfen Sie diese Seite erneut (siehe das Datum-Register).
Was tatsächlich in einem Pull Request sichtbar werden kann
Aktualität von Abhängigkeiten und SBOMs: Eine Änderung fixiert eine veraltete Komponente, entfernt die Generierung einer Software-Stückliste aus der CI oder stellt die Veröffentlichung des Komponenteninventars ein, auf das Ihr Schwachstellenprozess angewiesen ist. Meldeweg für Schwachstellen: Eine Änderung entfernt oder deaktiviert einen Sicherheitskontakt, einen Advisory-Feed oder einen internen Webhook zur Schwachstellen-Triage, von dem Ihr CRA-konformer Prozess ausgeht, dass er existiert. Erosion von Secure-by-Design: Ein "Bereinigungs"-PR löscht die Authentifizierung an einem Admin-Port, deaktiviert Update-Prüfungen oder schaltet die Integritätsprüfung von Update-Paketen ab, weil sie als störend empfunden wurden.
Das sind technische Muster. Sie stellen keine vollständige CRA-Konformitätsdatei, CE-Kennzeichnungsgeschichte oder Benannte-Stellen-Bewertung dar.
Praktisches Beispiel: CI stellt die Ausgabe des Komponenteninventars ein
Ein Plattformteam verkürzt die CI um zwei Minuten, indem es einen Job löscht, der syft (oder ein Äquivalent) ausführte und bei jedem Release-Tag ein SBOM-Artefakt hochlud. Die Dockerfile und die Anwendung bauen weiterhin. Die Tests bleiben grün. Review-Kommentare beziehen sich auf die Pipeline-Kosten. Wochen später kann das Sicherheitsteam die Frage "Welche Versionen wurden in 1.8.3 ausgeliefert?" nicht beantworten, ohne die Schichten zu rekonstruieren.
Falls Ihr Produkt im Anwendungsbereich des CRA liegt und Ihr Prozess für die Schwachstellenbehandlung und Transparenz auf dieses Inventar angewiesen ist, ist das Löschen des Jobs keine neutrale Hygienemaßnahme. Ein Compliance-bewusstes Review markiert den Verlust des Inventar-Schritts im PR, sodass Produkt und Sicherheit das Risiko formal akzeptieren oder den Job wiederherstellen können. Wenn heygrc hier auf eine Framework-Kontrolle verweist, ist dies ein Hinweis, keine Feststellung, dass das Produkt nicht konform ist.
Explizite Nicht-Ziele
Dieser Leitfaden behandelt keine Konformitätsbewertungsmodule, CE-Kennzeichnung, Herstellerregistrierung, die Erstellung einer EU-Konformitätserklärung oder die Frage, ob Ihr Produkt nach dem CRA als "wichtig" oder "kritisch" eingestuft wird. Er behauptet nicht, dass heygrc ein Produkt CRA-konform macht. Er ersetzt nicht Ihr PSIRT, Ihre rechtliche Prüfung oder Ihren Marktüberwachungs-Reaktionsplan.
Falls Sie für Kunden nur SOC 2 oder ISO 27001 benötigen, ist der CRA möglicherweise weiterhin irrelevant. Erzwingen Sie keine Anpassung.
Wo heygrc passt und die Ehrlichkeitsgrenze
heygrc ist darauf ausgelegt, kontrollrelevante Änderungen in Pull Requests gegenüber den von Ihnen aktivierten Frameworks anzuzeigen. Für CRA-nahe technische Hygiene liegt die nützliche Überschneidung in derselben Klasse von Befunden wie bei sicherer Entwicklung und Schwachstellenbehandlung nach anderen Frameworks (z. B. NIS 2 Art. 21 Softwareanforderungen, ISO 27001-Kontrollen für sichere Entwicklung): entfernte Integritätsprüfungen für Updates, geschwächte Authentifizierung, gelöschte Inventar-Jobs. Mappen Sie sorgfältig; erfinden Sie keine CRA-Artikelnummern für Befunde, es sei denn, Ihre aktivierte Wissensdatenbank enthält sie.
Behalten Sie SAST, Abhängigkeitsscanner und Ihre Code-Reviewer bei. Das CRA-Produktgesetz liegt größtenteils außerhalb des Diffs. Der Diff erfasst nur den Teil, der stillschweigend das löscht, von dem diese Programme annehmen, dass es noch läuft.