Das EU-Gesetz zur Cyber-Resilienz und DevOps

Als ich in Deutschland lebte, sah ich, wie die DSGVO die Art und Weise veränderte, wie jedes Unternehmen mit persönlichen Daten umgeht. Das EU-Gesetz zur Cyber-Resilienz (CRA) soll für die Software-Sicherheit ähnliche Maßnahmen ergreifen. Und im Gegensatz zu vielen Vorschriften, landet es direkt auf den Dingen, die DevOps-Teams jeden Tag tun: Abhängigkeiten, Schwachstellenbearbeitung, Updates und Pipelines.

Ein kurzer Disclaimer, bevor wir anfangen: Ich bin Ingenieur, kein Anwalt. Das ist meine praktische Lesart, was es für Teams bedeutet. Für die spezifischen Verpflichtungen Ihres Unternehmens sprechen Sie mit Ihren Rechts- und Compliance-Mitarbeitern.

Was das Gesetz sagt, in einfachen Worten

Die CRA legt Cybersicherheitsanforderungen für "Produkte mit digitalen Elementen" in der EU verkauft. Das umfasst vieles: Software, Apps, vernetzte Geräte, Firmware und viele Komponenten, die in anderen Produkten landen.

Die Kernidee: Wenn Sie Software auf den EU-Markt bringen, sind Sie für ihre Sicherheit verantwortlich für sein ganzes LebenNicht nur am Veröffentlichungstag. Das bedeutet:

• Sicher durch Design und standardmäßig: keine bekannten Schwachstellen, die bei der Freigabe ausgenutzt werden können, sichere Standardkonfiguration, Datenschutz, minimale Angriffsfläche.
• Verarbeitung von Schwachstellen: ein Prozess zum Empfangen, Beurteil­nen und Beheben von Sicherheitslücken und zur Bereitstellung von Sicherheitsupdates für einen definierten Supportzeitraum (in der Regel mindestens fünf Jahre oder die erwartete Produktlebensdauer, falls kürzer).
• SBOMs: die Komponenten Ihres Produkts, zumindest die Abhängigkeiten auf oberster Ebene, in maschinenlesbarem Format dokumentieren.
• Berichterstattung: die aktiven Schwachstellen und schweren Vorfälle innerhalb enger Fristen den Behörden zu melden.
• Dokumentation und KonformitätDie Kommission hat die Kommission aufgefordert, die in den Artikeln 1 und 2 genannten Maßnahmen zu ergreifen. Die CE-Kennzeichnung ist auf den konformen Produkten zu finden.

Die Daten, die zählen

• Dezember 2024: die Zinssätze- und Zinssätzungsbehörde in Kraft getreten.
• 11. September 2026: Berichtspflichten gelten- Ich weiß . Die Hersteller müssen aktiv ausgenutzte Sicherheitslücken und schwerwiegende Vorfälle über die einheitliche Meldeplattform der ENISA melden. Eine Frühwarnung innerhalb von 24 Stunden, eine vollständige Benachrichtigung innerhalb von 72 Stunden und ein Abschlussbericht später.
• 11. Dezember 2027: die übrigen Anforderungen gelten, einschließlich der wesentlichen Sicherheitsanforderungen und der Konformitätsbewertung.

Der Bericht ist also schon live. Das komplette Set kommt nächstes Jahr.

Die CRA macht "wir werden es irgendwann reparieren" zu einer gesetzlichen Verpflichtung mit einer Frist.

Was ist mit Open Source?

Dies wurde während der Ausarbeitung heftig diskutiert. Der endgültige Text versucht, Open-Source-Entwickler zu schützen:

• Entwickelte und freigegebene Open-Source-Software ohne kommerzielle Tätigkeit ist im Allgemeinen außerhalb des Anwendungsbereichs.
• Eine neue Rolle, die Open-Source-Software-Steward (Verwalter der Software mit offenem Code) (z.B. Stiftungen, die Projekte unterstützen, die kommerziell genutzt werden), leichtere Verpflichtungen haben.
• Unternehmen, die Open Source in ihren kommerziellen Produkten verwenden für diese Bestandteile als Bestandteil ihres Produkts verantwortlich sind. Die Nutzung einer Bibliothek überträgt die Verantwortung nicht auf die Betreuer.

Dieser letzte Punkt ist für die meisten von uns am wichtigsten: Ihre Abhängigkeiten sind jetzt Ihre Verantwortung.

Was ändert sich in meiner Pipeline

Die nette Überraschung: vieles, was die CRA verlangt, ist, was gute DevSecOps-Teams bereits tun oder sollten. Es wird einfach obligatorisch und dokumentiert.

• SBOM-Generation für jede Version (Syft, Trivy, CycloneDX-Tools), die gespeichert und verändert wird.
• Kontinuierliches Sicherheitsschwachstellen-Scan Die neuen Sicherheitslücken in alten Versionen werden gefunden.
• Eine Sicherheitsanfälligkeits-Offenlegungsrichtlinie Die Forschungsergebnisse werden in den folgenden Bereichen erörtert: security.txt, ein Sicherheitsbeauftragter, ein SECURITY.md).
• Eine definierte Unterstützungsfrist für jede Produktversion und die Möglichkeit, während dieser Versionen schnell Sicherheitsupdates zu versenden.
• Unterschriftene Artefakte und Herkunft der Bauten, um die Integrität dessen zu zeigen, was Sie versenden.
• Sicherung von Standards in Ihren Produkten: keine Standardpasswörter, minimale offene Ports, verschlüsselte Funktionen.
• Ein Vorfall- und Berichtsverfahren die eine Frist von 24 Stunden für ausgenutzte Schwachstellen einhalten können. Wer entscheidet? Wer berichtet? Üben Sie es.
• Dokumentation von allen oben genannten.

Eine Checkliste

1. Finden Sie heraus, ob Ihre Produkte in den Anwendungsbereich fallen und in welcher Kategorie (die meisten gehören zur Standard-Selbstbewertungskategorie).
2. Erstellen und speichern Sie SBOMs für jede Freigabe.
3. Setzen Sie eine kontinuierliche Sicherheitsanfälligkeitsüberwachung der versandten Versionen ein.
4. Veröffentlichen Sie eine Sicherheitsanfälligkeits- und Sicherheitskontaktpolitik.
5. Definition und Kommunikation von Unterstützungszeiten.
6. Erstellen Sie einen Prozess, um ausgenutzte Schwachstellen innerhalb von 24 Stunden zu melden.
7. Sicherheitsupdates leicht zu liefern und soweit möglich von Feature-Updates zu trennen.
8. Dokumentation Ihrer sicheren Entwicklungspraktiken.
9. Überprüfen Sie Ihre Abhängigkeiten: Nicht gewartete Komponenten sind jetzt eine Belastung.

Sollten sich DevOps-Teams darum kümmern?

Sehr viel. Die CRA landet direkt in unseren Pipelines. Die Teams, die bereits SBOMs, Scannen, Signieren und Schnellpatchen automatisieren, werden die Einhaltung relativ einfach finden. Die Teams, die nicht ein Jahr Zeit haben, um aufzuholen.

Ich denke, die CRA ist eine Verordnung, aber das meiste davon ist nur gute Technik, die in Gesetz geschrieben ist. Wenn man sich diese Gewohnheiten jetzt aneignet, wird die Einhaltung ein Nebenprodukt.

Desly