Digitale Produkte für den Cyber Resilience Act entwickeln

Wenn Sie Software oder Hardwareprodukte mit Softwarekomponenten verkaufen, die in die EU geliefert werden, müssen Sie sich auf den Cyber Resilience Act (CRA) vorbereiten. Der CRA ist eine neue EU-Verordnung, die ab 2026 gilt und die Sicherheitsanforderungen für jedes digitale Produkt auf dem Markt deutlich erhöht – darunter Apps, Hardware, Firmware, vernetzte Geräte wie Wearables und vieles mehr. Der CRA wurde eingeführt, um die Risiken durch böswillige Akteure zu reduzieren, die zunehmend die Software-Lieferkette ins Visier nehmen.

Der CRA schreibt Security by Design vor und verlangt die Implementierung von sicherem Code als festen Bestandteil des Software-Development-Lifecycle. Damit stellt sich für Engineering-, Plattform- und DevOps-Teams eine zentrale Frage: Wie lassen sich die CRA-Anforderungen erfüllen, ohne die Entwicklungsgeschwindigkeit zu beeinträchtigen?

Hier kommt Chainguard ins Spiel. Chainguard teilt das vom CRA propagierte Prinzip „secure by default“ und bringt den Produktentwicklungsprozess schnell in Einklang mit den CRA-Vorgaben. Chainguard übernimmt die Arbeit rund um Schwachstellen, Security-Best-Practices und sichere Build-Prozesse, reduziert manuellen Aufwand erheblich und spart wertvolle Zeit.

Warum der CRA wichtig ist

Der CRA gilt für „Produkte mit digitalen Elementen“ (Products with Digital Elements, PDEs) – im Grunde alles, was Software ausführt. Ob reines SaaS-Produkt oder IoT-Gerät: Sobald EU-Kund:innen erreicht werden, greift der CRA. Neben dem erheblichen Marken- und Vertrauensschaden bei Nichteinhaltung drohen empfindliche finanzielle Konsequenzen: Bußgelder zwischen 5 und 15 Millionen Euro oder 2,5 % des weltweiten Jahresumsatzes.

Die Durchsetzungsphasen beginnen 2026 und sind bis 2027 vollständig wirksam:

• Konformitätsbewertung ab dem 11. Juni 2026

• Verpflichtende Meldung von Schwachstellen und Sicherheitsvorfällen ab dem 11. September 2026

• Vollständige Anwendung aller Anforderungen für neue Produkte ab dem 11. Dezember 2027

Das „Warum“ hinter dem CRA erklärt, weshalb sich die Regulierung auf Engineering-Praktiken und nicht nur auf das Endprodukt konzentriert:

• Über 245.000 bösartige Open-Source-Pakete wurden 2023 entdeckt

• Der SolarWinds-Vorfall zeigte, wie eine einzige kompromittierte Build-Pipeline zehntausende Organisationen betreffen kann

• npm-Kompromittierungen haben Milliarden von Downloads erreicht

• KI-gestützte Supply-Chain-Angriffe erhöhen rasant Reichweite und Präzision

Der CRA fordert, dass Produkte so konzipiert, entwickelt und hergestellt werden, dass ein angemessenes Sicherheitsniveau gewährleistet ist. Für viele Organisationen bedeutet das ein Umdenken bei Entwicklung, Updates, Patching und Auslieferung von Software.

Vor Chainguard: So sieht CRA-Compliance heute oft aus

Die Realität in vielen Teams: Chaos bei Base Images, weil Entwickler:innen ungeprüfte öffentliche Images verwenden – „weil es funktioniert“. Daraufhin häufen sich Schwachstellen, da diese Images nicht mit Security-Prinzipien erstellt wurden. Tickets zur Behebung werden eröffnet, was erheblichen Mehraufwand verursacht: Ursachen analysieren, Fixes umsetzen, Abhängigkeiten aktualisieren. Liefertermine verzögern sich, Sicherheit leidet.

Für Security-Audits oder nach Vorfällen müssen Teams hektisch Risikoanalysen und Root-Cause-Analysen durchführen. Notfall-Patches für kritische CVEs führen häufig zu inkonsistenten, nicht reproduzierbaren Builds: lokal gebaut, aber im CI anders. Die Herkunft der Komponenten ist unklar, Transparenz in der fragmentierten Supply Chain gering. SBOMs im Nachhinein zu erstellen, gleicht dem Versuch, Humpty Dumpty wieder zusammenzusetzen.

All das widerspricht den CRA-Vorgaben – und bremst die Engineering-Geschwindigkeit massiv aus.

Nach Chainguard: CRA-ready, sichere Grundlagen direkt im Workflow

Chainguard bietet secure-by-default-Bausteine – gehärtete Container-Images, VMs und Sprachbibliotheken – und verlagert Sicherheit von reaktiv zu standardmäßig sicher.

Nach der Einführung von Chainguard sieht DevOps völlig anders aus. Statt mit ungeprüften, aufgeblähten Distribution-Images mit potenziell hunderten Schwachstellen zu starten, beginnen Sie mit:

• einem Zero-CVE-Distroless-Image

• Non-Root-User standardmäßig

• keiner Shell

• keinem Package Manager

Zusätzlich zur sicheren Basis bietet Chainguard kontinuierliches Patching: tägliche Updates der Images und eine 7-Tage-SLA für kritische CVEs. Sie müssen lediglich Ihre Anwendung neu bauen – und sind aktuell. Builds enthalten automatisch vollständige SBOMs und Attestierungen. Jedes Chainguard-Artefakt wird mit einer signierten SBOM, klarer Provenienz und unveränderlicher Versionierung ausgeliefert.

Damit erfüllen Sie mehrere Anforderungen aus CRA Anhang I sofort. Wenn Regulierungsbehörden oder Security-Teams fragen: „Woher stammt das?“, haben Sie die Antwort parat.

CRA und Chainguard: Compliance ohne Geschwindigkeitsverlust

Für Engineering-Teams bringt der CRA nicht nur neue Regeln, sondern zwingt zu einem stärkeren Fokus auf Bereiche, die oft herausfordernd sind. Chainguard ermöglicht es, CRA-Anforderungen zu erfüllen, ohne Entwicklung zu verlangsamen, ohne zusätzlichen manuellen Aufwand und ohne ein eigenes Security-Framework von Grund auf zu bauen.

Mit secure-by-default-Bausteinen:

• Eliminieren Sie CVE-Backlogs

• Reduzieren Sie Engineering-Aufwand für Patches und damit verbundenen Overhead

• Erhöhen Sie die Transparenz in der Supply Chain

• Erfüllen Sie CRA-Anforderungen als natürlichen Bestandteil Ihres Entwicklungsprozesses

Chainguard bietet eine sichere Grundlage für moderne Softwareentwicklung – damit Sie weiterhin schnell liefern und gleichzeitig Sicherheits- und Compliance-Anforderungen wie den CRA erfüllen können.

Kontaktieren Sie unser Team, um mehr darüber zu erfahren, wie wir Sie bei der Umsetzung der CRA-Anforderungen unterstützen können.