Conformité à la loi sur la cyber-résilience et Application Security 

La plupart des organisations qui s'attaquent à la loi sur la cyber-résilience (CRA) investissent au mauvais endroit. Elles renforcent leurs processus, étendent la couverture des analyses et documentent en détail les évaluations des risques. Toutes ces activités ont lieu avant la mise en production. Or, la réglementation impose la responsabilité juridique après la mise en production, lorsque le produit est déjà distribué et utilisé dans des environnements que le fabricant ne contrôle pas. 

La loi sur la conformité aux normes de cybersécurité (CRA) l'établit clairement. Les produits comportant des éléments numériques doivent satisfaire aux exigences essentielles de cybersécurité non seulement lors de leur mise sur le marché, mais tout au long de leur cycle de vie opérationnel, notamment en ce qui concerne la gestion des vulnérabilités et la détection et le signalement des incidents. Cela crée un mode de défaillance différent de celui auquel la plupart des équipes sont préparées. La conformité ne dépend pas de l'identification des vulnérabilités pendant le développement, mais de la capacité du produit à résister à l'exploitation, à limiter l'impact des attaques et à produire des preuves en cas d'exploitation.

L’accord de reconnaissance mutuelle (ARC) s’applique à toute organisation, quel que soit son emplacement, qui développe, importe ou distribue des « produits comportant des éléments numériques » (matériel ou logiciel) dans l’UE.

Chronologie : Quand la cyber-résilience devient opérationnelle 

La loi sur la cyber-résilience est déjà en cours de mise en œuvre. Entrée en vigueur le 10 décembre 2024, elle prévoit un calendrier de déploiement progressif qui accroît graduellement les obligations des fabricants de produits intégrant des éléments numériques. La première étape opérationnelle majeure interviendra le 11 septembre 2026, avec l'entrée en vigueur des obligations de déclaration prévues à l'article 14. L'ensemble du règlement s'appliquera à compter du 11 décembre 2027, date d'application des dispositions principales. 

Cette séquence induit un changement structurel dans la manière dont la conformité est vécue. Les organisations traversent une transition où les capacités qui, autrefois, témoignaient de leur maturité, deviennent des exigences contraignantes assorties de délais de réponse définis. Avant 2026, les équipes peuvent considérer la visibilité des exploitations et la gestion des vulnérabilités comme des axes d'amélioration. Après cette date, ces mêmes capacités doivent être mises en œuvre dans des délais stricts, étayés par des preuves démontrant la détection, la classification et la réponse. 

D’ici 2027, la norme s’appliquera à l’ensemble du cycle de vie. Les pratiques de développement sécurisé, la couverture des tests et les évaluations des risques devront être directement liées au comportement du produit en conditions réelles d’utilisation. L’exigence ne se limite pas à la conception initiale ; elle porte également sur la capacité du produit à résister à un examen critique lorsqu’il est exécuté dans des environnements hors du contrôle de l’organisation, et sur la capacité des processus de support à produire des preuves vérifiables lors des analyses. 

C’est souvent à ce stade que les efforts de préparation commencent à dévier de leur objectif initial. Les équipes se concentrent sur la documentation, la validation avant mise en production et la couverture des contrôles, car ces éléments sont plus faciles à recenser et à auditer. Or, les délais serrés imposent des contraintes ailleurs. Il est nécessaire de prouver que le produit résiste à l’exploitation, détecte les abus actifs et reste protégé après sa mise en production. La conformité dépend alors du comportement en temps réel et des preuves observables, et non plus seulement de la préparation. 

Les attaquants interagissent avec le fichier binaire, pas avec vos commandes. 

L’annexe I, partie I, exige que les produits limitent la surface d’attaque, empêchent toute manipulation non autorisée, protègent l’intégrité et réduisent l’impact des incidents. Ces exigences supposent une interaction directe entre l’attaquant et le logiciel déployé. 

Une application mobile est téléchargée et décompressée. Ses classes et méthodes sont reconstruites. Les points de terminaison de l'API et la logique d'authentification sont extraits. Au cours de la même session, un framework d'instrumentation d'exécution est attaché pour intercepter et modifier l'exécution. Un contrôle de validation est contourné en redéfinissant la valeur de retour d'une fonction. Aucune anomalie côté serveur n'est déclenchée car la requête reste structurellement valide. Il s'agit de l'environnement d'exécution de base pour lequel le CRA est conçu. 

Digital.ai Application Security Cette méthode modifie l'application compilée de sorte que la rétro-ingénierie ne permet plus d'obtenir une représentation exploitable de sa logique. Le flux de contrôle est transformé, les identificateurs sont supprimés et les chemins d'exécution deviennent non linéaires. L'analyse reste possible, mais l'effort requis devient prohibitif pour la plupart des attaques. Cette méthode suppose que l'application est déjà construite et se concentre sur son comportement lorsque l'attaquant y a un accès complet.  

Ces étapes peuvent être reproduites en quelques minutes à l'aide d'une application bancaire mobile standard. La logique métier est reconstruite directement à partir de l'application compilée. Les contrôles côté client deviennent visibles grâce à l'analyse statique. L'instrumentation d'exécution permet ensuite de modifier la logique de validation lors de l'exécution. 

Dans une implémentation classique, l'application maintient les sessions utilisateur grâce à un jeton émis par le serveur et stocké localement sur l'appareil. D'un point de vue architectural, ce modèle apparaît contrôlé et sécurisé, avec une communication authentifiée entre l'application et les services backend. L'application continue de fonctionner comme prévu pour l'utilisateur. Les requêtes envoyées au backend restent structurellement valides, authentifiées et conformes au comportement attendu. Du point de vue de l'infrastructure, aucune anomalie n'est détectée. La compromission se produit entièrement au sein de l'application, où l'exécution a été modifiée et des données sensibles exposées sans perturber les schémas de requêtes attendus. 

L'exploitation se produit à l'intérieur de l'application. 

Une application bancaire peut respecter des pratiques de développement sécurisées, imposer l'authentification et s'appuyer sur la validation côté serveur, tout en restant vulnérable une fois déployée. Une application de banque mobile maintient les sessions utilisateur grâce à un jeton émis par le serveur et stocké localement sur l'appareil. L'application communique avec les points de terminaison du serveur pour la connexion, la consultation du solde et les transactions. D'un point de vue architectural, ce modèle apparaît contrôlé et sécurisé. 

Au lieu de cibler l'infrastructure, un attaquant extrait le binaire de l'application et en reconstitue la logique. À l'aide d'outils de rétro-ingénierie classiques, il identifie les points de terminaison de l'API, les flux d'authentification et l'emplacement de stockage des jetons de session. L'application est ensuite reconditionnée avec du code injecté et redistribuée via un site d'hameçonnage imitant le service légitime. Lorsqu'un utilisateur installe et exécute cette version modifiée, l'application se comporte comme prévu de son point de vue. Simultanément, elle capture le jeton de session et le transmet à l'attaquant. 

Grâce à ce jeton, l'attaquant envoie des requêtes valides directement au serveur. Ce dernier traite ces requêtes sans déclencher d'anomalies, car la structure et l'authentification semblent légitimes. Du point de vue de la surveillance de l'infrastructure, rien d'anormal n'est constaté. Du point de vue de l'application, son exécution est altérée et des données sensibles sont exposées. C'est dans ce contexte opérationnel que repose la loi sur la cyber-résilience. Le produit n'est plus sous le contrôle du fabricant. L'attaquant interagit directement avec l'application, modifie son comportement et l'exploite en utilisant des voies d'accès légitimes. 

L'évaluation des risques n'est appliquée que si l'application la comporte. 

L'article 13 impose aux fabricants de produits comportant des éléments numériques d'évaluer les risques de cybersécurité et de veiller à ce qu'ils soient pris en compte tout au long des phases de conception, de développement, de production et de maintenance. Le règlement exige également que cette évaluation soit documentée, mise à jour et intégrée au fonctionnement du produit. En pratique, l'évaluation se limite à la documentation, tandis que son application repose sur des contrôles externes. La rétro-ingénierie est identifiée comme un risque, mais aucun mécanisme ne la prévient. La manipulation en cours d'exécution est reconnue, mais sa détection dépend de signaux d'infrastructure qui ne permettent pas de l'observer. 

Digital.ai AppSec comble cette lacune en intégrant les résultats de l'évaluation des risques directement dans l'application. Si l'évaluation identifie la rétro-ingénierie comme une menace, l'obfuscation renforce la protection contre cette activité. En cas de manipulation, les mesures anti-altération garantissent la détection et le blocage des chemins d'exécution modifiés. Si des données sensibles sont menacées, elles sont protégées au sein de l'application afin d'empêcher leur extraction par analyse statique ou dynamique. 

Cela crée un lien direct entre les exigences de l'agence de réglementation des risques (CRA) et le comportement du produit. La réglementation exige que les risques soient minimisés et que les incidents soient prévenus ou que leur impact soit réduit. Cette exigence n'est satisfaite que si l'application elle-même applique ces conditions lors de son exécution. Digital.ai AppSec ne réalise pas l'évaluation des risques ni la documentation de conformité. Son rôle est de veiller à ce que les conclusions de cette évaluation soient appliquées au sein de l'application lors de son exploitation réelle, là où la réglementation est finalement testée. 

La réglementation reconnaît le manque de correctifs, contrairement à la plupart des architectures. 

L’annexe I, partie II, exige que les vulnérabilités soient corrigées sans délai et que les mises à jour de sécurité soient diffusées efficacement. Cette même section impose des tests continus, une divulgation coordonnée et des mécanismes de diffusion des mises à jour. Le règlement reconnaît que des vulnérabilités existeront et devront être traitées progressivement. Il ne présuppose pas une correction immédiate. Il en résulte une période d’exposition connue entre la divulgation d’une vulnérabilité et l’adoption complète du correctif. Durant cette période, la vulnérabilité est publique, des techniques d’exploitation sont disponibles et les instances déployées restent non corrigées. 

Digital.ai La sécurité applicative réduit l'exploitabilité des vulnérabilités pendant cet intervalle. Si l'exploitation nécessite la compréhension de la logique vulnérable, l'obfuscation allonge le temps nécessaire pour localiser et interpréter cette logique. Si l'exploitation requiert une modification de l'exécution, les mesures anti-falsification bloquent le comportement altéré. Si l'exploitation repose sur l'observation du comportement en cours d'exécution, les protections perturbent les outils utilisés pour cette observation. L'impact concret de la vulnérabilité s'en trouve modifié : elle demeure présente, mais son exploitation à grande échelle est plus difficile. 

Digital.ai AppSec ne remplace pas la gestion des vulnérabilités, la génération de SBOM ni la distribution des correctifs. Ces fonctions restent indispensables pour respecter les obligations CRA. AppSec intervient pendant la période où ces fonctions ne permettent pas d'éliminer les risques suffisamment rapidement. 

L’article 14 exige des preuves, et non des suppositions. 

La loi CRA introduit des obligations de déclaration explicites pour les vulnérabilités exploitées et les incidents graves, avec des délais définis pour la notification et le suivi. Une vulnérabilité est considérée comme exploitée lorsqu'il existe des preuves fiables d'une utilisation malveillante. Un incident grave inclut les cas où du code malveillant est introduit ou lorsque la sécurité du produit est significativement compromise. La plupart des organisations ne peuvent satisfaire à cette exigence avec les outils de télémétrie existants. Les journaux d'infrastructure enregistrent les requêtes. La surveillance du réseau révèle les schémas de trafic. Aucun de ces outils ne permet de détecter qu'une fonction a été surchargée en mémoire ou que l'exécution a été altérée par instrumentation. 

Dans une application bancaire mobile standard, une fonction de validation côté client peut être contournée à l'exécution, autorisant ainsi une transaction normalement bloquée. L'application continue d'émettre des requêtes parfaitement conformes aux attentes du serveur. La requête reste structurellement valide, authentifiée et indiscernable du trafic légitime. Aucune anomalie n'apparaît dans les journaux d'infrastructure ou de réseau. Sans détection au niveau de l'application, rien ne prouve qu'une exploitation ait eu lieu. Digital.ai AppSec émet des signaux au moment précis où une exploitation se produit. Lorsqu'un débogueur se connecte à l'application, il est détecté. Lorsqu'une modification de la mémoire est identifiée, cette modification est repérée. Lorsqu'une exécution s'écarte du comportement attendu, l'application peut la signaler comme anormale. Ceci constitue le point de départ requis par l'article 14. 

Un comportement anormal est détecté au sein de l'application. Ce comportement est corrélé à des techniques d'exploitation ou des vulnérabilités connues. L'événement est validé par rapport à la définition d'exploitation du CRA. Il est classé comme vulnérabilité activement exploitée ou comme incident grave. Un rapport est ensuite établi dans les délais requis de 24 et 72 heures. Sans détection au niveau de l'application, ce processus ne peut être déclenché. Digital.ai AppSec ne remplace pas les systèmes de réponse aux incidents ni les processus de déclaration réglementaire. Il fournit les preuves requises par ces processus. 

Les périodes de soutien étendent le risque au-delà du contrôle technique 

L'accord de garantie des consommateurs (CRA) exige des fabricants qu'ils définissent une période de support et gèrent les vulnérabilités pendant toute cette période, généralement d'une durée minimale de cinq ans. Il exige également que les mises à jour de sécurité restent disponibles et que les vulnérabilités continuent d'être corrigées durant cette période. En pratique, les logiciels déployés ne convergent pas vers la dernière version. Les versions plus anciennes persistent sur différents appareils, environnements et selon les comportements des utilisateurs. Les attaquants se concentrent sur ces versions car leur comportement est stable et connu. 

Digital.ai AppSec garantit la persistance des protections au sein de ces versions. Même lorsque l'application n'est pas mise à jour, elle continue d'effectuer des contrôles d'intégrité, de résister à la rétro-ingénierie et de détecter les tentatives de manipulation. Cela réduit l'efficacité de l'exploitation des vulnérabilités connues dans les déploiements de longue durée. 

Digital.ai AppSec ne prolonge pas la période de support et ne gère pas la distribution des mises à jour. Il réduit les risques qui s'accumulent lorsque la période de support correspond aux pratiques d'utilisation réelles. 

Le risque lié à la chaîne d'approvisionnement ne devient exploitable que dans le produit final. 

La loi sur la responsabilité du fabricant (CRA) exige des fabricants qu'ils fassent preuve de diligence raisonnable à l'égard des composants tiers et qu'ils corrigent les vulnérabilités de l'ensemble du produit. Elle exige également l'identification des composants au moyen de mécanismes tels que les nomenclatures de sécurité (SBOM) et la correction des vulnérabilités découvertes dans ces composants. La réglementation considère le produit comme une unité unique de responsabilité, indépendamment de son mode d'assemblage. 

Digital.ai La sécurité applicative opère à ce point de convergence. Si un attaquant tente d'identifier les composants vulnérables en analysant l'application, l'obfuscation limite la visibilité sur la structure du code. Si l'exploitation repose sur la manipulation de ces composants lors de l'exécution, les protections anti-falsification et d'exécution interfèrent avec ce processus. Cela n'élimine pas les vulnérabilités de la chaîne d'approvisionnement, mais réduit leur vulnérabilité en contexte de déploiement. 

Digital.ai AppSec ne gère pas les dépendances ni les SBOM. Elle veille à ce que, lorsque ces dépendances présentent un risque, l'application ne les expose pas facilement aux attaquants. 

C'est à la frontière que se produit la plupart des confusions. 

La loi sur la cyber-résilience couvre de multiples domaines, notamment les exigences de conception, la gestion des vulnérabilités, le signalement, l'évaluation de la conformité et la surveillance du marché. 

Digital.ai Application Security Il opère avec précision dans l'un de ces domaines. Il assure la sécurité de l'application lors de son exécution. Il protège l'exécutable contre l'analyse, détecte les manipulations et limite les chances de succès des exploits. Il génère des signaux permettant de valider les tentatives d'exploitation.  

Il n'effectue pas d'analyse statique, ne gère pas les inventaires de dépendances, ne génère pas de nomenclatures de sécurité (SBOM), n'orchestre pas les pipelines de déploiement, ne distribue pas de correctifs et ne produit pas de documentation de conformité. Ces systèmes définissent et gèrent les obligations de conformité. Digital.ai AppSec garantit que ces obligations restent valides lorsque l'application est exposée à des conditions adverses. 

Perspective finale 

La loi sur la cyber-résilience part du principe que des vulnérabilités existeront, que des attaquants les exploiteront et que les produits doivent rester sécurisés dans ces conditions. La réglementation définit des exigences relatives à la conception, à la gestion du cycle de vie et au reporting, mais son application est vérifiée lors de l'exécution. C'est lorsque l'application est entre les mains d'un attaquant, lorsque son comportement est analysé et modifié, et lorsque des vulnérabilités sont activement exploitées, que la conformité est déterminée. 

Digital.ai Application Security C’est à ce niveau qu’il intervient. Il garantit la résistance de l’application à l’analyse, assure son intégrité, détecte les tentatives d’exploitation et atténue l’impact des vulnérabilités en conditions réelles d’utilisation. C’est à cette couche que le CRA est testé.