CRA Security Testing: Welche Tests Hersteller regelmäßig durchführen müssen

Der Cyber Resilience Act verlangt wirksame und regelmäßige Tests und Reviews der Sicherheit von Produkten mit digitalen Elementen. Hersteller müssen deshalb nicht nur einmal vor Marktstart prüfen, sondern ein risikobasiertes Testprogramm über Entwicklung, Release und Supportzeitraum etablieren.

Einordnung im CRA-Wissen: Dieser Fachartikel gehört zum Themenbereich Technische Produktsicherheit. Dort finden Sie die angrenzenden Anforderungen und eine praktische Reihenfolge für die Umsetzung.

Was verlangt der CRA bei Security Testing?

Anhang I Teil II verlangt ausdrücklich effektive und regelmäßige Tests und Reviews der Sicherheit des Produkts. Die Verordnung nennt dabei kein starres Toolset. Entscheidend ist, dass die Prüfungen geeignet sind, die für das konkrete Produkt relevanten Sicherheitsanforderungen und Schwachstellen zu untersuchen.

Der Testplan sollte deshalb aus der CRA-Risikobewertung entstehen. Ein internetfähiges Gateway braucht andere Schwerpunkte als eine lokale Desktopsoftware oder eine eingebettete Komponente ohne direkte Benutzeroberfläche.

Reicht ein Penetrationstest vor dem Release?

Nein. Ein einzelner Penetrationstest kann einen wertvollen Snapshot liefern, erfüllt aber nicht automatisch die Erwartung regelmäßiger und wirksamer Prüfungen. Neue Features, Komponentenupdates, Konfigurationsänderungen und neu bekannt gewordene Angriffstechniken verändern das Risiko nach dem Test.

Ein gutes Programm kombiniert kontinuierliche Prüfungen während der Entwicklung mit tieferen Tests zu definierten Zeitpunkten. Penetrationstests sind dabei ein Baustein, nicht der gesamte Sicherheitsprozess.

Welche Testarten sind für CRA-Produkte sinnvoll?

Die Auswahl richtet sich nach Technologie und Risiko. Typische Bausteine sind statische Codeanalyse, dynamische Tests, Software-Composition-Analysis, Fuzzing, Schnittstellen- und Protokolltests, Authentisierungs- und Autorisierungstests, Konfigurationsprüfungen, Penetrationstests sowie Update- und Recovery-Tests.

Wie oft müssen Tests wiederholt werden?

Der CRA nennt keine universelle Frequenz wie „alle zwölf Monate“. „Regelmäßig“ muss im Kontext von Produkt, Risiko, Änderungsgeschwindigkeit und Supportzeitraum definiert werden. Ein stark vernetztes Produkt mit wöchentlichen Releases braucht andere Zyklen als eine unveränderte Hardwarekomponente.

Hersteller sollten feste Basistermine mit Triggern verbinden: große Funktionsänderung, neue externe Schnittstelle, neue Authentisierung, neue Kernkomponente, wesentliche Architekturänderung, kritische Schwachstelle oder Hinweise aus dem Feld. Diese Trigger machen das Testprogramm nachvollziehbar.

Welche Rolle spielt die Software Bill of Materials?

Eine SBOM unterstützt Security Testing, indem sie verwendete Komponenten und Versionen sichtbar macht. Dependency-Scans können daraus bekannte Schwachstellen ableiten, während die Produktanalyse klärt, ob die betroffene Funktion tatsächlich erreichbar oder ausnutzbar ist.

Ein Scannergebnis allein ist deshalb kein abschließender Befund. Der Hersteller muss technische Betroffenheit, Produktkontext und mögliche Maßnahmen bewerten. False Positives und nicht ausnutzbare Komponenten sollten begründet dokumentiert werden.

Wie wichtig ist Fuzzing?

Fuzzing ist besonders sinnvoll bei Parsern, Protokollen, Dateiformaten, APIs und anderen Stellen, an denen das Produkt komplexe oder potenziell manipulierte Eingaben verarbeitet. Automatisch erzeugte unerwartete Eingaben können Speicherfehler, Abstürze, Ressourcenprobleme oder Logikfehler sichtbar machen.

Der CRA schreibt Fuzzing nicht als Pflichtmethode für jedes Produkt vor. Aus der Risikobewertung kann sich aber ergeben, dass Fuzzing eine geeignete und verhältnismäßige Prüfmethode ist. Dann sollte Umfang, Ziel und Ergebnis dokumentiert werden.

Was muss bei Authentisierung und Berechtigungen getestet werden?

Tests sollten nicht nur prüfen, ob ein Login funktioniert. Relevant sind Umgehungsversuche, Session- und Tokenbehandlung, Passwortreset, Mehrfaktorfunktionen, Rollenwechsel, direkte API-Aufrufe, Zugriff auf fremde Objekte und Rechte nach Deaktivierung eines Kontos.

Besonders wichtig ist die Prüfung horizontaler und vertikaler Rechteausweitung: Kann ein normaler Nutzer Daten eines anderen Nutzers lesen oder administrative Funktionen aufrufen? Der geplante Artikel CRA Zugriffsschutz behandelt die Produktanforderungen im Detail.

Wie testet man Secure by Default?

Die Prüfung muss mit einer frischen Standardinstallation oder einem frisch ausgelieferten Gerät beginnen. Entwicklerumgebungen oder bereits gehärtete Testsysteme sind dafür ungeeignet. Erfasst werden aktive Dienste, Ports, Konten, Berechtigungen, Telemetrie, Updateeinstellungen und Sicherheitsoptionen.

Die Ergebnisse lassen sich mit einer versionierten Baseline vergleichen. So wird sichtbar, wenn ein neues Feature versehentlich einen Dienst aktiviert oder eine Berechtigung erweitert. Der Beitrag CRA Secure by Default liefert dafür die fachliche Grundlage.

Wie prüft man Sicherheitsupdates?

Ein Security Update muss nicht nur den Bug beheben. Tests sollten sicherstellen, dass das Update authentisch und integer verteilt wird, auf unterstützten Versionen funktioniert, bei Unterbrechungen nicht zu einem unsicheren Zustand führt und keine neuen kritischen Schwachstellen einführt.

Bei automatischen Updates kommen Rollout, Aufschub, Opt-out und Recovery hinzu. Die konkrete Update-Strategie beschreibt der Artikel CRA-Sicherheitsupdates.

Was gehört zu Resilienz- und DoS-Tests?

Anhang I verlangt Schutz der Verfügbarkeit wesentlicher und grundlegender Funktionen, auch nach einem Vorfall, sowie Maßnahmen gegen Denial-of-Service. Tests sollten deshalb Ressourcenlimits, Lastspitzen, fehlerhafte Gegenstellen, Netzwerkunterbrechungen und kontrollierte Wiederherstellung betrachten.

Nicht jedes Produkt braucht einen riesigen DDoS-Test. Entscheidend ist, welche Verfügbarkeitsrisiken vernünftigerweise vorhersehbar sind und welche Funktion auch unter Störung erhalten bleiben muss.

Wie prüft man Kryptografie sinnvoll?

Kryptografische Tests betreffen nicht nur Algorithmusnamen. Wichtiger sind Schlüsselgenerierung, Speicherung, Rotation, Zertifikatsprüfung, Nonces, Zufallszahlen, Protokollkonfiguration und Fehlerfälle. Ein modernes Verfahren kann durch schlechtes Schlüsselmanagement wirkungslos werden.

Hersteller sollten möglichst etablierte Bibliotheken und Protokolle verwenden und Eigenentwicklungen vermeiden, sofern kein zwingender Grund besteht. Die Auswahl muss zum Produkt und Stand der Technik passen.

Wer sollte Security Tests durchführen?

Ein Teil kann intern erfolgen, ein Teil extern. Entwickler können automatisierte Tests und Codeanalysen effizient integrieren. Unabhängige interne Reviewer oder externe Spezialisten sind sinnvoll, wenn ein frischer Blick auf Architektur oder Angriffspfade benötigt wird.

Der CRA verlangt nicht pauschal einen externen Penetrationstest für jedes Standardprodukt. Bei bestimmten Produktklassen können jedoch strengere Konformitätsverfahren greifen. Der geplante Beitrag zu wichtigen Produkten Klasse I und II ordnet diese Wege ein.

Wie dokumentiert man Security Tests?

Für jeden relevanten Test sollten Ziel, Umfang, Produktversion, Umgebung, Methode, Ergebnis, offene Findings und Maßnahmen nachvollziehbar sein. Besonders wichtig ist die Verbindung zwischen Finding und Behebung. Ein Bericht ohne Nachweis, was mit kritischen Ergebnissen passiert ist, reicht als Prozessnachweis nicht aus.

Die technische Dokumentation kann auf detaillierte Testberichte verweisen, muss aber die wesentlichen Sicherheitsentscheidungen und den aktuellen Status erkennen lassen. Geplante technische Dokumentationsinhalte werden unter CRA technische Dokumentation vertieft.

Wie behandelt man Findings?

Findings müssen triagiert, bewertet und einem Owner zugeordnet werden. Sicherheitsrelevante Befunde gehören in denselben Schwachstellenmanagement-Prozess wie externe Meldungen. Dadurch gelten einheitliche Prioritäten, Nachweise und Abschlusskriterien.

Ein Test ist erst wirklich abgeschlossen, wenn kritische Findings behoben oder eine begründete, dokumentierte Risikobehandlung beschlossen wurde. „Akzeptiert“ ohne technische Begründung ist kein belastbarer Abschluss.

Was gilt bei False Positives?

Automatisierte Tools erzeugen Fehlalarme. Diese dürfen geschlossen werden, wenn nachvollziehbar geprüft wurde, warum keine tatsächliche Betroffenheit vorliegt. Die Dokumentation sollte Produktversion, relevanten Code- oder Komponentenpfad und die technische Begründung enthalten.

Ein pauschales Unterdrücken ganzer Regelgruppen, nur um die Scanliste kürzer zu machen, schwächt den Prozess. Ausnahmen sollten regelmäßig überprüft werden.

Wie verhindert man Testlücken bei Drittkomponenten?

Lieferanten- oder Open-Source-Komponenten können eigene Testnachweise mitbringen, aber der Hersteller muss trotzdem den Integrationskontext prüfen. Eine sichere Bibliothek kann durch unsichere Konfiguration, falsche Berechtigungen oder fehlerhafte Nutzung im Produkt riskant werden.

Der Lieferanten- & Drittkomponentencheck hilft, Security-Prozesse und Supportfähigkeit von Kernkomponenten strukturiert zu erfassen.

Welche Teststrategie eignet sich für KMU?

Ein KMU kann mit einer gestuften Strategie arbeiten: bei jedem Build automatisierte Abhängigkeits- und Basistests, bei jedem größeren Release gezielte manuelle Security Tests und bei hohem Risiko oder größeren Architekturänderungen einen unabhängigen Penetrationstest.

Dazu kommen ein jährlicher Gesamtcheck der Teststrategie und anlassbezogene Wiederholungen nach kritischen Schwachstellen. So wird die Frequenz risikobasiert statt rein kalendergesteuert.

Wie werden Tests in CI/CD integriert?

Automatisierung ist besonders sinnvoll für wiederholbare Prüfungen: Dependency-Scans, Secret-Scanning, statische Analyse, Unit-Tests sicherheitskritischer Funktionen und Baseline-Checks. Kritische Ergebnisse können den Build blockieren, während weniger dringende Findings in den regulären Vulnerability-Prozess überführt werden.

Die Schwellen sollten bewusst gesetzt werden. Ein Pipeline-Gate, das ständig wegen irrelevanter Findings umgangen wird, schafft keine Sicherheit. Besser ist eine gepflegte Regelbasis mit nachvollziehbaren Ausnahmen.

Was sollte nach einem echten Sicherheitsvorfall neu getestet werden?

Nach einem Vorfall oder einer bestätigten Schwachstelle sollte nicht nur der konkrete Fix geprüft werden. Das Team sollte untersuchen, welche Testart den Fehler früher hätte entdecken können und ob ähnliche Muster an anderen Stellen vorkommen.

Das Ergebnis kann neue Regressionstests, angepasste Codeanalyse-Regeln, erweiterte Fuzzing-Ziele oder neue Architekturprüfungen erzeugen. Dadurch verbessert ein realer Fall dauerhaft die Entwicklungsqualität.

Wie prüft man Security-Anforderungen bei Hardware und Embedded Systems?

Bei eingebetteten Produkten kommen physische und hardwarenahe Angriffspfade hinzu: Debugports, Bootloader, Firmwareextraktion, sichere Bootketten, Hardware-Root-of-Trust, Speicherzugriffe und lokale Wartungsschnittstellen. Welche Tests angemessen sind, hängt von Zugänglichkeit und Risiko ab.

Auch hier gilt: Nicht jede Hardware braucht dieselben Laborprüfungen. Die Risikobewertung muss begründen, welche Angriffsmöglichkeiten vernünftigerweise relevant sind.

Wie werden Testergebnisse versioniert?

Testberichte müssen eindeutig einer Produktversion, Build-ID oder Firmwareversion zugeordnet sein. Andernfalls ist später unklar, ob ein Ergebnis für das tatsächlich in Verkehr gebrachte Produkt gilt. Dasselbe gilt für Testumgebung und relevante Konfiguration.

Bei kontinuierlichen Releases kann ein zentraler Security-Status pro Version sinnvoll sein, der auf detaillierte Reports verweist. So bleibt die technische Dokumentation übersichtlich.

Welche Rolle spielt Threat Modeling?

Threat Modeling ist kein Ersatz für Tests, verbessert aber deren Zielgenauigkeit. Es identifiziert Assets, Vertrauensgrenzen, Angreiferziele und mögliche Missbrauchspfade. Daraus lassen sich konkrete Testfälle ableiten, die ein generischer Scanner nicht kennt.

Besonders neue Schnittstellen, Administrationsfunktionen und Cloud-Verbindungen profitieren von einem kurzen Threat Review. Das verbindet Secure by Design direkt mit der Teststrategie.

Wie definiert man Security-Akzeptanzkriterien für Releases?

Security-Akzeptanzkriterien legen vorab fest, welche Findings einen Release blockieren und welche unter dokumentierten Bedingungen später behandelt werden dürfen. Kriterien können Schweregrad, Ausnutzbarkeit, Exposition, betroffene Produktfunktion und verfügbare Mitigations berücksichtigen. Dadurch wird die Freigabeentscheidung nachvollziehbarer als ein spontanes Abwägen kurz vor dem Release.

Ausnahmen sollten einen Owner, eine Frist und eine technische Begründung erhalten. So wird verhindert, dass bekannte Findings nach der Freigabe ohne Verantwortlichkeit im Backlog verschwinden.

Warum sollten Tests produktionsnahe Konfigurationen verwenden?

Viele Schwachstellen entstehen erst durch reale Konfiguration, Netzwerkpfade oder Berechtigungen. Ein Test auf einer stark vereinfachten Entwicklerumgebung kann deshalb ein falsches Sicherheitsbild erzeugen. Mindestens die kritischen Testfälle sollten mit der vorgesehenen Standardkonfiguration und realistischen Integrationen wiederholt werden.

Das gilt besonders für Authentisierung, Cloud-Anbindungen, Updatewege, Mandantentrennung und externe Schnittstellen. Abweichungen zwischen Test- und Produktionsarchitektur sollten dokumentiert sein.

Wie schützt man Testdaten und Testzugänge?

Security Tests brauchen häufig privilegierte Konten, Beispieldaten oder spezielle Diagnosefunktionen. Diese Hilfsmittel dürfen nicht ungeprüft in Produktionsbuilds oder öffentliche Repositories gelangen. Test-Credentials sollten getrennt, zeitlich begrenzt und nach Abschluss widerrufen werden.

Auch produktionsnahe Testdaten sollten möglichst synthetisch oder ausreichend geschützt sein. Ein gutes Security-Testprogramm darf nicht selbst neue Geheimnis- oder Datenschutzrisiken erzeugen.

Wie prüft man die Wirksamkeit des gesamten Testprogramms?

Ein jährlicher Review kann untersuchen, welche realen Schwachstellen durch vorhandene Tests gefunden wurden und welche erst später auffielen. Wiederkehrende Lücken zeigen, welche Methoden, Testfälle oder Tools ergänzt werden sollten. Dadurch wird das Testprogramm mit jedem Vorfall gezielter.

Wie sollten Security-Tests in die Release-Entscheidung einfließen?

Testergebnisse sollten nicht nur als Bericht abgelegt, sondern in eine klare Freigabeentscheidung übersetzt werden. Für offene Findings braucht es mindestens Schweregrad, betroffene Version, Owner, geplante Maßnahme und Entscheidung, ob ein Release trotz Restrisiko vertretbar ist. Kritische Schwachstellen ohne belastbare Mitigation sollten ein Release-Gate blockieren. So wird aus einzelnen Tests ein wirksamer Qualitätsprozess mit nachvollziehbaren Entscheidungen.

Wo steht die Testpflicht im CRA?

Die ausdrückliche Grundlage findet sich in Anhang I Teil II Nummer 3 der Verordnung (EU) 2024/2847. Dort werden wirksame und regelmäßige Tests und Reviews der Sicherheit des Produkts verlangt.