Einhaltung des Cyber ​​Resilience Act: Was Softwareteams wissen müssen

Der Cyber ​​Resilience Act verlagert die Sicherheit von einem abschließenden Release-Schritt zu einer kontinuierlichen Entwicklungsanforderung – mit einer 24-Stunden-Meldepflicht für Sicherheitslücken ab September 2026. Hier erfahren Sie, was Software- und Embedded-Teams jetzt tun müssen.

Was ist der Cyber ​​Resilience Act?

Der Cyber ​​Resilience Act ist eine Verordnung der Europäischen Union, die darauf abzielt, die Cybersicherheit von Produkten mit digitalen Elementen zu verbessern.

Die Cybersecurity Regulation Authority (CRA) gilt für Softwareprodukte, vernetzte Geräte, eingebettete Systeme, Industrieanlagen, Automobilplattformen, IoT-Geräte und softwarefähige Hardware, die auf dem EU-Markt in Verkehr gebracht werden. Die Verordnung legt verbindliche Cybersicherheitsanforderungen für den gesamten Produktlebenszyklus fest, einschließlich Entwicklung, Umgang mit Sicherheitslücken, Meldung von Vorfällen, Sicherheitsupdates und Konformitätsbewertung.

Wer muss das Cyber ​​Resilience Act einhalten?

Die Verpflichtungen der CRA erstrecken sich nicht nur auf traditionelle Softwareanbieter. Hersteller, Importeure, Distributoren und Unternehmen außerhalb der EU, die betroffene Produkte auf dem europäischen Markt vertreiben, können gleichermaßen betroffen sein. Organisationen, die eingebettete Systeme, Steuergeräte für die Automobilindustrie, industrielle Steuerungen, Luft- und Raumfahrtsysteme, Medizinprodukte, Netzwerkgeräte und IoT-Produkte für Endverbraucher entwickeln, sollten ihr Risiko bereits jetzt prüfen.

CRA ist nicht einfach nur eine weitere Cybersicherheitsverordnung. Sie verändert grundlegend, wie Teams Software und eingebettete Systeme entwerfen, entwickeln, testen, dokumentieren, veröffentlichen und warten. Für Unternehmen, die Produkte mit digitalen Elementen entwickeln, führt die Einhaltung von CRA zu rechtlich verbindlichen Anforderungen an die Entwicklung von Produkten mit Sicherheitsarchitektur, das Schwachstellenmanagement, die Meldebereitschaft und die Verantwortlichkeit über den gesamten Lebenszyklus.

Durch die Umsetzung regulatorischer Anforderungen in konkrete technische Maßnahmen weiß Ihr Team, was zu tun ist und wie es zu tun ist.

Wichtige Fristen des Cyber ​​Resilience Act und warum Softwareteams jetzt handeln sollten

Der CRA trat offiziell am 10. Dezember 2024 in Kraft. Die obligatorische Meldepflicht für Sicherheitslücken beginnt am 11. September 2026, während die weitergehenden Compliance-Verpflichtungen am 11. Dezember 2027 durchsetzbar werden.

Diese Termine mögen noch weit entfernt erscheinen, doch Unternehmen können nicht bis zum endgültigen Stichtag mit den Vorbereitungen warten. Entwicklungsteams benötigen Zeit, um wiederholbare Arbeitsabläufe zu etablieren, die Nachweisgenerierung zu automatisieren, Sicherheit in CI/CD-Pipelines zu integrieren, Berichtsprozesse zu formalisieren und Entwicklungspraktiken an den Prinzipien von „Secure by Design“ auszurichten.

Ein Warten bis 2027 ist keine Option. Entwicklungsteams benötigen Zeit, um wiederholbare Arbeitsabläufe zu etablieren, die Nachweisgenerierung zu automatisieren, Sicherheit in CI/CD-Pipelines zu integrieren, Berichtsprozesse zu formalisieren und die Entwicklung an den Prinzipien von „Secure by Design“ auszurichten. Die Frist für die Berichtsbereitschaft beginnt im September 2026.

Was sind die wichtigsten Anforderungen des Cyber ​​Resilience Act?

Der CRA führt weitreichende Cybersicherheitsverpflichtungen ein, die sich auf die Entwicklung und Wartung von Produkten auswirken. Zu den Kernanforderungen gehören:

• Entwicklung von sicheren Systemen durch Design und sichere Standardeinstellungen
• Cybersicherheitsrisikobewertungen
• Umgang mit Schwachstellen und koordinierte Offenlegung
• Meldepflicht für Vorfälle und Sicherheitslücken
• Sicherheitsupdates und Lebenszykluswartung
• Technische Dokumentation und Konformitätsnachweis
• SBOM-Transparenz und Lieferkettenbewusstsein
• Konformitätsbewertungen und CE-Kennzeichnung

Wie sich die Produktklassifizierung auf die CRA-Konformitätsanforderungen auswirkt

Die CRA kategorisiert Produkte je nach Risiko und Auswirkungen als Standard, Wichtig oder Kritisch.

Produkte, die unter Anhang III und Anhang IV aufgeführt sind, unterliegen strengeren Prüfungen und können unabhängige Konformitätsbewertungen durch Dritte erfordern. Die Klassifizierung sollte nicht als nachträgliche Prüfung betrachtet werden. Sie ist eine strategische technische Entscheidung, die sich unmittelbar auf den Umfang der Prüfungen, die Dokumentationsanforderungen, die Validierungsaktivitäten und die Kosten für die Einhaltung der Vorschriften auswirkt.

Handlungsschritt »

Ermitteln Sie, in welche Kategorie Ihr Produkt fällt. Ist es nicht in Anhang III oder IV aufgeführt, gilt es als Standardprodukt. Könnte eine Kompromisslösung jedoch die öffentliche Sicherheit oder lebenswichtige Dienstleistungen gefährden, können die Aufsichtsbehörden es unabhängig von der Liste als kritisch einstufen.

Checkliste zur Einhaltung der CRA-Vorschriften für Softwareteams

Die Vorbereitung auf die Einhaltung der CRA-Vorschriften erfordert mehr als die Durchsicht regulatorischer Texte oder die Erstellung von Dokumentationen kurz vor einem Audit. Entwicklungsunternehmen benötigen wiederholbare Prozesse für Entwicklung, Tests, Schwachstellenmanagement und Berichterstattung, die die Cybersicherheitsbereitschaft über den gesamten Produktlebenszyklus hinweg kontinuierlich nachweisen können.

Für viele Software- und Embedded-Teams liegt die Herausforderung nicht im Fehlen von Sicherheitsmaßnahmen, sondern im Mangel an Konsistenz, Nachvollziehbarkeit und operativer Integration im gesamten Softwareentwicklungszyklus (SDLC). Die Bereitschaft zur CRA-Prüfung hängt davon ab, voneinander getrennte Sicherheitsaufgaben in messbare und auditierbare Entwicklungsabläufe zu überführen.

Ein praktischer Ausgangspunkt sind beispielsweise folgende Aktivitäten.

1. Produkte identifizieren, die in den Anwendungsbereich der CRA fallen.

• Erstellen Sie ein Verzeichnis aller für die EU bestimmten Produkte mit digitalen Elementen.
• Dazu gehören eingebettete Firmware, mobile Apps, Cloud-Backends und jegliche Software, die mit der Hardware ausgeliefert wird.

2. Durchführung und Pflege von Cybersicherheitsrisikobewertungen.

• Dies ist kein Dokument, das nur einmalig verwendet werden muss. Aktualisieren Sie es immer dann, wenn sich das Produkt ändert oder neue Bedrohungen auftreten.
• Die Risikobewertung bestimmt Ihre Sicherheitsmaßnahmen, Tests und Dokumentation.

3. CRA-Anforderungen den SDLC-Kontrollen und -Workflows zuordnen.

• Ordnen Sie jeden Artikel (z. B. 13, 14, 31) und jede Anforderung aus Anhang I spezifischen technischen Aktivitäten zu: Bedrohungsmodellierung, statische Analyse, Komponententests usw.

4. Implementieren Sie sichere Codierungsstandards wie OWASP, CWE, CERT oder MISRA.

• Nutzen Sie OWASP Top 10, OWASP Proactive Controls, CWE Top 25, CERT oder MISRA.
• Warum? Die CRA schreibt keine spezifischen Frameworks vor, aber diese bilden die gemeinsame Sprache der Anwendungssicherheit. Prüfer verstehen sie bereits, und sie lassen sich direkt den von der CRA genannten Schwachstellenklassen zuordnen.

5. SBOMs erstellen und pflegen, um Transparenz in der Software-Lieferkette zu gewährleisten.

• Verwenden Sie Formate wie SPDX oder CycloneDX. Generieren Sie SBOMs automatisch mit Tools wie cdxgen, Syft oder Ihrem Build-System.

6. Verfahren zur Offenlegung und Meldung von Sicherheitslücken formalisieren.

• Benennen Sie einen zentralen Ansprechpartner für die Entgegennahme von Schwachstellenmeldungen.
• Veröffentlichen Sie eine Richtlinie zur Offenlegung von Sicherheitslücken.
• Bereiten Sie sich auf die 24-Stunden-Meldepflicht vor (Artikel 14):
  • Innerhalb von 24 Stunden nach Bekanntwerden einer aktiv ausgenutzten Sicherheitslücke: erste Benachrichtigung an ENISA/CSIRT.
  • Innerhalb von 72 Stunden: technische Details und Maßnahmen zur Risikominderung.
  • Innerhalb von 14 Tagen: vollständige Analyse, Ursachenermittlung und Nachweis der Behebung.
• Entwickeln Sie vorausgefüllte Berichtsvorlagen. Führen Sie Planspiele durch. Trainieren Sie das Muskelgedächtnis vor einem Vorfall.

7. Integrieren Sie automatisierte Tests in CI/CD-Pipelines.

• Statische Analyse (SAST) in IDE und Pre-Commit: Kennzeichnung von OWASP Top 10, CWE Top 25, Speichersicherheitsproblemen.
• Abhängigkeitsprüfung während des Build-Prozesses, um SBOM aktuell zu halten.
• Unit-, Integrations- und Systemtests mit struktureller Codeabdeckung.
• Sicherheitsmechanismen: Bei schwerwiegenden Sicherheitslücken den Build abbrechen, weniger schwerwiegende Probleme mit festgelegten Behebungsfristen verfolgen.
• Jeder Build generiert Testergebnisse, Abdeckungsberichte und Scanprotokolle. Diese bilden Ihren Prüfpfad.

8. Sicherstellung der Rückverfolgbarkeit zwischen Anforderungen, Tests und Fehlerbehebung.

• Verknüpfen Sie jede Sicherheitsanforderung mit den Testfällen, die sie überprüfen, und verknüpfen Sie diese wiederum mit Codeänderungen und Korrektur-Commits.
• Nutzen Sie eine zentrale Berichtslösung, um die Beweislage zu erfassen.

9. Halten Sie revisionssichere Nachweise und technische Dokumentationen bereit.

• Ihre Dokumentation muss aufzeigen, was Sie getan haben, warum und wie Sie es überprüft haben.
• Alles versionieren: Pipeline-Konfigurationen, Sicherheitsregeln, Testfälle, SBOMs und Scanberichte.

10. Überprüfung der Patching- und Sicherheitsupdate-Prozesse.

• Zeigen Sie, dass Sie Patches schnell entwickeln, testen und verteilen können.
• Die Validierung von Patches muss Teil Ihres CI/CD-Prozesses sein (Regressionstests + Sicherheitsüberprüfungen der gepatchten Version).

Wie SBOMs und die Transparenz von Drittanbieterkomponenten die CRA-Bereitschaft unterstützen

Software-Stücklisten (SBOMs) ermöglichen die Transparenz der in einem Produkt verwendeten Open-Source- und Drittanbieterkomponenten. Gemäß dem CRA unterstützen SBOMs die Nachverfolgung von Schwachstellen, das Verständnis von Abhängigkeiten und die Transparenz der Lieferkette. SBOMs allein genügen jedoch nicht den Compliance-Anforderungen.

Organisationen müssen außerdem das Komponentenrisiko bewerten, Schwachstellen validieren, Probleme beheben, Korrekturen überprüfen und die ergriffenen Maßnahmen dokumentieren.

Hier sind die operativen Schritte, die Sie durchführen müssen.

• Automatische Generierung von SBOMs für jede Version.
• SBOMs werden in eine Schwachstellendatenbank wie NVD oder GitHub Advisory DB eingespeist, um bekannte CVEs zu identifizieren.
• Bewerten Sie für jede CVEs die Ausnutzbarkeit im Kontext Ihres Produkts. Nicht alle CVEs sind relevant.
• Maßnahmen zur Fehlerbehebung verfolgen. Komponente aktualisieren, Patch einbinden oder Risiko mit dokumentierter Begründung akzeptieren.
• Überprüfen Sie die Fehlerbehebung mit Regressionstests und Sicherheitsüberprüfungen.
• Bewahren Sie alle oben genannten Unterlagen als revisionssichere Dokumente auf.

Ohne diese Kette ist ein SBOM nur eine Liste – kein Nachweis für die gebotene Sorgfalt.

Wie Schwachstellenmanagement und -berichterstattung in die CRA-Bereitschaft passen

Die CRA wandelt das Schwachstellenmanagement in einen formalen operativen Prozess um. Teams müssen Schwachstellen erkennen, deren Schweregrad bewerten, Verantwortlichkeiten zuweisen, Probleme beheben, Korrekturen validieren, Maßnahmen dokumentieren und bei Bedarf Vorfälle melden.

Dieser Arbeitsablauf muss wiederholbar, nachvollziehbar und in der Lage sein, unter Einhaltung strenger Berichtsfristen zu funktionieren.

Warum 24 Stunden so anspruchsvoll sind

Die meisten Teams verfügen nicht über einen 24-Stunden-Reaktionsprozess für Sicherheitsvorfälle. Um die Anforderungen zu erfüllen, benötigen Sie Folgendes:

• Echtzeitüberwachung – keine wöchentlichen Scans
• Vorabgenehmigte Berichtsvorlagen
• Vorab etablierte Kommunikationswege mit ENISA und nationalen CSIRTs
• Eskalationsverfahren im Bereitschaftsdienst
• Geübte Manöver – Planspiele zur Simulation eines aktiven Angriffs.

Beginnen Sie jetzt mit dem Bau. Die Berichtspflicht beginnt am 11. September 2026.

Was die CRA für Software- und Embedded-Entwicklungsteams bedeutet

Für Software- und Embedded-Engineering-Unternehmen verändert die Einhaltung der CRA-Vorschriften die täglichen Entwicklungsabläufe. Sicherheitsaspekte erstrecken sich nun über den gesamten Softwareentwicklungszyklus (SDLC).

Für Ingenieurorganisationen verändert die Einhaltung der CRA-Vorschriften die tägliche Entwicklung:

• Anforderungen. Sicherheitsanforderungen sind von höchster Priorität und nicht optional.
• Architektur. Bedrohungsmodellierung, wie beispielsweise STRIDE, wird Bestandteil von Designprüfungen.
• Codierung. Statische Analyseregeln werden in IDE und CI durchgesetzt. Keine pauschale Sicherheitsprüfung in später Phase.
• Testen. Unit-Tests, Integrationstests und Testabdeckung müssen die Sicherheitsfunktionalität nachweisen.
• Die Release-Pipeline erzeugt SBOM, Scanberichte, Testergebnisse und Rückverfolgbarkeit als Release-Artefakte.
• Nach der Veröffentlichung. Kontinuierliche Überwachung, Patch-Validierung und Bereitschaftsberichterstattung.

Warum die Entwicklung von Grund auf sicher ist für die Einhaltung der CRA-Richtlinien von zentraler Bedeutung ist

Secure-by-Design ist nicht länger nur eine bewährte Vorgehensweise. Im Rahmen des CRA wird es zur betrieblichen Erwartung.

Sicherheit muss in die Anforderungsdefinition, die Softwarearchitektur, die Codierungsstandards, die Testabläufe, den Umgang mit Schwachstellen und die langfristige Wartung integriert werden. Organisationen, die weiterhin auf Sicherheitsüberprüfungen in späten Phasen setzen, werden Schwierigkeiten haben, die Einhaltung der Vorschriften wiederholt nachzuweisen.

CRA weitet Verantwortung über die Entlassung hinaus aus

Die CRA stellt klar, dass die Veröffentlichung nicht das Ende darstellt. Unternehmen sind verpflichtet, Schwachstellen kontinuierlich zu überwachen, Patches zu validieren, Sicherheitsupdates zu verteilen und während des gesamten Produktlebenszyklus Cybersicherheitssupport zu gewährleisten. Langfristige Betriebsbereitschaft wird somit Teil der Compliance-Strategie.

Warum manuelle Compliance-Prozesse nicht skalierbar sind

Unverbundene Tools, Tabellenkalkulationen, manuelle Beweissammlung, uneinheitliche Berichterstattung und Überprüfungen in späten Phasen bergen operationelle Risiken im Rahmen des CRA.

Mit zunehmender Größe von Produkten und Veröffentlichungen benötigen Sie Folgendes:

• Automatisierte Beweisgenerierung: Jeder Build erzeugt Artefakte.
• Zentralisierte Rückverfolgbarkeit von der Anforderung über den Test bis zur Fehlerbehebung.
• Richtlinien als Code – Sicherheitsregeln, die von der Pipeline und nicht vom Speicher durchgesetzt werden.
• Manuelle Prozesse können die von der CRA erwartete Wiederholbarkeit und Prüfbarkeit nicht gewährleisten.

Wie DevSecOps und CI/CD Teams bei der Vorbereitung auf die CRA-Konformität unterstützen

Moderne DevSecOps-Workflows helfen Unternehmen, Sicherheit direkt in die Softwareentwicklungspipelines zu integrieren. Anstatt Compliance als abschließende Hürde zu betrachten, können CI/CD-Pipelines Sicherheitsrichtlinien kontinuierlich durchsetzen, automatisierte Validierungen durchführen, Audit-Trails generieren und Schwachstellen frühzeitig in der Entwicklung erkennen.

Wie automatisierte Tests die Einhaltung des Cyber ​​Resilience Act unterstützen

Automatisierte Tests spielen eine entscheidende Rolle bei der Vorbereitung auf die CRA-Prüfung. Folgendes ist zu implementieren:

Für C- und C++-Entwicklungsteams Parasoft Embedded-Verifizierungslösungen Integration von statischer Analyse, automatisierten Tests, struktureller Codeabdeckung, Anforderungsrückverfolgbarkeit und Compliance-Berichterstattung zur Unterstützung der Cyber ​​Resilience Act-Bereitschaft.

Erstellung von auditfähigen Nachweisen für CRA-Konformitätsbewertungen

Die CRA verlangt von den Organisationen, dass sie nachweisen, was sie getan haben, und nicht einfach nur behaupten, sie hätten einen bestimmten Prozess befolgt.

Zu den prüfungsfähigen Nachweisen können Cybersicherheitsrisikobewertungen gehören. Rückverfolgbarkeit der AnforderungenErgebnisse der statischen Analyse, Testergebnisse, Codeabdeckungsberichte, Behebungsprotokolle, SBOM-Dokumentation, Schwachstellenhistorie, Ergebnisse der Patch-Validierung und Release-Dokumentation.

Organisationen, die die Erstellung von Nachweisen automatisieren, sind besser gerüstet, um auf Audits und Konformitätsbewertungen zu reagieren.

Obligatorische Meldung von Sicherheitslücken: Was ändert sich im Rahmen des CRA?

Eine der operativ anspruchsvollsten Anforderungen der CRA ist die Meldepflicht für Sicherheitslücken. Organisationen müssen aktiv ausgenutzte Sicherheitslücken innerhalb von 24 Stunden nach deren Entdeckung melden, innerhalb von 72 Stunden zusätzliche technische Informationen bereitstellen und innerhalb von 14 Tagen einen vollständigen Bericht einreichen.

Die Berichte werden über ENISA eingereicht und mit den nationalen CSIRTs koordiniert. Artikel 14 gehört zu den operativ anspruchsvollsten Teilen des CRA. Hier ist der genaue Zeitplan:

Wichtig: Die 24-Stunden-Frist beginnt, sobald Sie von einer aktiven Ausnutzung Kenntnis erlangen – nicht erst, wenn Sie die Ursache bestätigen oder eine Lösung gefunden haben.

Warum die 24-Stunden-Berichterstattung operative Bereitschaft erfordert

Die Einhaltung der 24-Stunden-Meldepflicht erfordert weit mehr als einen reaktiven Incident-Response-Prozess. Organisationen benötigen ausgereifte Erkennungsfähigkeiten, klar definierte Verantwortlichkeiten, Eskalationsverfahren, vordefinierte Kommunikationsabläufe, Berichtsvorlagen und eine geübte operative Einsatzbereitschaft.

Wenn ein realer Vorfall eintritt, bleibt keine Zeit, einen Prozess von Grund auf neu zu entwickeln.

Warten Sie nicht auf einen tatsächlichen Vorfall. Führen Sie ein simuliertes aktives Exploit-Szenario durch. Messen Sie die Zeit von der Erkennung bis zur Übermittlung. Üben Sie, bis Sie das 24-Stunden-Fenster konstant einhalten.
H2: Wie man einen CRA-Bereitschaftsplan erstellt
Organisationen, die sich auf die CRA vorbereiten, sollten die Einhaltung der Vorschriften als einen schrittweisen technischen Transformationsprozess und nicht als eine einmalige rechtliche Angelegenheit betrachten.

Phase 1: Beurteilung (30–60 Tage)

• Identifizieren Sie die in den Geltungsbereich fallenden Produkte.
• Führen Sie eine Gap-Analyse anhand der CRA-Artikel durch.
• Produktklassifizierung ermitteln (Standard/Wichtig/Kritisch).
• Aktuelle Sicherheitspraktiken und -werkzeuge dokumentieren.

Phase 2: Fundament (60–90 Tage)

• Implementieren Sie sichere Codierungsstandards (OWASP/CWE/CERT).
• Generieren Sie SBOMs für alle Produkte.
• Formalisierung der Richtlinien zur Offenlegung von Sicherheitslücken und der entsprechenden Meldeverfahren.
• SAST und Abhängigkeitsprüfung in CI/CD integrieren.

Phase 3: Automatisierung & Nachweisführung (90–120 Tage)

• Sicherheitsvorkehrungen in Pipelines erzwingen (Build bei kritischen Fehlern abbrechen).
• Automatisierte Rückverfolgbarkeit zwischen Anforderungen, Tests und Code.
• Generieren Sie aus jedem Build revisionssichere Berichte.
• Führe Reporting-Übungen durch (24-Stunden-/72-Stunden-/14-Tage-Simulationen).

Phase 4: Validierung & Konformität (laufend)

• Führen Sie gegebenenfalls unabhängige Beurteilungen durch.
• Aktualisieren Sie die Risikobewertungen mit jeder neuen Version.
• Sicherheitslücken kontinuierlich überwachen und beheben.
• Beweismaterial zur Marktüberwachung aufbewahren.

Häufige Fehler bei der Vorbereitung auf die CRA-Prüfung, die Sie vermeiden sollten

• Bis 2027 mit den Vorbereitungen zu warten, ist keine Option. Die Bereitschaft zur Berichterstattung lässt sich nicht über Nacht aufbauen.
• Die CRA-Prüfung lediglich als rechtliche oder dokumentarische Angelegenheit zu betrachten, ändert etwas an der Art und Weise, wie Sie programmieren, testen und veröffentlichen.
• Man verlässt sich auf Tabellenkalkulationen und die manuelle Erfassung von Beweismitteln. Diese Methoden sind nicht skalierbar und fehleranfällig.
• SBOMs ohne Behebungsworkflows zu erstellen, ist sinnlos. Ein SBOM ohne Plan zur Behebung von Schwachstellen ist wertlos.
• Das Aufspüren von Schwachstellen ohne Überprüfung der Behebung ist nicht ausreichend. Ein geschlossenes Ticket ist erst dann ein Beweis, wenn es erneut getestet wurde.
• Sicherheitstests sollten nur vor der Veröffentlichung durchgeführt werden. Schwachstellen, die frühzeitig entdeckt werden, lassen sich später deutlich teurer beheben.

Machen Sie die Einhaltung der CRA-Richtlinien zu einem Wettbewerbsvorteil

Obwohl der Cyber ​​Resilience Act oft als regulatorische Belastung angesehen wird, können Organisationen, die sich frühzeitig vorbereiten, die Softwarequalität stärken, die operative Reife verbessern, das langfristige Cybersicherheitsrisiko reduzieren und ein größeres Kundenvertrauen aufbauen.

Teams, die sichere Entwicklungsprozesse, automatisierte Tests, Rückverfolgbarkeit und die Bereitschaft zur Behebung von Sicherheitslücken in ihre Entwicklungsabläufe integrieren, verbessern nicht nur die Compliance-Bereitschaft, sondern liefern auch robustere Produkte.

Erfahren Sie, wie Parasoft Unterstützt die CRA-Bereitschaft für C- und C++-Software mit integrierten Sicherheitstests.

Legen Sie noch heute los. Überprüfen Sie Ihre Prozesse, automatisieren Sie Ihre Nachweise und trainieren Sie Ihre Berichtsprozesse. Die Fristen rücken näher, als Sie denken.