Der Cyber Resilience Act (CRA) bringt erstmals EU-weit verbindliche Cybersecurity-Anforderungen für viele digitale Produkte – und trifft damit auch Software-Entwickler direkt: Sicherheit muss von der Idee bis zum Patch als durchgängiger Prozess organisiert und nachweisbar gemacht werden. Wir zeigen, wo bei der Software-Entwicklung unter dem CRA die größten Hürden liegen und wie Sie die Anforderungen in Entwicklungs- und Release-Prozesse übersetzen.
Warum trifft der CRA Software-Entwickler besonders hart?
Der CRA zielt darauf ab, das Sicherheitsniveau von Produkten mit digitalen Elementen in der Europäischen Union zu erhöhen. Für Software-Entwickler ist das nicht nur ein regulatorisches Thema, sondern ein operatives: Die Anforderungen betreffen Produktstrategie, Architektur, Entwicklung, Betrieb, Support und Lieferkettenmanagement.
Besonders praxisrelevant wird der CRA, weil typische Realitäten bei mittelständischen Software-Entwicklern – knappe Ressourcen, parallele Kundenprojekte, gewachsene Toolchains – mit der Erwartung kollidieren, Security by Design und Security by Default systematisch umzusetzen und nachzuweisen.
Hinzu kommt: Viele Produkte bestehen heute aus eigener Software plus Open-Source-Komponenten, Cloud-Diensten, Bibliotheken, Container-Images und Build-Pipelines. Genau dort entstehen die Risiken, die der CRA adressiert. Konkret müssen Software-Anbieter Sicherheitsanforderungen als Produktanforderungen verankern, ein durchgängiges Vulnerabilitätsmanagement aufbauen, Entscheidungen und Tests nachvollziehbar dokumentieren sowie Lieferketten transparent machen – von der Software Bill of Materials (SBOM) bis hin zu belastbaren Patch- und Incident-Prozessen.
Die größten Hürden des CRA bei der Software-Entwicklung
Wie gelingt Security by Design ohne den Entwicklungsprozess zu blockieren?
Kleine und mittelständische Unternehmen (KMU) entwickeln Software und digitale Tools häufig unter Zeitdruck, mit enger Kundenbindung und kurzen Entscheidungswegen. Das ist ein Vorteil, führt aber auch häufig dazu, dass Sicherheitsanforderungen erst spät sichtbar werden.
In der Praxis entstehen die größten Lücken dort, wo Architekturentscheidungen – etwa zur Mandantenfähigkeit, Authentifizierung oder Datenflüssen – ohne explizite Security-Anforderungen getroffen werden. Hinzu kommt: Feature-Toggles oder Debug-Endpunkte verbleiben häufig unbeabsichtigt in der Produktion, sichere Defaults fehlen, weil Konfigurationen historisch gewachsen sind.
Doch wenn Bedrohungsmodelle oder Kryptographie-Entscheidungen erst kurz vor dem Release auftauchen, drohen Verzögerungen, Ad-hoc-Fixes und technische Schulden.
Unsere Erfahrung aus der Zusammenarbeit mit zahlreichen Unternehmen der Branche zeigt, dass Sicherheit in der Software-Entwicklung nicht ein separater Nebenschauplatz sein darf, der dann irgendwann mal gemacht wird. Stattdessen sollten die Prinzipien von Security by Design und Security by Default ein elementarer Bestandteil eines ganzheitlichen Prozesses sein, der von Anfang an mitgedacht werden muss.
Der CRA verstärkt diesbezüglich den Druck, Security als nicht-funktionale Kernanforderung an Software bereits in der Produktdefinition zu verankern – inklusive klarer Akzeptanzkriterien in User Stories und Definition-of-Done.
So verlangt der CRA, dass Sicherheit in der Software-Entwicklung ein klar definierter Prozess ist, der abhängig vom Anwendungsfall, den eingesetzten Technologien, bestehenden Abhängigkeiten und der zugrundeliegenden Infrastruktur geplant, implementiert und über den Lebenszyklus einer Software geprüft und erhalten werden muss. Das ist nur möglich, wenn Software-Sicherheit sauber definiert und messbar wird und vollwertig neben fachlichen Anforderungen steht.
Hinweis: Entwickler von Software oder anderen Produkten mit digitalen Elementen stehen in der Pflicht, diese Themen proaktiv zu betrachten und bei Kunden und anderen Stakeholdern zu platzieren.
Was bedeutet Nachweisbarkeit der Software-Sicherheit in der Praxis?
Viele Software-Entwickler arbeiten sicherheitsbewusst, aber implizit: Know-how steckt in Köpfen, Entscheidungen passieren im Chat-Thread und Tests sind über Tools verteilt.
Regulatorisch und gegenüber Kunden zählt jedoch, dass Prozesse reproduzierbar sind und Ergebnisse nachvollziehbar dokumentiert werden.
Typische Lücken sind unklare Verantwortlichkeiten zwischen Produkt, Entwicklung, Betrieb und Support sowie fehlende oder uneinheitliche Dokumentation zu Sicherheitsanforderungen, Risikoakzeptanzen und Freigaben.
Hinzu kommt, dass oft keine konsistente Sicht auf Security-Tests (SAST, DAST, Dependency-Scanning) und deren Findings über Releases hinweg besteht: Was ist notwendig? Wer ist verantwortlich? Wie ist der Umgang mit geänderten Bedrohungslagen?
Fehlen Antworten auf diese Fragen, dann erschwert dies sowohl die interne Qualitätssicherung als auch externe Nachweise gegenüber Kunden und Prüfern.
Aus Beratungsprojekten kennen wir dieses Muster gut: Der Fokus in der Praxis liegt auf funktionalen Features und schnellen Iterationen. Eine Risikobetrachtung bleibt oft auf der Strecke und wird von Kunden in aller Regel auch nicht unmittelbar adressiert. Vielmehr ist es so, dass der Software-Nutzern (zu Recht) erwartet, dass Security-Aspekte zumindest nach dem Stand der Technik im Rahmen der Auftragsentwicklung berücksichtigt werden.
Wie gehen Software-Entwickler mit Open-Source-Abhängigkeiten um?
Open Source ist für KMU in der Software-Entwicklung ein Produktivitätsmotor. Kaum ein Software-Projekt kommt heute noch externe Software-Bibliotheken aus, die Funktionalitäten wiederverwendbar bereitstellen. Gleichzeitig entsteht eine Abhängigkeiten-Landschaft, die ohne Automatisierung kaum beherrschbar ist. Schwachstellen in transitiven Abhängigkeiten, veraltete Container-Basisimages oder unsichere Build-Plugins werden schnell zum operativen Risiko.
Typisches Beispiel: Es fehlt ein aktuelles Inventar der Komponenten und Versionen (SBOM) – damit fehlen notwendige Informationen für Patch-Entscheidungen.
Moderne IDEs und Build-Pipelines bieten technische Möglichkeiten, genutzte Abhängigkeiten in einem Projekt zu identifizieren und zu prüfen, um veraltete Bibliotheken oder mögliche Lücken automatisiert sichtbar zu machen. Aber selbst, wenn dies in Entwicklungsprojekten gegeben ist, fehlt es oft an Verantwortlichkeiten oder Prozessen, wie damit umgegangen wird.
Worst Case: Findings werden ignoriert, weil es zu viele sind oder nicht klar ist, wer dafür Verantwortung trägt.
Tipp: Ownership für Abhängigkeiten im Code, Infrastructure-as-Code und CI/CD-Pipelines sind für jedes Entwicklungsprojekt von entscheidender Bedeutung.
Warum scheitert Patch-Management oft am Organisatorischen?
Der CRA lenkt den Fokus auf den Lebenszyklus: Produkte müssen sicher betrieben und aktualisiert werden können. Technisch sind Update-Mechanismen oft vorhanden – organisatorisch fehlen jedoch belastbare Abläufe für Priorisierung, Rollout-Strategie, Kommunikation und Rückfallpläne.
Gerade wenn Kunden individuelle Releases erwarten, On-Premises-Installationen Updates verlangsamen oder Support-Teams Sicherheitsreleases neben Feature-Anforderungen unterbringen müssen, wird die Herausforderung spürbar.
Hier hilft der Blick über den Tellerrand: Sicherheit ist kein Thema, das allein bei der Software-Entwicklung liegt, sondern muss ganzheitlich betrachtet werden. Nur wenn Projektverantwortliche, das Produktmanagement, DevOps, Vertrieb, Kunden etc. (kurz alle relevanten Parteien im Ökosystem der Software) ein gemeinsames Verständnis für das Thema entwickeln, dann ist eine stringente Organisation sinnvoll möglich.
Welches Tooling brauchen Software-Entwickler – und was ist zu viel?
Software-Entwickler können besonders von Automatisierung profitieren. Gleichzeitig ist die Tool-Auswahl unübersichtlich, und ein Tool-Zoo erzeugt mehr Arbeit als Nutzen.
Der CRA erhöht den Bedarf an konsistenter, auditierbarer Toolchain-Integration: Scans, Policies, Release-Gates, Artefakt-Signierung und nachvollziehbare Build-Provenance. Ohne einheitliches Scanning über alle Artefakte hinweg (Code, Container, IaC) bleiben Sicherheitslücken im Blindspot. Wenn jedes Tool eigene Reports produziert, aber kein gemeinsames Bild entsteht, fehlen am Ende die Release-Gates, auf die Kunden und Prüfer vertrauen.
Tipp: Systeme sind oft historisch gewachsen. Hier hilft nur, ehrlich zu prüfen, welche Tools tatsächlich notwendig sind und wo Redundanzen oder evtl. Lücken bestehen. Automatisierung darf der Transparenz nicht im Wege stehen, sondern soll den Blick schärfen. Eine allgemeine One-Size-fits-All-Lösung ist unrealistisch, ein technisches Setup muss immer im Kontext der Anforderungen des Projektes gesehen werden.
Pragmatischer Fahrplan für CRA-konforme Software-Entwicklung
Eine realistische Umsetzung der CRA-Vorgaben gelingt, wenn Sie den CRA nicht als Zusatzprojekt behandeln, sondern als Qualitäts- und Risikoprogramm für Ihr Produktportfolio. Bewährt hat sich ein Vorgehen in klaren, messbaren Schritten:
- Scope klären: Welche Produkte und Komponenten fallen in den relevanten Anwendungsbereich? Welche Ausliefermodelle (Cloud, On-Premises, Embedded) gibt es?
- Security-Baseline definieren: Mindestanforderungen an Authentifizierung, Logging, Kryptographie, Secrets-Handling, sichere Defaults und Hardening dokumentieren.
- Vulnerabilitätsmanagement operationalisieren: Schwachstellen-Intake, Triage-Regeln (Schweregrad, Exploitability, Exposure), SLAs und Release-Prozess festlegen.
- Supply-Chain-Transparenz aufbauen: SBOM erzeugen, Abhängigkeiten kontinuierlich überwachen, Policies für neue Dependencies definieren.
- CI/CD absichern und vereinheitlichen: Scans automatisieren, Findings in Tickets überführen, Release-Gates mit Ausnahmenregelung und dokumentierter Build-Provenance etablieren.
Dokumentation, Schulung und Rollen – Security-Champions je Team, klare Ownership für Komponenten und eine Eskalationslinie für kritische Findings – lassen sich am besten schrittweise in bestehende Abläufe integrieren, statt als separates Projekt aufsetzen.
Gerade bei komplexen Unternehmensstrukturen und/oder unterschiedlichen Produktlinien lohnt es sich, mit einer Sparte zu beginnen, um dort schnell Erfahrungen zu sammeln. Anschließend können die optimierten Prozesse auf alle anderen Unternehmensbereiche bzw. Produktlinien ausgerollt werden.
Typische Fehler bei der Anpassung an den CRA
In unserer Beratung sehen wir immer wieder, dass einige Stolpersteine KMU bei der Umstellung auf eine CRA-konforme Software-Entwicklung am meisten Zeit kosten:
- Zu spät starten: Security-Anforderungen erst vor einem Audit oder Kundenfragebogen anzugehen, führt zu hektischen Umbaumaßnahmen.
- Nur Tools kaufen: Ohne Prozesse und Verantwortlichkeiten erzeugen Scanner vor allem Rauschen.
- IT-Team macht das: CRA-Readiness ist eine umfängliche Produktverantwortung, keine reine Aufgabe der IT-Security.
- Ausnahmen ohne Ende: Wenn jede Policy regelmäßig umgangen wird, fehlt am Ende sowohl Sicherheit als auch Nachweisbarkeit.
Fazit: CRA-Readiness ist ein Wettbewerbsvorteil
Der Cyber Resilience Act hat für KMU in der Software-Entwicklung eine hohe Praxisrelevanz, weil er Sicherheitsarbeit in Entwicklung und Produktbetrieb verbindlich macht. Die größte Herausforderung liegt selten in einem einzelnen Security-Tool, sondern in der Kombination aus Prozessen, Rollen, Dokumentation und Lieferkettenkontrolle – und in der Fähigkeit, sicher zu patchen, ohne die Produktentwicklung zu blockieren.
Wenn Sie jetzt strukturiert starten, gewinnen Sie doppelt: Sie reduzieren reale Risiken (und Supportkosten) und können gegenüber Kunden belastbar zeigen, dass Ihr Produkt sicher entwickelt und gepflegt wird. Beginnen Sie mit Scope, Baselines und einem pragmatischen Vulnerabilitätsmanagement – und erweitern Sie dann schrittweise Automatisierung und Nachweisführung entlang Ihrer CI/CD-Pipeline.