CRA und Softwareentwicklung: Security by Design als Pflicht

Ab dem 11. Dezember 2027 darf kein Produkt mit digitalen Elementen mehr auf den EU-Markt gebracht werden, das die Anforderungen des Cyber Resilience Act (CRA) nicht erfüllt. Für Softwarehersteller bedeutet das: Security by Design ist keine Best Practice mehr – es ist Gesetz.

Die Konsequenzen bei Nichteinhaltung sind erheblich: Bis zu 15 Millionen Euro oder 2,5% des globalen Jahresumsatzes. Marktaufsichtsbehörden können den Verkauf stoppen oder Rückrufe anordnen. Und die Anforderungen betreffen nicht nur das fertige Produkt, sondern den gesamten Entwicklungsprozess – von der ersten Codezeile bis zum letzten Sicherheitsupdate.

Dieser Artikel zeigt Ihnen, was der CRA konkret für Ihre Softwareentwicklung bedeutet, welche Pflichten auf Sie zukommen, und wie Sie Ihre CI/CD-Pipelines CRA-konform aufstellen.

Was der CRA für Softwareentwicklung bedeutet

Der CRA richtet sich an Hersteller von "Produkten mit digitalen Elementen". Das umfasst jede kommerzielle Software, die auf dem EU-Markt vertrieben wird – ob als Standalone-Anwendung, Firmware, SaaS mit Client-Komponente oder eingebettete Software in Hardware.

Die zentrale Anforderung: Produkte müssen während ihres gesamten Lebenszyklus sicher sein. Das beginnt beim Design, geht über die Entwicklung und reicht bis zur Außerbetriebnahme. Artikel 13 des CRA definiert die Pflichten des Herstellers – und die sind umfassend.

Für eine umfassende Übersicht zum CRA-Compliance-Prozess: CRA Compliance im Detail.

SBOM: Die Stückliste Ihrer Software

Eine Software Bill of Materials (SBOM) ist das Herzstück der CRA-Compliance für Entwicklungsteams. Sie dokumentiert alle Komponenten, aus denen Ihre Software besteht – ähnlich einer Zutatenliste bei Lebensmitteln.

Warum die SBOM so wichtig ist

Moderne Software besteht zu 70–90% aus Open-Source-Komponenten. Wenn eine Schwachstelle wie Log4Shell bekannt wird, müssen Sie innerhalb von Stunden wissen, ob Ihr Produkt betroffen ist. Ohne SBOM ist das ein manueller, fehleranfälliger Prozess, der Tage dauern kann. Mit SBOM dauert es Minuten.

Der CRA fordert in Artikel 13 (5), dass Hersteller eine SBOM erstellen und pflegen. Die EU-Kommission wird das genaue Format noch spezifizieren, aber zwei Standards haben sich etabliert:

SBOM in der Praxis implementieren

Eine SBOM muss automatisiert generiert werden – manuelle Pflege skaliert nicht. Integrieren Sie die Generierung in Ihren Build-Prozess.

Minimale SBOM-Inhalte nach CRA:

• Name und Version jeder Komponente
• Lieferant bzw. Herkunft
• Abhängigkeitsbeziehungen (direkt und transitiv)
• Bekannte Schwachstellen zum Zeitpunkt der Auslieferung
• Lizenzinformationen

Tools für die SBOM-Generierung:

Empfehlung: Generieren Sie die SBOM bei jedem Build und speichern Sie sie versioniert. So können Sie jederzeit nachweisen, welche Komponenten in welcher Produktversion enthalten waren.

Schwachstellen-Management: Die 24-Stunden-Pflicht

Artikel 14 des CRA schreibt vor: Innerhalb von 24 Stunden nach Bekanntwerden einer aktiv ausgenutzten Schwachstelle müssen Sie die ENISA (EU-Agentur für Cybersicherheit) informieren. Innerhalb von 72 Stunden folgt ein detaillierter Bericht. Das ist ambitioniert – und ohne strukturierte Prozesse nicht machbar.

Was das konkret bedeutet

Schwachstellen-Management-Prozess aufbauen

Ein CRA-konformes Schwachstellen-Management umfasst fünf Kernelemente:

1. Kontinuierliches Monitoring: Überwachen Sie Ihre Abhängigkeiten automatisch auf neue CVEs. Tools wie Dependabot, Snyk oder OWASP Dependency-Track gleichen Ihre SBOM kontinuierlich gegen Schwachstellen-Datenbanken ab.

2. Triage und Priorisierung: Nicht jede Schwachstelle hat die gleiche Kritikalität. Nutzen Sie CVSS-Scores als Ausgangspunkt, aber bewerten Sie immer im Kontext Ihrer Anwendung. Eine kritische Schwachstelle in einer Bibliothek, deren betroffene Funktion Sie nicht nutzen, hat eine andere Priorität als eine mittlere Schwachstelle in einem exponierten Eingabepfad.

3. Koordinierte Offenlegung: Der CRA verlangt, dass Hersteller einen Prozess für die koordinierte Schwachstellen-Offenlegung (Coordinated Vulnerability Disclosure) etablieren. Das bedeutet: eine öffentlich erreichbare Kontaktmöglichkeit für Sicherheitsforscher, definierte Reaktionszeiten und eine Vulnerability Disclosure Policy.

4. Patch-Entwicklung und -Verteilung: Sicherheitspatches müssen zeitnah entwickelt, getestet und verteilt werden. Der CRA fordert, dass Patches kostenlos und separat von Feature-Updates bereitgestellt werden – Nutzer sollen nicht gezwungen sein, ein Feature-Update zu installieren, nur um eine Sicherheitslücke zu schließen.

5. Dokumentation: Jeder Schritt muss nachvollziehbar dokumentiert werden. Wann wurde die Schwachstelle bekannt? Wann wurde die ENISA informiert? Welche Maßnahmen wurden ergriffen? Diese Dokumentation ist bei einer Prüfung durch Marktaufsichtsbehörden entscheidend.

Wie Sie Schwachstellen-Management in einen sicheren Entwicklungslebenszyklus einbetten: SSDLC – Secure Software Development Lifecycle.

Update-Pflicht: Mindestens 5 Jahre

Einer der folgenreichsten Aspekte des CRA: Hersteller müssen für mindestens 5 Jahre nach Inverkehrbringen Sicherheitsupdates bereitstellen. Oder länger, wenn die erwartete Produktlebensdauer es erfordert.

Was das für Ihre Planung bedeutet

Die strategische Konsequenz: Sie müssen Ihre Software so architektieren, dass Sicherheitsupdates auch nach Jahren noch möglich sind. Das bedeutet:

• Modulare Architektur: Sicherheitsrelevante Komponenten müssen austauschbar sein, ohne das gesamte Produkt neu zu bauen.
• Langfristige Abhängigkeiten-Strategie: Wenn eine Bibliothek, die Sie nutzen, in drei Jahren End-of-Life geht, müssen Sie einen Plan haben.
• Update-Infrastruktur: Sie brauchen einen zuverlässigen Kanal, um Updates an Ihre Nutzer zu verteilen – und nachweisen zu können, dass Updates verfügbar gemacht wurden.
• Budgetplanung: Die 5-Jahres-Pflicht muss in die Produktkalkulation einfließen. Sicherheitsupdates sind kein optionaler Service, sondern eine gesetzliche Verpflichtung.

Open Source und der CRA

Die Behandlung von Open-Source-Software war einer der meistdiskutierten Aspekte bei der CRA-Verhandlung. Das Ergebnis ist differenziert – und für Unternehmen relevant.

Wer ist betroffen?

Nicht betroffen sind Open-Source-Projekte, die ohne kommerzielle Absicht entwickelt werden. Ein Hobby-Projekt auf GitHub fällt nicht unter den CRA, selbst wenn es von Unternehmen genutzt wird.

Betroffen sind:

• Unternehmen, die Open Source kommerziell einsetzen: Sie sind als Hersteller verantwortlich für die Sicherheit des Gesamtprodukts – einschließlich aller Open-Source-Komponenten.
• Open Source Stewards: Der CRA führt den neuen Begriff "Open Source Software Steward" ein. Das sind Organisationen (z.B. Stiftungen), die die Entwicklung von Open Source mit kommerzieller Absicht systematisch unterstützen. Sie haben reduzierte Pflichten, müssen aber einen Sicherheitsprozess nachweisen.
• Kommerzielle Open-Source-Anbieter: Wer Open Source mit kommerziellem Support oder als Teil eines kommerziellen Produkts anbietet, unterliegt den vollen CRA-Pflichten.

Konsequenzen für Ihr Unternehmen

Wenn Sie Open-Source-Bibliotheken in Ihrem Produkt verwenden – und das tun Sie fast sicher – tragen Sie die Verantwortung für deren Sicherheit. Das bedeutet:

• Jede eingebundene Open-Source-Komponente muss in der SBOM erfasst sein
• Sie müssen Schwachstellen in diesen Komponenten überwachen und darauf reagieren
• Wenn ein Upstream-Projekt eine Schwachstelle nicht behebt, müssen Sie selbst einen Fix bereitstellen oder die Komponente ersetzen
• Die 5-Jahres-Update-Pflicht gilt auch für Schwachstellen in Open-Source-Abhängigkeiten

Praktische Empfehlung: Führen Sie eine Risikobewertung Ihrer Open-Source-Abhängigkeiten durch. Wie aktiv wird das Projekt gepflegt? Gibt es einen Security-Response-Prozess? Wie schnell werden Schwachstellen behoben? Projekte mit niedrigem Maintenance-Level in kritischen Pfaden sind ein CRA-Risiko.

CRA-konforme CI/CD-Pipelines

Die größte Hebelwirkung für CRA-Compliance erzielen Sie, wenn Sie die Anforderungen direkt in Ihre CI/CD-Pipeline integrieren. Statt manueller Prüfungen vor jedem Release automatisieren Sie die Compliance-Checks als Quality Gates.

Pipeline-Architektur für CRA-Compliance

Eine CRA-konforme Pipeline erweitert den klassischen Build-Test-Deploy-Prozess um Sicherheits- und Compliance-Schritte:

Quality Gates definieren

Definieren Sie klare Kriterien, wann ein Build die Pipeline passieren darf und wann nicht. Diese Gates müssen dokumentiert und auditierbar sein.

Empfohlene Quality Gates:

• Keine kritischen oder hohen Schwachstellen in Abhängigkeiten ohne dokumentierte Risikobewertung
• SBOM erfolgreich generiert und alle Komponenten aufgelöst
• Statische Analyse bestanden – keine Findings der Kategorie "Critical"
• Alle Sicherheitstests bestanden – SAST, SCA, Container Scan
• Artefakte signiert – Build-Integrität nachweisbar

Wichtig: Ein Quality Gate, das permanent übergangen wird, ist wertlos. Definieren Sie einen klaren Eskalationsprozess, wenn ein Gate blockiert, und dokumentieren Sie jede Ausnahme mit Begründung und Risikobewertung.

Wie Security Champions in Entwicklungsteams diese Prozesse verankern: OWASP Security Champion Programm.

Supply Chain Security

Der CRA fordert Integritätsschutz für die gesamte Software-Lieferkette. Das umfasst:

• Build-Reproduzierbarkeit: Können Sie nachweisen, dass ein bestimmtes Artefakt aus einem bestimmten Quellcode entstanden ist?
• Artefakt-Signierung: Signieren Sie Ihre Build-Artefakte kryptographisch, damit Nutzer deren Integrität prüfen können.
• SLSA-Framework: Das Supply-chain Levels for Software Artifacts Framework bietet ein Reifegradmodell für Supply Chain Security – von SLSA Level 1 (Dokumentation) bis SLSA Level 4 (hermetische Builds).
• Abhängigkeiten-Pinning: Nutzen Sie Lockfiles und überprüfen Sie Checksummen. Ein manipuliertes Paket in Ihrer Dependency-Chain kann Ihr gesamtes Produkt kompromittieren.

Zum Thema API-Absicherung in der Lieferkette: API Security für AI-Systeme.

Dokumentationspflichten: Was Sie nachweisen müssen

Die technische Dokumentation nach Anhang VII des CRA ist umfangreich. Für Entwicklungsteams sind insbesondere folgende Nachweise relevant:

Automatisierung ist entscheidend. Generieren Sie so viel Dokumentation wie möglich automatisch aus Ihrer Pipeline. SBOM, Test-Ergebnisse und Schwachstellen-Reports lassen sich direkt aus den CI/CD-Tools exportieren. Das reduziert den manuellen Aufwand und stellt sicher, dass die Dokumentation immer aktuell ist.

Praxisfahrplan: In 6 Schritten zur CRA-konformen Entwicklung

Schritt 1: Bestandsaufnahme (Monat 1)

• Inventarisieren Sie alle Produkte, die unter den CRA fallen
• Erfassen Sie aktuelle Entwicklungsprozesse und -tools
• Identifizieren Sie Gaps zu den CRA-Anforderungen

Schritt 2: SBOM-Prozess etablieren (Monat 2)

• Wählen Sie ein SBOM-Format (CycloneDX empfohlen)
• Integrieren Sie SBOM-Generierung in den Build-Prozess
• Richten Sie SBOM-Management ein (z.B. OWASP Dependency-Track)

Schritt 3: Schwachstellen-Management aufsetzen (Monat 2–3)

• Implementieren Sie automatisiertes Schwachstellen-Scanning
• Definieren Sie Triage-Prozess und Verantwortlichkeiten
• Erstellen Sie eine Vulnerability Disclosure Policy
• Testen Sie den 24-Stunden-Meldeprozess

Schritt 4: CI/CD-Pipeline erweitern (Monat 3–4)

• Integrieren Sie SAST, SCA und Container-Scanning
• Definieren Sie Quality Gates mit klaren Schwellenwerten
• Implementieren Sie Artefakt-Signierung
• Automatisieren Sie die Dokumentationsgenerierung

Schritt 5: Update-Strategie definieren (Monat 4–5)

• Planen Sie die 5-Jahres-Update-Pflicht in die Produktarchitektur ein
• Etablieren Sie einen separaten Kanal für Sicherheitsupdates
• Definieren Sie SLAs für Patch-Bereitstellung nach Kritikalität

Schritt 6: Auditierung und Verbesserung (Monat 6, dann fortlaufend)

• Führen Sie ein internes Audit gegen die CRA-Anforderungen durch
• Dokumentieren Sie verbleibende Gaps und Mitigationspläne
• Etablieren Sie quartalsweise Reviews des gesamten Prozesses

Fazit: Früh starten, systematisch aufbauen

Der CRA macht Security by Design zur gesetzlichen Pflicht. Das ist ein Paradigmenwechsel für Unternehmen, die Sicherheit bisher als nachgelagertes Thema behandelt haben. Aber es ist auch eine Chance: Wer seine Entwicklungsprozesse jetzt CRA-konform aufstellt, reduziert nicht nur regulatorische Risiken, sondern baut robustere Software.

Die drei wichtigsten Sofortmaßnahmen:

1. SBOM-Generierung automatisieren – das ist die Grundlage für alles Weitere und in wenigen Tagen implementierbar.
2. Schwachstellen-Scanning in die Pipeline integrieren – Tools wie Trivy oder Snyk lassen sich mit minimalem Aufwand einbinden.
3. 24-Stunden-Meldeprozess definieren – dieser Prozess muss stehen, bevor die erste kritische Schwachstelle auftaucht.

Die technischen Maßnahmen sind überschaubar. Die größere Herausforderung liegt in der organisatorischen Verankerung: klare Verantwortlichkeiten, dokumentierte Prozesse und eine Kultur, in der Sicherheit kein Hindernis ist, sondern integraler Bestandteil der Softwareentwicklung.

Weiterführend

• CRA Compliance – Der vollständige Compliance-Leitfaden
• SSDLC – Sicherer Entwicklungslebenszyklus im Detail
• OWASP Security Champion – Security in Entwicklungsteams verankern
• API Security – Schnittstellen absichern