Stand 11. August 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. Praktische Leitlinien der Kommission wurden am 27. Juli 2026 veröffentlicht. Meldepflichten gelten ab dem 11. September 2026; die Hauptanforderungen für Produkte ab dem 11. Dezember 2027. Dieser Leitfaden richtet sich an Softwareentwickler, deren Produkte möglicherweise betroffen sind, nicht an Konformitätsbewertungs-Juristen.
Zuerst ehrliche Einordnung: Das CRA ist kein Ersatz für SOC 2, ISO 27001 oder die DSGVO. Es ist kein "weiteres Compliance-Bot-Kästchen". Viele CRA-Pflichten betreffen Hersteller, Dokumentation und Nachmarktprozesse. Nur ein kleiner Teil kann in einem typischen Pull Request sichtbar werden: Abhängigkeitsinventar und SBOM-Aktualität, Schwachstellenmeldungswege und Sicherheitskontrollen, die als toter Code entfernt werden. Falls Ihr Rechts- oder Produktteam nicht bestätigt hat, dass das 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 die Meldepflichten im Zusammenhang mit dem Schwachstellen- und Vorfallmeldesystem der Verordnung für Hersteller gemäß dem Zeitplan der Verordnung und den Leitlinien der Kommission. Ab dem 11. Dezember 2027 gelten die Hauptanforderungen an die Produktsicherheit (einschließlich Secure-by-Design-Erwartungen, Schwachstellenmanagementprozesse und SBOM-Transparenz für Produkte mit digitalen Elementen) breiter. Die genaue Klassifizierung Ihres Produkts (Standard, wichtig, kritisch) ist eine rechtliche und Produktfrage, keine Entscheidung, die ein Code-Review trifft.
Behandeln Sie diese Daten als Planungsanker. Falls Korrekturen im Amtsblatt der EU oder weitere Leitlinien sie verschieben, überprüfen Sie diese Seite erneut (siehe das Datum-Register).
Was tatsächlich in einem Pull Request auffallen kann
Aktualität von Abhängigkeiten und SBOM: 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. Schwachstellenmanagementpfad: Eine Änderung entfernt oder deaktiviert einen Sicherheitskontakt, einen Advisory-Feed oder einen internen Webhook zur Schwachstellenbewertung, von dem Ihr CRA-konformer Prozess ausgeht, dass er existiert. Secure-by-Design-Erosion: Ein "Bereinigungs"-PR löscht die Authentifizierung an einem Admin-Port, deaktiviert Update-Prüfungen oder schaltet Integritätsprüfungen für Update-Pakete ab, weil sie lästig waren.
Das sind technische Muster. Sie stellen keine vollständige CRA-Konformitätsdatei, CE-Kennzeichnungsgeschichte oder benannte-Stelle-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 Äquivalent) ausführte und bei jedem Release-Tag ein SBOM-Artefakt hochlud. Die Dockerfile und die App bauen weiterhin. Tests bleiben grün. Review-Kommentare beziehen sich auf die Pipeline-Kosten. Wochen später kann das Sicherheitsteam nicht mehr beantworten, welche Versionen in 1.8.3 ausgeliefert wurden, ohne die Schichten zu rekonstruieren.
Falls Ihr Produkt im Geltungsbereich des CRA liegt und Ihr Prozess von diesem Inventar für das Schwachstellenmanagement und die Transparenz abhängt, 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. heygrc, das hier auf eine Framework-Kontrolle verweist, ist ein Signal, keine Feststellung, dass das Produkt nicht konform ist.
Explizit nicht abgedeckte Ziele
Dieser Leitfaden behandelt keine Konformitätsbewertungsmodule, CE-Kennzeichnung, Herstellerregistrierung, die Erstellung einer EU-Konformitätserklärung oder die Frage, ob Ihr Produkt nach der Verordnung als "wichtig" oder "kritisch" eingestuft wird. Er behauptet nicht, dass heygrc ein Produkt CRA-konform macht. Er ersetzt nicht Ihr PSIRT, Ihre Rechtsprüfung oder Ihren Marktüberwachungs-Reaktionsplan.
Falls Sie für Kunden nur SOC 2 oder ISO 27001 benötigen, ist das 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 Entwicklungs-Hygiene liegt die nützliche Überschneidung in derselben Klasse von Befunden wie sichere Entwicklung und Schwachstellenmanagement nach anderen Frameworks (z. B. NIS 2 Art. 21 Softwareanforderungen, ISO 27001 Kontrollen für sichere Entwicklung): entfernte Update-Integritätsprüfungen, 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 Ihren Code-Reviewer. 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 ausgehen, dass es noch läuft.