Dieses Video, präsentiert von Mark Hermling von AdaCore im August 2026, behandelt die strategische und technische Ausrichtung von Softwareentwicklungsprozessen für eingebettete Systeme auf den europäischen Cyber Resilience Act (CRA). Es analysiert die regulatorischen Anforderungen der Anhänge I und II, erläutert das Konzept „Secure by Design“ und demonstriert die Integration von Static Application Security Testing (SAST) mittels des Werkzeugs CodeSonar. Im Fokus stehen zudem die Schwachstellenklassifizierung (Zero-Day, N-Day, aktiv ausgenutzt), die Definition von Angriffsflächen (Attack Surfaces), die Optimierung von CI/CD-Pipelines für schnelles Entwicklerfeedback sowie die Absicherung der Software-Lieferkette einschließlich Compilern und SBOMs.
Wichtigste Punkte & Zeitstempel
0:00 Cyber Resilience Act (CRA): Einführung in den CRA, dessen erste Stufe im September 2026 in Kraft tritt, mit dem Ziel, Hersteller von Produkten mit digitalen Elementen für die Softwaresicherheit rechtlich haftbar zu machen.
1:12 Anwendungsbereich & Dokumentation: Relevanz für alle in die Europäische Union exportierten eingebetteten Systeme sowie Erwähnung der essenziellen Anhänge Annex I (Cybersicherheitsanforderungen) und Annex II (Vulnerability Handling).
3:07 Secure by Design & SAST: Die Rolle von Static Application Security Testing (SAST) zur Umsetzung von Best Practices, obgleich der CRA den Einsatz von SAST nicht explizit vorschreibt, behördliche Untersuchungen jedoch entsprechende Tests voraussetzen.
5:56 Schwachstellen-Kategorisierung: Unterscheidung zwischen allgemeinen Schwachstellen, effektiv ausnutzbaren Schwachstellen unter Praxisbedingungen und aktiv ausgenutzten Schwachstellen, wobei Letztere eine 24-Stunden-Meldepflicht nach Artikel 14 auslösen.
7:38 Angriffsfläche (Attack Surface): Analyse physischer und netzwerkbasierter Eintrittspunkte (Ethernet, USB, serielle Schnittstellen, Wi-Fi) und deren genaue Definition im Bedrohungsmodell.
9:13 Produktarchitektur & Verantwortung: Aufteilung der Verantwortung über Hardware, Drittanbieter-Komponenten (RTOS wie Zephyr oder FreeRTOS), unternehmenseigene IP und Software Development Kits (SDK).
13:27 CodeSonar Warnklassen: Klassifizierung von statischen Analysewarnungen in fünf Signifikanzbereiche, wobei für den CRA primär Sicherheits- und Zuverlässigkeitswarnungen relevant sind.
15:16 Zero-Day vs. N-Day: Definition von Zero-Day-Schwachstellen (intern durch SAST entdeckt, der Community noch unbekannt) versus N-Day-Schwachstellen (öffentlich bekannte Schwachstellen mit CVE-Nummern in Drittanbieter-Code).
17:14 Prozess-Anti-Pattern: Kritik an langsamen Feedback-Schleifen (Wartezeiten von Wochen oder Monaten bis zum Sicherheitsbericht) und dem „Heuhaufeneffekt“ bei großen Warnungs-Backlogs, die Entwickler demotivieren.
20:38 CI/CD in Embedded Systems: Implementierung von Continuous Integration und Continuous Deployment (ständige Bereitstellungssbereitschaft) mit automatisierten Test- und Analyse-Pipelines mit einer Feedback-Dauer von unter 15 Minuten.
24:42 Automatisierte Schwellenwerte: Nutzung von Schweregrad-Scores (z. B. Blockierung von Pull-Requests bei Warnungen mit einem Score über 55) und optionaler KI-Unterstützung zur automatisierten Code-Korrektur.
26:28 Software-Lieferkette: Absicherung des Compilers und der Build-Umgebung als Teil der Software Supply Chain (Salsa Build Level 3, reproduzierbare Builds) zur Minimierung von Risiken im SDK.
27:28 Pragmatischer Umsetzungsplan: Aufruf zu inkrementellen Verbesserungen, Bestandsaufnahme der Angriffsflächen und Erstellung einer strategischen Roadmap ohne Panik vor dem nahenden CRA-Stichtag.
Glossar
Cyber Resilience Act (CRA): Eine EU-Verordnung zur Erhöhung der Cybersicherheit für Produkte mit digitalen Elementen, die Hersteller zu strengeren Sicherheitsstandards, Dokumentationen und Schwachstellenmanagement verpflichtet.
Statische Analyse (SAST - Static Application Security Testing): Ein automatisiertes Verfahren zur Untersuchung von Quellcode auf Sicherheitslücken, Programmierfehler und Regelverstöße, ohne den Code auszuführen.
SBOM (Software Bill of Materials): Eine strukturierte Inventarliste aller Softwarekomponenten, Bibliotheken, Open-Source-Module und Abhängigkeiten, die in einem Produkt verbaut sind.
Zero-Day-Schwachstelle: Eine neu entdeckte Sicherheitslücke in Software, die den Entwicklern oder der Öffentlichkeit noch unbekannt ist und für die es daher keine Patches gibt.
N-Day-Schwachstelle: Eine bereits öffentlich bekannte Sicherheitslücke, für die seit „N“ Tagen Patches oder offizielle CVE-Einträge existieren.
CVE (Common Vulnerabilities and Exposures): Ein international standardisiertes Verzeichnis und System zur eindeutigen Benennung bekannter Sicherheitslücken in IT-Systemen.
CI/CD (Continuous Integration / Continuous Deployment): Ein Entwicklungsansatz, bei dem Code-Änderungen automatisiert integriert, gebaut, getestet und jederzeit auslieferungsbereit gehalten werden.
RTOS (Real-Time Operating System): Ein Echtzeit-Betriebssystem für eingebettete Systeme, das deterministisches Verhalten und präzise Reaktionszeiten auf externe Ereignisse garantiert.
SDK (Software Development Kit): Eine Sammlung von Entwicklungswerkzeugen, Bibliotheken, Compilern und Dokumentationen, die das Erstellen von Software für bestimmte Plattformen unterstützen.
Salsa (Supply-chain Levels for Software Artifacts): Ein Sicherheitsframework zur Absicherung der Software-Lieferkette und Gewährleistung der Integrität und Nachvollziehbarkeit von Build-Prozessen (hier Stufe 3).
Annex I / Annex II: Rechtliche Anhänge der EU-CRA-Verordnung; Anhang I definiert die grundlegenden Cybersicherheitsanforderungen, Anhang II regelt die Anforderungen an das Schwachstellenmanagement (Vulnerability Handling).