Security-by-Design: Sicherheit von Anfang an
Ein mittelständischer Hersteller von Smart-Home-Geräten steht vor einem typischen Dilemma: Das neue Thermostat soll zur Heizperiode auf den Markt, aber gleichzeitig CRA-konform sein. Die Entwickler haben das Produkt funktional fertiggestellt, nun soll in einer Woche die Sicherheit nachgerüstet werden. Dieser Ansatz ist zum Scheitern verurteilt. Erfolgreiche europäische Hersteller wie tado° (München), Nuki (Graz) oder Bosch Smart Home zeigen, dass es anders geht: Security-by-Design bedeutet, Sicherheit von der ersten Konzeptphase an mitzudenken, nicht nachträglich anzuflicken.
Zur Einordnung: Der Cyber Resilience Act (Verordnung 2024/2847) ist die erste EU-weite Regulierung, die Cybersicherheitsanforderungen für alle Produkte mit digitalen Elementen verbindlich vorschreibt. Er betrifft Hardware und Software gleichermaßen und gilt für alle Hersteller, die in der EU verkaufen wollen. Die Kernanforderungen umfassen sichere Produktentwicklung, transparente Schwachstellenkommunikation und Sicherheitsupdates über den gesamten Produktlebenszyklus. Teil 1 dieser Serie behandelt die rechtlichen Grundlagen im Detail.
Die Erfahrung aus der Softwareentwicklung belegt die Vorteile dieses Ansatzes quantitativ. Eine Studie des National Institute of Standards and Technology (NIST) zeigt: Eine Sicherheitslücke, die in der Designphase entdeckt wird, kostet etwa das Dreißigfache weniger zu beheben als dieselbe Lücke nach dem Release. Bei Embedded-Systemen wie IoT-Geräten vervielfacht sich dieser Faktor, weil Firmware-Updates aufwändiger sind als Software-Patches. Der CRA macht Security-by-Design zur verbindlichen Pflicht und kodifiziert damit eine Praxis, die sich in sicherheitsbewussten Organisationen längst etabliert hat.
Dieser Artikel behandelt die konkreten Anforderungen des CRA an die Produktsicherheit und zeigt, wie die grundlegenden Prinzipien in der Praxis umgesetzt werden. Der Fokus liegt auf Anhang I der Verordnung, der die technischen Anforderungen definiert, sowie auf bewährten Sicherheitsprinzipien wie Defense in Depth, Least Privilege und der Software Bill of Materials (SBOM). Diese Prinzipien bilden das Fundament für das gesamte Operating Model: Sie bestimmen, wie Entwicklungsprozesse gestaltet werden (Teil 3), wie der sichere Betrieb organisiert wird (Teil 4) und welche Nachweise für die Konformitätsbewertung erforderlich sind (Teil 5).
Die Anforderungen in Anhang I des CRA
Anhang I des CRA bildet das technische Herzstück der Verordnung. Er gliedert sich in zwei Teile: Teil 1 beschreibt die Sicherheitsanforderungen an das Produkt selbst, Teil 2 die Anforderungen an den Umgang mit Schwachstellen während des gesamten Produktlebenszyklus. Beide Teile sind verbindlich und müssen ab dem 11. Dezember 2027 von allen Produkten mit digitalen Elementen erfüllt werden, die in der EU in Verkehr gebracht werden.
Angemessenes Cybersicherheitsniveau
Die zentrale Anforderung in Anhang I, Teil 1, Nummer 1 lautet: Produkte müssen so konzipiert, entwickelt und hergestellt werden, dass sie ein angemessenes Cybersicherheitsniveau gewährleisten. Das Wort angemessen ist dabei entscheidend. Der CRA fordert keine absolute Sicherheit, die ohnehin unerreichbar wäre. Stattdessen muss das Sicherheitsniveau den Risiken entsprechen, die mit dem jeweiligen Produkt verbunden sind.
Ein Passwortmanager, der Zugangsdaten zu Bankkonten speichert, hat andere Anforderungen als ein Smart-Pflanzensensor, der Bodenfeuchtigkeit misst. Die Risikobewertung ist der erste Schritt zur Bestimmung der erforderlichen Maßnahmen. Artikel 13 Absatz 2 des CRA verlangt explizit eine Cybersicherheits-Risikobewertung, die dokumentiert und bei wesentlichen Änderungen aktualisiert werden muss. Diese Bewertung berücksichtigt die vorgesehene Verwendung, die Umgebung, in der das Produkt eingesetzt wird, und die potenziellen Auswirkungen von Sicherheitsvorfällen.
Keine bekannten ausnutzbaren Schwachstellen
Anhang I, Teil 1, Nummer 2 fordert: Produkte dürfen bei Inverkehrbringen keine bekannten ausnutzbaren Schwachstellen enthalten. Diese Anforderung klingt selbstverständlich, hat aber weitreichende Konsequenzen für den Entwicklungsprozess. Hersteller müssen vor dem Release systematisch nach Schwachstellen suchen, und zwar im eigenen Code, in verwendeten Drittkomponenten und in Open-Source-Bibliotheken gleichermaßen.
Die Schwachstellenprüfung umfasst mehrere Dimensionen: Statische Code-Analyse identifiziert potenzielle Probleme im Quellcode. Dynamische Tests prüfen das Verhalten zur Laufzeit. Dependency-Checks gleichen verwendete Bibliotheken mit bekannten Schwachstellendatenbanken ab. Ein aktuelles SBOM ist für diese Prüfung unerlässlich. Der Log4Shell-Vorfall Ende 2021 demonstrierte eindrücklich: Viele Unternehmen wussten nicht, ob ihre Produkte die betroffene Bibliothek enthielten. Ein gepflegtes SBOM ermöglicht die Beantwortung dieser Frage in Minuten.
Was bedeutet Secure by Default in der Praxis?
Anhang I, Teil 1, Nummer 3 verlangt eine sichere Standardkonfiguration (Secure by Default). Das Produkt muss so ausgeliefert werden, dass es ohne zusätzliche Konfiguration durch den Nutzer sicher betrieben werden kann. Konkret bedeutet das: keine schwachen oder universellen Standardpasswörter, keine unnötig offenen Netzwerkports, keine überflüssigen Dienste standardmäßig aktiviert.
Das BSI dokumentiert in seinen Sicherheitsanalysen regelmäßig Produkte, die gegen dieses Prinzip verstoßen. Router mit dem Standardpasswort admin:admin, IoT-Kameras mit offenem Telnet-Zugang, Smart-Home-Gateways ohne aktivierte Verschlüsselung. Solche Produkte werden unter dem CRA nicht mehr verkehrsfähig sein. Der Nutzer soll sich darauf verlassen können, dass das Produkt im Auslieferungszustand sicher ist. Optionale Sicherheitsfunktionen wie automatische Updates sollten standardmäßig aktiviert sein, nicht erst nach bewusster Entscheidung des Nutzers.
Schutz vor unbefugtem Zugriff
Anhang I fordert angemessene Mechanismen zur Zugangs- und Zugriffskontrolle. Das umfasst Authentifizierung (Wer greift zu?) und Autorisierung (Was darf der Zugreifende tun?). Standardpasswörter müssen entweder gerätespezifisch sein oder bei der Ersteinrichtung vom Nutzer geändert werden. Administrative Schnittstellen benötigen besonders starke Authentifizierung. Mehrfaktor-Authentifizierung muss unterstützt werden, wo dies angemessen ist.
Die Anforderungen gehen über reine Authentifizierung hinaus. Produkte müssen unbefugte Zugriffsversuche erkennen und melden können. Brute-Force-Angriffe auf Passwörter müssen durch Rate-Limiting oder Account-Sperrung erschwert werden. Nach einer definierten Anzahl fehlgeschlagener Anmeldeversuche soll das System reagieren, sei es durch zunehmende Verzögerungen, temporäre Sperrung oder Benachrichtigung des Nutzers.
Defense in Depth: Gestaffelte Verteidigung
Defense in Depth ist ein fundamentales Sicherheitsprinzip, das der CRA implizit in mehreren Anforderungen fordert. Der Ansatz basiert auf einer militärischen Analogie: Statt alle Verteidigungsressourcen auf eine einzige Linie zu konzentrieren, werden mehrere Verteidigungsebenen hintereinander gestaffelt. Wenn eine Ebene durchbrochen wird, greifen die dahinterliegenden.
Übertragen auf die Produktsicherheit bedeutet das: Keine einzelne Sicherheitsmaßnahme ist perfekt. Firewalls können umgangen werden, Passwörter können kompromittiert werden, Verschlüsselung kann gebrochen werden. Ein Produkt, das sich auf nur eine Sicherheitsebene verlässt, ist verwundbar, sobald diese Ebene versagt. Ein Produkt mit gestaffelter Verteidigung bleibt auch dann geschützt, wenn einzelne Maßnahmen versagen.
Schichten der Verteidigung
Die typischen Schichten einer Defense-in-Depth-Architektur umfassen: Netzwerksegmentierung verhindert, dass ein kompromittiertes System direkten Zugriff auf andere Systeme erhält. Ein Smart-Home-Gateway sollte Geräte in separate Netzwerksegmente isolieren können. Eingabevalidierung fängt bösartige Daten ab, bevor sie verarbeitet werden. Jede Schnittstelle, die Daten von außen entgegennimmt, muss diese validieren, unabhängig davon, ob die Daten aus einer vermeintlich vertrauenswürdigen Quelle stammen.
Verschlüsselung schützt Daten auch bei erfolgreicher Extraktion. Ein Angreifer, der eine Datenbank kopiert, kann mit verschlüsselten Daten wenig anfangen, wenn er den Schlüssel nicht besitzt. Zugangskontrolle beschränkt, wer auf welche Ressourcen zugreifen kann. Logging und Monitoring ermöglichen die Erkennung von Anomalien und Angriffen. Jede dieser Schichten erhöht den Aufwand für einen erfolgreichen Angriff und reduziert die Wahrscheinlichkeit, dass ein einzelner Fehler zur vollständigen Kompromittierung führt.
Praktisches Beispiel: Smart-Home-Thermostat
Wie marktführende Produkte von tado° oder Bosch zeigen, implementiert ein gut konzipiertes Smart-Home-Thermostat Defense in Depth auf mehreren Ebenen. Die Kommunikation mit der Cloud erfolgt über TLS mit Certificate Pinning. Selbst wenn ein Angreifer den Netzwerkverkehr abfangen kann, sieht er nur verschlüsselte Daten. Die lokale Speicherung von Zugangsdaten erfolgt verschlüsselt, nicht im Klartext. Selbst physischer Zugriff auf das Gerät gibt dem Angreifer nicht automatisch die Cloud-Zugangsdaten.
Die Firmware akzeptiert nur signierte Updates. Selbst wenn ein Angreifer das Update-System kompromittiert, kann er keine manipulierte Firmware aufspielen. Die API validiert alle Eingaben strikt. Ein Angreifer kann keine Buffer-Overflow-Angriffe über manipulierte Temperaturdaten durchführen. Das Gerät protokolliert sicherheitsrelevante Ereignisse und meldet Anomalien. Wiederholte fehlgeschlagene Authentifizierungsversuche lösen Warnungen aus.
Least Privilege und Zugangskontrolle
Das Prinzip der minimalen Rechte (Least Privilege) ist eine der ältesten und bewährtesten Sicherheitsregeln. Es besagt: Jede Komponente, jeder Prozess und jeder Nutzer sollte nur die Berechtigungen haben, die für seine spezifische Aufgabe unbedingt erforderlich sind, nicht mehr. Der CRA fordert dies explizit in Anhang I: Produkte müssen angemessene Zugangs- und Zugriffskontrollmechanismen implementieren.
Die Begründung ist einleuchtend: Je mehr Rechte eine Komponente hat, desto größer der potenzielle Schaden bei einer Kompromittierung. Ein Webserver-Prozess, der mit Root-Rechten läuft, gibt einem Angreifer bei erfolgreicher Exploitation vollständige Kontrolle über das System. Derselbe Webserver-Prozess mit eingeschränkten Rechten begrenzt den Schaden auf das, was diese eingeschränkten Rechte erlauben.
Authentifizierung: Identität verifizieren
Authentifizierung beantwortet die Frage: Wer greift auf das System zu? Der CRA fordert geeignete Authentifizierungsmechanismen, die dem Risikoprofil des Produkts entsprechen. Für ein Consumer-IoT-Gerät kann ein sicheres Passwort ausreichen. Für ein industrielles Steuerungssystem ist Mehrfaktor-Authentifizierung angemessen.
Die Anforderungen an Passwörter sind klar: Standardpasswörter müssen entweder gerätespezifisch sein (jedes Gerät hat ein individuelles Passwort, typischerweise auf einem Aufkleber am Gerät) oder der Nutzer muss bei der Ersteinrichtung ein eigenes Passwort setzen. Universelle Standardpasswörter wie admin oder 123456 sind nicht CRA-konform. Zusätzlich muss das Produkt Schutz vor Brute-Force-Angriffen bieten, etwa durch Rate-Limiting oder progressive Verzögerungen.
Autorisierung: Berechtigungen kontrollieren
Autorisierung beantwortet die Frage: Was darf der authentifizierte Nutzer tun? Nicht jeder Nutzer benötigt alle Funktionen. Administrative Funktionen wie Firmware-Updates oder Netzwerkkonfiguration sollten von regulären Nutzerfunktionen getrennt sein. Rollenbasierte Zugangskontrolle (RBAC) ist ein bewährtes Muster: Nutzer werden Rollen zugewiesen, Rollen haben definierte Berechtigungen.
Bei Produkten mit mehreren Nutzern muss die Datentrennung gewährleistet sein. Ein Smart-Home-System, das von mehreren Familienmitgliedern genutzt wird, sollte verhindern, dass ein Nutzer die persönlichen Einstellungen eines anderen ändert. Ein Cloud-basiertes System muss sicherstellen, dass Mandant A keinen Zugriff auf Daten von Mandant B erhält, selbst wenn beide auf derselben Infrastruktur laufen.
Minimierung der Angriffsfläche
Die Angriffsfläche (Attack Surface) eines Produkts umfasst alle Punkte, an denen ein Angreifer potenziell ansetzen kann: offene Netzwerkports, exponierte APIs, Eingabefelder, verarbeitete Dateiformate, physische Schnittstellen. Je größer die Angriffsfläche, desto mehr potenzielle Einstiegspunkte für Angreifer. Der CRA fordert deren Minimierung als Teil des angemessenen Cybersicherheitsniveaus.
Reduktion auf das Wesentliche
Der erste Schritt ist die Entfernung unnötiger Funktionen. Jede Funktion, die nicht für den Betrieb erforderlich ist, vergrößert die Angriffsfläche ohne Nutzen. Debug-Schnittstellen, die während der Entwicklung hilfreich waren, haben in Produktionsversionen nichts zu suchen. Legacy-APIs, die aus Kompatibilitätsgründen beibehalten wurden, aber nicht mehr gebraucht werden, sollten entfernt werden. Jeder offene Port, jeder aktive Dienst, jede exponierte Schnittstelle ist ein potenzieller Angriffsvektor.
Das Mirai-Botnet von 2016 illustriert die Konsequenzen unnötiger Angriffsfläche drastisch. Millionen von IoT-Geräten wurden kompromittiert, weil sie Telnet-Dienste mit Standardpasswörtern exponiert hatten. Telnet war für die Funktion der Geräte nicht erforderlich, öffnete aber ein Einfallstor für Angreifer. Ein DDoS-Angriff mit diesen Geräten legte zeitweise große Teile des Internets lahm. Unter dem CRA wären solche Geräte nicht verkehrsfähig.
Eingabevalidierung
Alle Eingaben von außen müssen als potenziell bösartig behandelt werden. Das umfasst Nutzereingaben über Weboberflächen, Daten aus importierten Dateien, Netzwerkverkehr von anderen Systemen und API-Aufrufe. Das Zero-Trust-Prinzip gilt hier: Vertraue keiner Eingabe, auch wenn sie aus einer vermeintlich vertrauenswürdigen Quelle stammt.
Strenge Validierung nach dem Whitelist-Prinzip ist Blacklist-Ansätzen vorzuziehen. Statt zu definieren, welche Eingaben verboten sind (und zu hoffen, alle gefährlichen Fälle abzudecken), definiert der Whitelist-Ansatz, welche Eingaben erlaubt sind. Alles andere wird abgelehnt. Eingaben werden auf erwartete Formate, Längen und Zeichensätze geprüft. Unerwartete Eingaben werden nicht bereinigt oder interpretiert, sondern konsequent abgewiesen.
Sichere Kommunikation
Der CRA fordert in Anhang I den Schutz vor unbefugtem Zugriff auf Daten während der Übertragung. In der Praxis bedeutet das: TLS für alle Netzwerkverbindungen, aktuelle Verschlüsselungsstandards (TLS 1.2 oder höher), Validierung von Server-Zertifikaten. Unverschlüsselte Kommunikation sollte nur in begründeten Ausnahmefällen möglich sein und erfordert dann eine explizite, informierte Nutzerentscheidung.
Certificate Pinning erhöht die Sicherheit zusätzlich. Dabei akzeptiert das Gerät nur bestimmte, vorab bekannte Zertifikate oder Zertifizierungsstellen. Ein Angreifer, der sich zwischen Gerät und Server schaltet (Man-in-the-Middle), kann die Verbindung nicht mit einem eigenen Zertifikat abfangen, selbst wenn dieses von einer allgemein vertrauenswürdigen Zertifizierungsstelle ausgestellt wurde.
Software Bill of Materials (SBOM)
Der CRA verpflichtet Hersteller in Artikel 13 Absatz 1 Buchstabe h in Verbindung mit Anhang I Teil II Nummer 1 zur Erstellung und Pflege einer Software Bill of Materials (SBOM). Die SBOM ist eine vollständige, maschinenlesbare Liste aller Softwarekomponenten eines Produkts: eigener Code, Open-Source-Bibliotheken, Drittanbieter-Komponenten, Frameworks. Sie bildet die Grundlage für effektives Schwachstellenmanagement und ist eines der wichtigsten Instrumente zur Umsetzung der CRA-Anforderungen.
Welche Anforderungen stellt der CRA an die SBOM?
Die SBOM muss in einem maschinenlesbaren Standardformat vorliegen. Die beiden etablierten Formate sind SPDX (Software Package Data Exchange, ein ISO/IEC-Standard der Linux Foundation) und CycloneDX (ein OWASP-Standard mit Fokus auf Security). Das BSI empfiehlt in TR-03183-2 weitere Spezifikationen zur SBOM-Struktur. Die EU-Kommission kann im Rahmen von Durchführungsverordnungen weitere Formatanforderungen festlegen.
Der CRA fordert, dass die SBOM mindestens die Top-Level-Abhängigkeiten enthält. In der Praxis ist eine tiefere Erfassung sinnvoll, da Schwachstellen oft in transitiven Abhängigkeiten stecken. Eine Bibliothek A, die der Hersteller direkt verwendet, nutzt ihrerseits Bibliothek B, die Bibliothek C verwendet. Eine Schwachstelle in C betrifft auch das Produkt, selbst wenn der Hersteller C nie direkt eingebunden hat.
Der Log4Shell-Fall
Der Log4Shell-Vorfall im Dezember 2021 demonstrierte den Wert einer gepflegten SBOM eindrücklich. Eine kritische Schwachstelle in der Java-Bibliothek Log4j betraf Millionen von Systemen weltweit. Unternehmen mit aktueller SBOM konnten innerhalb von Stunden prüfen, welche ihrer Produkte betroffen waren. Unternehmen ohne SBOM brauchten Tage oder Wochen für dieselbe Analyse, während ihre Produkte ungeschützt blieben.
Die SBOM ermöglichte die schnelle Identifikation betroffener Produkte und die gezielte Priorisierung der Reaktion. Produkte mit exponierten Log4j-Instanzen erforderten sofortige Maßnahmen. Produkte, die Log4j nur in nicht erreichbaren Komponenten verwendeten, konnten mit geringerer Priorität behandelt werden. Diese differenzierte Triage wäre ohne SBOM nicht möglich gewesen.
Integration in den Entwicklungsprozess
Die SBOM sollte automatisch als Teil des Build-Prozesses generiert werden. Manuelle Pflege ist fehleranfällig und nicht skalierbar. Tools wie Syft, Trivy, OWASP Dependency-Track oder kommerzielle Lösungen können die SBOM-Generierung in CI/CD-Pipelines integrieren. Bei jedem Build wird eine aktuelle SBOM erstellt. Bei Releases wird diese archiviert und versioniert.
Die SBOM ist nicht nur ein Compliance-Dokument, sondern ein aktives Sicherheitswerkzeug. Automatisierte Scans gleichen die SBOM regelmäßig mit Schwachstellendatenbanken ab: der National Vulnerability Database (NVD), dem GitHub Advisory Database und seit Mai 2025 der European Vulnerability Database (EUVD) von ENISA. Die EUVD bietet speziell auf den EU-Markt zugeschnittene Schwachstelleninformationen und unterstützt die CRA-Konformität. Neue Schwachstellen in verwendeten Komponenten werden automatisch erkannt und gemeldet. Der Hersteller kann proaktiv reagieren, statt auf Meldungen von außen zu warten.
Datenschutz und Datenintegrität
Der CRA fordert in Anhang I den Schutz der Vertraulichkeit und Integrität von Daten. Diese Anforderung betrifft Daten in drei Zuständen: im Ruhezustand (at rest), während der Verarbeitung (in use) und während der Übertragung (in transit). Die CRA-Anforderungen ergänzen die DSGVO, fokussieren aber auf technische Maßnahmen statt auf organisatorische Datenschutzprozesse.
Verschlüsselung nach Stand der Technik
Sensible Daten müssen verschlüsselt gespeichert werden. Die Verordnung fordert dem Stand der Technik entsprechende Verschlüsselung. Das bedeutet konkret: aktuelle Algorithmen wie AES-256 für symmetrische Verschlüsselung, RSA mit mindestens 2048 Bit (für langlebige Systeme empfiehlt NIST bereits RSA 3072 oder Elliptic Curve Cryptography) für asymmetrische Verschlüsselung. Veraltete oder gebrochene Algorithmen wie DES, RC4 oder MD5 erfüllen die Anforderungen nicht.
Ordnungsgemäßes Schlüsselmanagement ist ebenso wichtig wie die Wahl des Algorithmus. Schlüssel dürfen nicht im Klartext im Code stehen. Sie müssen sicher erzeugt (ausreichende Entropie), sicher gespeichert (Hardware Security Modules oder sichere Enklaven wo angemessen) und regelmäßig rotiert werden. Der Verlust eines Schlüssels muss handhabbar sein, ohne die Verfügbarkeit des Systems zu gefährden.
Datenminimierung
Produkte sollten nur Daten erheben und speichern, die für die Funktion erforderlich sind. Übermäßige Datensammlung vergrößert die Angriffsfläche und das Schadenspotenzial bei einem Breach. Ein Smart-Home-Thermostat benötigt Temperaturdaten und Heizpläne. Es benötigt nicht die Bewegungsprofile der Bewohner, die Namen ihrer WLAN-Geräte oder die Inhalte ihrer Kalender.
Diese Anforderung korrespondiert mit dem Datenminimierungsprinzip der DSGVO (Artikel 5 Absatz 1 Buchstabe c). Der CRA ergänzt die rechtliche Anforderung um eine technische Dimension: Das Produkt soll technisch so gestaltet sein, dass übermäßige Datensammlung gar nicht erst möglich ist. Privacy by Design und Security by Design gehen Hand in Hand.
Herausforderungen bei der Umsetzung
Die Security-by-Design-Anforderungen des CRA sind fachlich unstrittig. Die praktische Umsetzung stellt viele Unternehmen jedoch vor erhebliche Herausforderungen. Diese Herausforderungen sollten nicht verschwiegen werden, denn sie zu adressieren ist Teil einer realistischen CRA-Vorbereitung.
Bestandsprodukte und Legacy-Systeme
Security-by-Design lässt sich bei Neuentwicklungen vergleichsweise gut umsetzen. Die Herausforderung liegt bei Bestandsprodukten. Ein Produkt, das seit Jahren auf dem Markt ist und dessen Architektur Sicherheit nicht von Anfang an berücksichtigt hat, lässt sich nicht durch nachträgliche Patches CRA-konform machen. In manchen Fällen ist eine grundlegende Neuarchitektur erforderlich, in anderen ist das Auslaufen des Produkts wirtschaftlich sinnvoller.
Die Übergangsfristen des CRA berücksichtigen diese Realität nur teilweise. Produkte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden, müssen die Anforderungen nicht sofort erfüllen. Aber sie müssen sie erfüllen, sobald sie wesentlich geändert werden. Und die Schwachstellenmanagement-Anforderungen gelten ab dem 11. September 2026 für alle Produkte, auch für Bestandsprodukte.
Woher kommt das Security-Know-how?
Security-by-Design erfordert spezifische Expertise, die nicht in jedem Entwicklungsteam vorhanden ist. Threat Modeling, sichere Code-Praktiken, Penetrationstests, SBOM-Management: Diese Fähigkeiten müssen aufgebaut oder eingekauft werden. Für KMU, die bisher ohne dedizierte Security-Ressourcen entwickelt haben, bedeutet das einen erheblichen Aufwand.
Die EU-Kommission hat dieses Problem erkannt. Der CRA sieht Unterstützungsmaßnahmen für KMU vor, und ENISA veröffentlicht Leitfäden und Best Practices. Im April 2025 haben CEN, CENELEC und ETSI den Standardisierungsauftrag M/606 offiziell angenommen und arbeiten an harmonisierten Standards, die bis Oktober 2026 vorliegen sollen. Diese Standards werden konkrete Umsetzungsvorgaben bieten und eine Konformitätsvermutung begründen. Dennoch bleibt die Umsetzung anspruchsvoll, insbesondere für Unternehmen mit begrenzten Ressourcen.
Wie sichert man die Lieferkette ab?
Kaum ein Produkt besteht ausschließlich aus eigenem Code. Open-Source-Bibliotheken, Drittanbieter-SDKs, eingekaufte Komponenten sind die Regel. Der Hersteller ist für die Sicherheit des Gesamtprodukts verantwortlich, hat aber nur begrenzte Kontrolle über die Sicherheit der Zulieferer. Die Beschaffung von SBOMs von Zulieferern, die Validierung ihrer Sicherheitsaussagen, die Reaktion auf Schwachstellen in Drittkomponenten: All das erfordert neue Prozesse und vertragliche Regelungen.
Security-by-Design im internationalen Vergleich
Der CRA steht nicht isoliert. Auch die USA haben Security-by-Design zur strategischen Priorität erklärt. Executive Order 14028 vom Mai 2021 verpflichtete Bundesbehörden zur Beschaffung sicherer Software und führte SBOM-Anforderungen für Regierungsaufträge ein. CISA (Cybersecurity and Infrastructure Security Agency) veröffentlichte im April 2023 das Dokument Shifting the Balance of Cybersecurity Risk, das Hersteller auffordert, Sicherheitsverantwortung zu übernehmen statt sie auf Kunden abzuwälzen. Der CISA Secure by Design Pledge von 2024 hat bereits über 200 Unterzeichner, darunter Microsoft, Google und Siemens.
Die Parallelen zwischen CRA und US-Ansätzen sind offensichtlich: Beide fordern Secure-by-Default-Konfigurationen, SBOM-Transparenz und proaktives Schwachstellenmanagement. Der wesentliche Unterschied liegt in der Verbindlichkeit. Der CRA ist eine Verordnung mit Bußgeldern bis 15 Millionen Euro, die US-Initiativen sind bisher freiwillig (außer für Bundesaufträge). Für Hersteller, die global agieren, bedeutet das: Eine CRA-konforme Produktentwicklung erfüllt automatisch auch die CISA-Empfehlungen. Die Investition in Security-by-Design zahlt sich auf beiden Märkten aus.
Fazit und Ausblick
Security-by-Design ist kein Hindernis für schnelle Produktentwicklung, sondern eine Investition in nachhaltige Produktqualität. Die Kosten für frühe Sicherheitsmaßnahmen sind erheblich geringer als die Kosten für nachträgliche Korrekturen, Rückrufaktionen oder Reputationsschäden nach Sicherheitsvorfällen. Die Prinzipien des CRA sind keine Revolution: Defense in Depth, Least Privilege, Minimierung der Angriffsfläche, sichere Defaults. Sie kodifizieren bewährte Praktiken, die in sicherheitsbewussten Organisationen längst Standard sind.
Die SBOM entwickelt sich zum zentralen Instrument der Produktsicherheit. Sie ist mehr als ein Compliance-Dokument: Sie ist ein aktives Werkzeug für Schwachstellenmanagement, Incident Response und Supply-Chain-Security. Ich halte die SBOM-Pflicht des CRA für eine der wirksamsten Maßnahmen der Verordnung. Die Erfahrungen aus Log4Shell zeigen, wie wertvoll eine aktuelle Komponentenliste im Ernstfall ist.
Die Herausforderungen bei der Umsetzung sind real. Bestandsprodukte lassen sich nicht über Nacht umbauen, Expertise muss aufgebaut werden, Lieferketten müssen neu organisiert werden. Aber diese Herausforderungen sind lösbar. Wer heute mit der Vorbereitung beginnt, hat noch ausreichend Zeit bis zur vollen Anwendbarkeit im Dezember 2027.
Wer Security-by-Design systematisch umsetzt, sollte drei Prioritäten setzen: Erstens die Etablierung eines SBOM-Prozesses, der automatisch in den Build integriert ist. Zweitens die Durchführung einer Risikobewertung für alle Produkte, um den angemessenen Schutzbedarf zu bestimmen. Drittens die Schulung der Entwicklungsteams in sicheren Entwicklungspraktiken. Im nächsten Teil betrachten wir, wie diese Prinzipien konkret in Entwicklungsprozesse integriert werden: Secure Development Lifecycle, Threat Modeling und CI/CD-Integration.
Quellenverzeichnis
[1] Europäische Union: Verordnung (EU) 2024/2847 des Europäischen Parlaments und des Rates vom 23. Oktober 2024 über horizontale Cybersicherheitsanforderungen für Produkte mit digitalen Elementen (Cyber Resilience Act). Amtsblatt der Europäischen Union L 2024/2847.
[2] National Institute of Standards and Technology (NIST): The Economic Impacts of Inadequate Infrastructure for Software Testing. NIST Planning Report 02-3, 2002. Dokumentiert die Kostensteigerung bei später Fehlerbehebung.
[3] Bundesamt für Sicherheit in der Informationstechnik (BSI): TR-03183-2 Cyber-Resilienz-Anforderungen an Hersteller und Produkte, Teil 2: Software Bill of Materials (SBOM). Version 2.1.0 (2025). Enthält SPDX/CycloneDX-Mapping-Empfehlungen.
[4] ENISA: Guidelines on Cybersecurity of IoT. European Union Agency for Cybersecurity, Good Practices for Security of IoT, 2020. Grundlage für viele CRA-Anforderungen.
[5] OWASP Foundation: CycloneDX SBOM Standard (ECMA-424). Internationaler Standard für Software Bill of Materials. Version 1.7 (Oktober 2025). https://cyclonedx.org/
[6] Linux Foundation: SPDX (Software Package Data Exchange). ISO/IEC 5962:2021 International Standard. https://spdx.dev/
[7] Cloudflare: Inside the Log4j2 Vulnerability (CVE-2021-44228). Dezember 2021. Fallstudie zur Bedeutung von SBOMs bei kritischen Schwachstellen.
[8] Imperva: Mirai Botnet Attack Analysis. 2016/2017. Dokumentation der Konsequenzen unnötiger Angriffsfläche bei IoT-Geräten.
[9] ENISA: European Vulnerability Database (EUVD). Gestartet Mai 2025. Zentrale EU-Schwachstellendatenbank zur Unterstützung von NIS2 und CRA. https://euvd.enisa.europa.eu/
[10] CEN-CENELEC: Standardization Request M/606 for the Cyber Resilience Act. Offiziell angenommen April 2025. Entwicklung harmonisierter Standards für CRA-Konformität.
[11] CISA: Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Secure by Design Software. April 2023. Sowie CISA Secure by Design Pledge, 2024. https://www.cisa.gov/securebydesign