Einhaltung des Cyber ​​Resilience Act & Application Security 

Die meisten Organisationen, die sich mit dem Cyber ​​Resilience Act (CRA) befassen, investieren in die falsche Ebene. Sie stärken ihre IT-Pipelines, erweitern die Scanabdeckung und dokumentieren Risikobewertungen detailliert. All diese Aktivitäten finden vor der Veröffentlichung statt. Die Verordnung sieht jedoch eine rechtliche Verantwortung erst nach der Veröffentlichung vor, wenn das Produkt bereits im Umlauf ist und in Umgebungen eingesetzt wird, die der Hersteller nicht kontrolliert. 

Die CRA legt dies explizit fest. Produkte mit digitalen Elementen müssen grundlegende Cybersicherheitsanforderungen nicht nur bei der Markteinführung, sondern während ihrer gesamten Nutzungsdauer erfüllen. Dies umfasst den Umgang mit Schwachstellen sowie die Erkennung und Meldung von Vorfällen. Dadurch entsteht ein anderes Fehlerszenario, als die meisten Teams vorbereitet sind. Die Einhaltung der Vorschriften hängt nicht davon ab, ob Schwachstellen während der Entwicklung identifiziert wurden, sondern davon, ob das Produkt der Ausnutzung widersteht, die Auswirkungen begrenzt und im Falle einer Ausnutzung Beweise liefert.

Der CRA gilt für jede Organisation, unabhängig von ihrem Standort, die „Produkte mit digitalen Elementen“ (Hardware oder Software) in die EU entwickelt, importiert oder vertreibt.

Zeitleiste: Wann Cyberresilienz operativ wird 

Das Gesetz zur Stärkung der Cyberresilienz ist bereits in Kraft. Es trat am 10. Dezember 2024 in Kraft und sieht einen festgelegten Umsetzungspfad vor, der die Anforderungen an Hersteller von Produkten mit digitalen Elementen schrittweise erhöht. Der erste wichtige operative Meilenstein wird am 11. September 2026 erreicht, wenn die Meldepflichten gemäß Artikel 14 wirksam werden. Die Verordnung gilt ab dem 11. Dezember 2027 in vollem Umfang, wenn die wichtigsten Bestimmungen durchsetzbar sind. 

Diese Abfolge führt zu einem strukturellen Wandel im Umgang mit Compliance. Organisationen durchlaufen einen Übergang, in dem Fähigkeiten, die einst Reife signalisierten, zu verbindlichen Anforderungen mit festgelegten Reaktionszeiten werden. Bis zum Meilenstein 2026 können Teams die Transparenz von Sicherheitslücken und den Umgang mit Schwachstellen als Verbesserungspotenziale betrachten. Danach müssen diese Fähigkeiten innerhalb strenger Zeitvorgaben und untermauert durch Nachweise zur Erkennung, Klassifizierung und Reaktion funktionieren. 

Bis 2027 wird der Standard den gesamten Lebenszyklus abdecken. Sichere Entwicklungsmethoden, Testabdeckung und Risikobewertungen müssen sich direkt auf das Produktverhalten unter realen Bedingungen beziehen. Die Erwartung beschränkt sich nicht auf die Designabsicht. Sie umfasst auch, ob das Produkt Prüfungen in Umgebungen außerhalb der Kontrolle des Unternehmens standhält und ob die unterstützenden Prozesse verifizierbare Nachweise erbringen können. 

Hier geraten viele Vorbereitungsbemühungen ins Stocken. Teams konzentrieren sich auf Dokumentation, Validierung vor der Veröffentlichung und Kontrollabdeckung, da diese Elemente leichter zu erfassen und zu prüfen sind. Der Zeitplan setzt andere Bereiche unter Druck. Er erfordert den Nachweis, dass das Produkt Angriffen widersteht, aktiven Missbrauch erkennt und auch nach der Veröffentlichung verteidigungsfähig bleibt. Die Einhaltung der Vorschriften hängt somit nicht nur von der Vorbereitung, sondern vom Verhalten im laufenden Betrieb und beobachtbaren Beweisen ab. 

Angreifer interagieren mit der Binärdatei, nicht mit Ihren Steuerelementen. 

Anhang I Teil I fordert, dass Produkte die Angriffsfläche verringern, unbefugte Manipulationen verhindern, die Integrität schützen und die Auswirkungen von Vorfällen minimieren. Diese Anforderungen setzen eine direkte Interaktion zwischen Angreifer und eingesetzter Software voraus. 

Eine mobile Anwendung wird heruntergeladen und entpackt. Ihre Klassen und Methoden werden rekonstruiert. API-Endpunkte und Authentifizierungslogik werden extrahiert. Innerhalb derselben Sitzung wird ein Laufzeitinstrumentierungs-Framework eingebunden, um die Ausführung abzufangen und zu modifizieren. Eine Validierungsprüfung wird umgangen, indem der Rückgabewert einer Funktion überschrieben wird. Serverseitig wird keine Anomalie ausgelöst, da die Anfrage strukturell gültig bleibt. Dies ist die grundlegende Ausführungsumgebung, für die die CRA entwickelt wurde. 

Digital.ai Application Security Die kompilierte Anwendung wird so verändert, dass Reverse Engineering keine brauchbare Darstellung der Logik mehr liefert. Der Kontrollfluss wird transformiert, Kennungen werden entfernt und die Ausführungspfade werden nichtlinear. Dies macht die Analyse zwar nicht unmöglich, erhöht aber den Aufwand über das für die meisten Angriffe praktische Maß hinaus. Es wird davon ausgegangen, dass die Anwendung bereits erstellt ist, und der Fokus liegt darauf, wie sie sich verhält, wenn der Angreifer vollen Zugriff darauf hat.  

Diese Schritte lassen sich mit einer Standard-Mobile-Banking-Anwendung innerhalb weniger Minuten nachvollziehen. Die Geschäftslogik wird direkt aus der kompilierten Anwendung rekonstruiert. Clientseitige Steuerelemente werden durch statische Analyse sichtbar. Anschließend wird die Laufzeitinstrumentierung verwendet, um die Validierungslogik während der Ausführung zu überschreiben. 

In einer typischen Implementierung verwaltet die Anwendung Benutzersitzungen mithilfe eines vom Server ausgestellten Tokens, der lokal auf dem Gerät gespeichert wird. Architektonisch betrachtet erscheint dieses Modell kontrolliert und sicher, da die Kommunikation zwischen Anwendung und Backend-Diensten authentifiziert ist. Aus Benutzersicht funktioniert die Anwendung weiterhin wie vorgesehen. An das Backend gesendete Anfragen bleiben strukturell gültig, authentifiziert und entsprechen dem erwarteten Verhalten. Infrastrukturell werden keine Anomalien festgestellt. Die Kompromittierung findet ausschließlich innerhalb der Anwendungsgrenzen statt, wo die Ausführung verändert und sensible Daten offengelegt wurden, ohne die erwarteten Anfragemuster zu beeinträchtigen. 

Die Ausnutzung erfolgt innerhalb der Anwendung. 

Eine Banking-Anwendung kann sichere Entwicklungsmethoden anwenden, Authentifizierung erzwingen und serverseitige Validierung nutzen, aber dennoch nach der Bereitstellung angreifbar bleiben. Eine mobile Banking-Anwendung verwaltet Benutzersitzungen mithilfe eines vom Server ausgestellten Tokens, der lokal auf dem Gerät gespeichert wird. Die Anwendung kommuniziert mit Backend-Endpunkten für Login, Kontostandsabfrage und Transaktionen. Aus architektonischer Sicht erscheint dieses Modell kontrolliert und sicher. 

Anstatt die Infrastruktur anzugreifen, extrahiert ein Angreifer die Anwendungsdatei und rekonstruiert deren Logik. Mithilfe gängiger Reverse-Engineering-Tools identifiziert er API-Endpunkte, Authentifizierungsabläufe und den Speicherort der Sitzungstoken. Anschließend wird die Anwendung mit eingeschleustem Code neu verpackt und über eine Phishing-Website verbreitet, die den legitimen Dienst imitiert. Installiert und startet ein Benutzer diese modifizierte Version, verhält sich die Anwendung aus Benutzersicht wie erwartet. Gleichzeitig erfasst sie jedoch das Sitzungstoken und übermittelt es an den Angreifer. 

Mithilfe dieses Tokens sendet der Angreifer gültige Anfragen direkt an das Backend. Der Server verarbeitet diese Anfragen ohne Auffälligkeiten, da Struktur und Authentifizierung legitim erscheinen. Aus Sicht der Infrastrukturüberwachung geschieht nichts Ungewöhnliches. Aus Sicht der Anwendung wurde die Ausführung jedoch verändert und sensible Daten wurden offengelegt. Dies ist die Betriebsumgebung, die der Cyber ​​Resilience Act voraussetzt. Das Produkt befindet sich nicht mehr unter der Kontrolle des Herstellers. Der Angreifer interagiert direkt mit der Anwendung, verändert ihr Verhalten und nutzt sie über legitime Wege aus. 

Eine Risikobewertung wird nur dann durchgeführt, wenn die Anwendung sie beinhaltet. 

Artikel 13 verpflichtet Hersteller von Produkten mit digitalen Elementen, Cybersicherheitsrisiken zu bewerten und sicherzustellen, dass diese Risiken in Design, Entwicklung, Produktion und Wartung berücksichtigt werden. Die Verordnung schreibt außerdem vor, dass diese Bewertung dokumentiert, gepflegt und in der Funktionsweise des Produkts abgebildet wird. In der Praxis existiert die Bewertung jedoch lediglich als Dokumentation, während die Durchsetzung von externen Kontrollen abhängt. Reverse Engineering wird als Risiko identifiziert, jedoch gibt es keinen Mechanismus, der es verhindert. Laufzeitmanipulation wird zwar anerkannt, die Erkennung basiert jedoch auf Infrastruktursignalen, die diese nicht erfassen können. 

Digital.ai AppSec schließt diese Lücke, indem es die Ergebnisse der Risikoanalyse direkt in die Anwendung integriert. Wird Reverse Engineering als Bedrohung identifiziert, sorgt Verschleierung direkt für Widerstand gegen diese Aktivität. Wird Manipulation festgestellt, stellt der Manipulationsschutz sicher, dass veränderte Ausführungspfade erkannt und blockiert werden. Sind sensible Daten gefährdet, werden sie innerhalb der Anwendung geschützt, sodass sie weder durch statische noch durch dynamische Analyse extrahiert werden können. 

Dadurch entsteht ein direkter Zusammenhang zwischen den Anforderungen der Risikoanalyse (CRA) und dem Produktverhalten. Die Verordnung verlangt, dass Risiken minimiert und Vorfälle verhindert oder deren Auswirkungen reduziert werden. Diese Anforderung ist nur dann erfüllt, wenn die Anwendung selbst diese Bedingungen während der Ausführung durchsetzt. Digital.ai AppSec führt weder die Risikobewertung durch noch pflegt es die Dokumentation zur Einhaltung der Vorschriften. AppSec stellt sicher, dass die Ergebnisse dieser Bewertung während des realen Betriebs der Anwendung umgesetzt werden, wo die Einhaltung der Vorschriften letztendlich geprüft wird. 

Die Verordnung erkennt die Patch-Lücke an, die meisten Architekturen jedoch nicht. 

Anhang I Teil II fordert, dass Sicherheitslücken unverzüglich behoben und Sicherheitsupdates effektiv verteilt werden. Derselbe Abschnitt verlangt kontinuierliche Tests, koordinierte Offenlegung und Mechanismen zur Bereitstellung von Updates. Die Verordnung erkennt an, dass Sicherheitslücken bestehen bleiben und im Laufe der Zeit behoben werden müssen. Sie geht nicht von einer sofortigen Behebung aus. Dadurch entsteht ein bekanntes Zeitfenster zwischen der Offenlegung der Sicherheitslücke und der vollständigen Implementierung des Patches. Während dieses Zeitraums ist die Sicherheitslücke öffentlich, Ausnutzungstechniken sind verfügbar und die eingesetzten Systeme bleiben ungepatcht. 

Digital.ai AppSec verringert die Ausnutzbarkeit von Schwachstellen in diesem Zeitraum. Wenn die Ausnutzung das Verständnis der anfälligen Logik erfordert, verlängert die Verschleierung die Zeit, die zum Auffinden und Interpretieren dieser Logik benötigt wird. Wenn die Ausnutzung eine Änderung der Ausführung erfordert, blockiert der Manipulationsschutz das veränderte Verhalten. Wenn die Ausnutzung von der Beobachtung des Laufzeitverhaltens abhängt, stören Schutzmechanismen die zur Durchführung dieser Beobachtung verwendeten Werkzeuge. Dies verändert die praktischen Auswirkungen der Schwachstelle. Sie bleibt zwar bestehen, ist aber schwieriger in großem Umfang auszunutzen. 

Digital.ai AppSec ersetzt weder Schwachstellenmanagement, SBOM-Erstellung noch Patch-Verteilung. Diese Funktionen bleiben notwendig, um die Verpflichtungen gemäß CRA zu erfüllen. AppSec befasst sich mit dem Zeitraum, in dem diese Funktionen Risiken nicht schnell genug beseitigen können. 

Artikel 14 verlangt Beweise, keine Annahmen. 

Die CRA führt explizite Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle ein, mit festgelegten Fristen für Benachrichtigung und Nachverfolgung. Eine aktiv ausgenutzte Schwachstelle liegt vor, wenn verlässliche Beweise für böswillige Nutzung vorliegen. Ein schwerwiegender Vorfall umfasst Fälle, in denen Schadcode eingeschleust oder die Sicherheit des Produkts wesentlich beeinträchtigt wird. Die meisten Organisationen können diese Anforderung mit den bestehenden Telemetriedaten nicht erfüllen. Infrastrukturprotokolle zeigen Anfragen an. Netzwerküberwachung zeigt Verkehrsmuster. Beides zeigt jedoch nicht, ob eine Funktion im Speicher überschrieben oder die Ausführung durch Instrumentierung verändert wurde. 

Bei einer typischen Mobile-Banking-Anwendung kann eine clientseitige Validierungsfunktion zur Laufzeit überschrieben werden, wodurch eine normalerweise blockierte Transaktion durchgeführt werden kann. Die Anwendung sendet weiterhin Anfragen, die exakt den Erwartungen des Backends entsprechen. Die Anfrage bleibt strukturell gültig, authentifiziert und ist nicht von legitimem Datenverkehr zu unterscheiden. In den Infrastruktur- oder Netzwerkprotokollen treten keine Anomalien auf. Ohne Erkennung auf Anwendungsebene gibt es keine Hinweise auf eine Ausnutzung der Sicherheitslücke. Digital.ai AppSec liefert Signale an der Stelle, an der eine Sicherheitslücke ausgenutzt wird. Wenn sich ein Debugger an die Anwendung anhängt, wird dies erkannt. Speicheränderungen werden identifiziert. Weicht die Ausführung vom erwarteten Verhalten ab, kann die Anwendung dies als anomal kennzeichnen. Dies schafft die für Artikel 14 erforderliche Ausgangsbasis. 

In der Anwendung wird anomales Verhalten festgestellt. Dieses Verhalten wird mit bekannten Exploit-Techniken oder Sicherheitslücken korreliert. Das Ereignis wird anhand der CRA-Definition von Exploitation validiert. Es wird als aktiv ausgenutzte Sicherheitslücke oder schwerwiegender Vorfall eingestuft. Die Meldung erfolgt anschließend innerhalb der vorgeschriebenen Fristen von 24 bzw. 72 Stunden. Ohne die Erkennung auf Anwendungsebene kommt diese Kette nicht in Gang. Digital.ai AppSec ersetzt weder Systeme zur Reaktion auf Sicherheitsvorfälle noch Meldeverfahren für Aufsichtsbehörden. Es liefert jedoch die für diese Verfahren erforderlichen Nachweise. 

Unterstützungszeiträume erweitern das Risiko über die technische Kontrolle hinaus. 

Die CRA verpflichtet Hersteller, einen Supportzeitraum festzulegen und Sicherheitslücken während dieses Zeitraums zu beheben, in den meisten Fällen mindestens fünf Jahre. Sie schreibt außerdem vor, dass Sicherheitsupdates verfügbar bleiben und Sicherheitslücken während dieser Zeit kontinuierlich geschlossen werden. In der Praxis wird jedoch nicht immer die neueste Softwareversion installiert. Ältere Versionen sind weiterhin auf verschiedenen Geräten, in unterschiedlichen Umgebungen und trotz des Nutzerverhaltens präsent. Angreifer konzentrieren sich auf diese Versionen, da deren Verhalten stabil und bekannt ist. 

Digital.ai AppSec stellt sicher, dass die Schutzmechanismen auch in diesen Versionen erhalten bleiben. Selbst wenn die Anwendung nicht aktualisiert wird, werden weiterhin Integritätsprüfungen durchgeführt, Reverse Engineering verhindert und Manipulationsversuche erkannt. Dadurch wird die Ausnutzung bekannter Schwachstellen in langlebigen Umgebungen deutlich erschwert. 

Digital.ai AppSec verlängert weder den Supportzeitraum noch verwaltet es die Update-Bereitstellung. Es reduziert das Risiko, das sich ergibt, wenn der Supportzeitraum auf reale Nutzungsmuster trifft. 

Das Lieferkettenrisiko wird erst im Endprodukt ausnutzbar. 

Die CRA verpflichtet Hersteller zur sorgfältigen Prüfung von Fremdkomponenten und zur Behebung von Schwachstellen im gesamten Produkt. Sie schreibt außerdem die Identifizierung von Komponenten mithilfe von Mechanismen wie SBOMs (Structured Basic Management Documents) und die Behebung der darin entdeckten Schwachstellen vor. Die Verordnung behandelt das Produkt als eine Einheit, unabhängig von seiner Montage. 

Digital.ai AppSec greift an diesem Konvergenzpunkt an. Versucht ein Angreifer, durch Anwendungsanalyse anfällige Komponenten zu identifizieren, schränkt die Verschleierung die Sichtbarkeit der Codestruktur ein. Hängt die Ausnutzung von der Manipulation dieser Komponenten zur Laufzeit ab, greifen Manipulationsschutz und Laufzeitschutzmechanismen in diesen Prozess ein. Dadurch werden Schwachstellen in der Lieferkette nicht beseitigt, aber ihre Nutzbarkeit im Produktivbetrieb reduziert. 

Digital.ai AppSec verfolgt keine Abhängigkeiten und verwaltet keine SBOMs. Es stellt sicher, dass die Anwendung potenzielle Risiken durch solche Abhängigkeiten nicht leicht Angreifern zugänglich macht. 

An der Grenze entsteht die meiste Verwirrung. 

Der Cyber ​​Resilience Act umfasst mehrere Bereiche, darunter Designanforderungen, Umgang mit Schwachstellen, Berichterstattung, Konformitätsbewertung und Marktüberwachung. 

Digital.ai Application Security Es arbeitet präzise in einem dieser Bereiche. Es gewährleistet die Sicherheit innerhalb der Anwendung zur Laufzeit. Es schützt die ausführbare Datei vor Analyse, erkennt Manipulationen und begrenzt den Erfolg von Ausnutzungen. Es generiert Signale, die zur Validierung von Ausnutzungsereignissen verwendet werden können.  

Es führt keine statische Analyse durch, verwaltet keine Abhängigkeitsinventare, generiert keine SBOMs, orchestriert keine Release-Pipelines, verteilt keine Patches und erstellt keine Konformitätsdokumentation. Diese Systeme definieren und verwalten Compliance-Verpflichtungen. Digital.ai AppSec stellt sicher, dass diese Verpflichtungen auch dann gültig bleiben, wenn die Anwendung feindlichen Bedingungen ausgesetzt ist. 

Letzte Perspektive 

Der Cyber ​​Resilience Act geht davon aus, dass Sicherheitslücken existieren, Angreifer diese ausnutzen und Produkte unter diesen Bedingungen sicher bleiben müssen. Die Verordnung definiert Anforderungen für Design, Lebenszyklusmanagement und Berichterstattung, die Durchsetzung erfolgt jedoch erst zur Laufzeit. Die Einhaltung der Vorschriften wird dann festgestellt, wenn die Anwendung in den Händen eines Angreifers ist, ihr Verhalten untersucht und verändert wird und Sicherheitslücken aktiv ausgenutzt werden. 

Digital.ai Application Security An dieser Stelle greift die CRA ein. Sie stellt sicher, dass die Anwendung Analysen widersteht, ihre Integrität gewährleistet, Angriffsversuche erkennt und die Auswirkungen von Schwachstellen im realen Betrieb minimiert. Auf dieser Ebene wird die CRA tatsächlich getestet.