Découvrez GoogleTest certifié TÜV avec Agentic AI pour les tests C/C++ !
Plus de détails »
Aller à la section
Blog Parasoft
La loi sur la cyber-résilience fait passer la sécurité d'une étape finale de déploiement à une exigence d'ingénierie continue, avec un signalement des vulnérabilités 24 heures sur 24 à partir de septembre 2026. Voici ce que les équipes logicielles et embarquées doivent faire dès maintenant.
Aller à la section
La loi sur la cyber-résilience (CRA) a un impact sur les logiciels, les systèmes embarqués, les appareils connectés et les produits numériques vendus sur le marché de l'UE.
La loi sur la cyber-résilience est un règlement de l'Union européenne visant à améliorer la cybersécurité des produits comportant des éléments numériques.
Le règlement CRA s'applique aux logiciels, aux objets connectés, aux systèmes embarqués, aux équipements industriels, aux plateformes automobiles, aux dispositifs IoT et aux matériels fonctionnant avec des logiciels mis sur le marché de l'UE. Ce règlement établit des exigences obligatoires en matière de cybersécurité tout au long du cycle de vie du produit, y compris le développement, la gestion des vulnérabilités, le signalement des incidents, les mises à jour de sécurité et l'évaluation de la conformité.
Les obligations des agences de réglementation des crédits (ARC) ne se limitent pas aux éditeurs de logiciels traditionnels. Les fabricants, importateurs, distributeurs et entreprises non européennes commercialisant des produits concernés sur le marché européen peuvent également être touchés. Les entreprises développant des systèmes embarqués, des calculateurs automobiles, des contrôleurs industriels, des systèmes aérospatiaux, des dispositifs médicaux, des équipements de réseau et des objets connectés grand public devraient d'ores et déjà évaluer leur exposition.
La CRA n'est pas une simple réglementation de cybersécurité. Elle modifie en profondeur la manière dont les équipes conçoivent, développent, testent, documentent, déploient et maintiennent les logiciels et les systèmes embarqués. Pour les organisations qui développent des produits intégrant des éléments numériques, la conformité à la CRA impose des obligations légales en matière de sécurité dès la conception, de gestion des vulnérabilités, de reporting et de responsabilité tout au long du cycle de vie.
En traduisant les exigences réglementaires en actions d'ingénierie concrètes, votre équipe saura quoi faire et comment le faire.
La loi sur les risques liés aux cyberattaques (CRA) est officiellement entrée en vigueur le 10 décembre 2024. Les obligations de déclaration obligatoire des vulnérabilités débutent le 11 septembre 2026, tandis que les obligations de conformité plus générales deviennent exécutoires le 11 décembre 2027.
Ces dates peuvent paraître lointaines, mais les organisations ne peuvent pas attendre la dernière minute pour se préparer. Les équipes d'ingénierie ont besoin de temps pour mettre en place des flux de travail reproductibles, automatiser la génération de preuves, intégrer la sécurité aux pipelines CI/CD, formaliser les processus de reporting et aligner les pratiques de développement sur les principes de sécurité dès la conception.
| Délai | Exigence |
|---|---|
| X | L'ARC est entrée en vigueur |
| 11-Sep-26 | Le signalement obligatoire des vulnérabilités commence |
| X | Conformité totale exécutoire |
Attendre 2027 n'est pas envisageable. Les équipes d'ingénierie ont besoin de temps pour mettre en place des flux de travail reproductibles, automatiser la génération de preuves, intégrer la sécurité aux pipelines CI/CD, formaliser les processus de reporting et aligner le développement sur les principes de sécurité dès la conception. Le délai pour être prêt à produire des rapports commence en septembre 2026.
La loi sur la cybersécurité (CRA) introduit de vastes obligations en matière de cybersécurité qui influent sur la façon dont les produits sont développés et maintenus. Les principales catégories d'exigences comprennent :
Approfondissez
Apprenez à intégrer Conformité CWE dans votre cycle de développement »
L'agence d'évaluation du crédit (CRA) classe les produits en trois catégories : par défaut, importants ou critiques, en fonction du risque et de l'impact.
Les produits figurant aux annexes III et IV font l'objet d'un examen plus approfondi et peuvent nécessiter des évaluations de conformité indépendantes réalisées par un organisme tiers. La classification ne doit pas être considérée comme un audit de dernière minute. Il s'agit d'une décision d'ingénierie stratégique qui influe directement sur le niveau de contrôle, les exigences en matière de documentation, les activités de validation et les coûts de mise en conformité.
| Catégories | Description | Exemples | Chemin de conformité |
|---|---|---|---|
| Par défaut (~90 % des produits) | Non répertorié dans les annexes, risque moindre | Capteurs IoT de base, logiciel bureautique | Auto-évaluation |
| Important – Classe I | Annexe III, impact moindre | Gestionnaires de mots de passe, serrures intelligentes | Auto-évaluation du respect des normes harmonisées |
| Important – Classe II | Annexe III, impact plus élevé | Systèmes d'exploitation, pare-feu | Évaluation obligatoire par un tiers |
| Critical | Annexe IV | Compteurs intelligents, modules de sécurité matériels | Certification tierce ou européenne |
Déterminez la catégorie de votre produit. S'il ne figure pas aux annexes III ou IV, il est considéré comme non prioritaire. Cependant, si une modification risque d'affecter la sécurité publique ou les services essentiels, les autorités réglementaires peuvent le qualifier de critique, indépendamment de sa présence sur la liste.
Se préparer à la conformité aux exigences de la CRA ne se limite pas à la simple révision du texte réglementaire ou à la production de documents juste avant un audit. Les services d'ingénierie ont besoin de processus de développement, de test, de gestion des vulnérabilités et de reporting reproductibles, capables de démontrer en continu leur niveau de préparation en matière de cybersécurité tout au long du cycle de vie du produit.
Pour de nombreuses équipes de développement logiciel et de systèmes embarqués, le défi ne réside pas dans l'absence d'activités de sécurité, mais dans le manque de cohérence, de traçabilité et d'intégration opérationnelle tout au long du cycle de vie du développement logiciel. La préparation à l'analyse des risques liés à la sécurité (CRA) dépend de la transformation des tâches de sécurité cloisonnées en flux de travail d'ingénierie mesurables et auditables.
Un point de départ pratique comprend les activités suivantes.
Les nomenclatures logicielles (SBOM) permettent de visualiser les composants open source et tiers utilisés dans un produit. Dans le cadre de la loi CRA, les SBOM facilitent le suivi des vulnérabilités, la connaissance des dépendances et la transparence de la chaîne d'approvisionnement. Cependant, les SBOM ne suffisent pas à elles seules pour satisfaire aux exigences de conformité.
Les organisations doivent également évaluer les risques liés aux composants, valider les vulnérabilités, corriger les problèmes, vérifier les correctifs et documenter les actions entreprises.
Voici les étapes opérationnelles que vous devez suivre.
Sans cette chaîne de transmission, une SBOM n'est qu'une liste, et non une preuve de diligence raisonnable.
Le CRA transforme la gestion des vulnérabilités en un processus opérationnel formel. Les équipes doivent détecter les vulnérabilités, évaluer leur gravité, en attribuer la responsabilité, corriger les problèmes, valider les correctifs, documenter les actions et signaler les incidents lorsque cela est nécessaire.
Ce processus doit être reproductible, traçable et capable de fonctionner dans le respect de délais de reporting stricts.
| Etape | Implication de l'ARC |
|---|---|
| Détecter les vulnérabilités | SAST, DAST, analyse des dépendances, rapports externes |
| Évaluer la gravité | CVSS + contexte métier (est-il activement exploité ?) |
| Attribuer la propriété | Établissez une matrice RACI claire pour chaque produit |
| Remédier | Correction de code, mise à jour de composant ou mesure d'atténuation |
| Valider la correction | Tests automatisés + analyses de sécurité sur la version corrigée |
| Actions du document | Traçabilité de la détection à la correction, jusqu'aux tests |
| Rapportez dans les délais impartis | Alerte 24h / Détails 72h / Rapport complet 14j à ENISA/CSIRT |
La plupart des équipes ne disposent pas d'une procédure de réponse aux incidents de sécurité fonctionnant 24 heures sur 24. Pour être en conformité, vous devez :
Commencez à élaborer ce projet dès maintenant. L'obligation de déclaration débutera le 11 septembre 2026.
Pour les entreprises de développement logiciel et de systèmes embarqués, la conformité aux normes CRA modifie leurs activités de développement quotidiennes. Les considérations de sécurité s'appliquent désormais à l'ensemble du cycle de vie du développement logiciel (SDLC).
Pour les entreprises d'ingénierie, la conformité aux normes CRA modifie le développement quotidien :
La sécurité dès la conception n'est plus seulement une bonne pratique. En vertu de l'ARC, elle devient une exigence opérationnelle.
La sécurité doit être intégrée à la définition des exigences, à l'architecture logicielle, aux normes de codage, aux processus de test, à la gestion des vulnérabilités et à la maintenance à long terme. Les organisations qui continuent de s'appuyer sur des audits de sécurité tardifs auront du mal à démontrer une conformité constante.
Approfondissez
Apprener comment Conformité OWASP prend en charge le développement sécurisé dès la conception »
L'ARC précise que la mise en production n'est pas une fin en soi. Les organisations doivent surveiller en permanence les vulnérabilités, valider les correctifs, diffuser les mises à jour de sécurité et assurer un support en cybersécurité tout au long du cycle de vie du produit. La préparation opérationnelle à long terme fait partie intégrante de la stratégie de conformité.
Des outils déconnectés, des feuilles de calcul, la collecte manuelle de preuves, des rapports incohérents et des examens tardifs créent un risque opérationnel dans le cadre de l'ARC.
À mesure que le nombre de produits et de mises en production augmente, vous avez besoin de :
Les flux de travail DevSecOps modernes permettent aux organisations d'intégrer la sécurité directement dans leurs pipelines de livraison logicielle. Au lieu de considérer la conformité comme une étape finale, les pipelines CI/CD peuvent appliquer en continu les politiques de sécurité, effectuer des validations automatisées, générer des journaux d'audit et détecter les vulnérabilités plus tôt dans le développement.
Les tests automatisés jouent un rôle essentiel dans la préparation aux exigences des agences d'évaluation du crédit. Voici les éléments à mettre en œuvre :
| Type de test | Pertinence de l'ARC |
|---|---|
| Analyse statique (SAST) | Identifier rapidement les 10 principales vulnérabilités OWASP, les faiblesses CWE et les problèmes de sécurité de la mémoire |
| Analyse des dépendances | Maintenez la nomenclature des composants (SBOM) à jour et signalez les vulnérabilités connues dans les composants tiers. |
| Tests unitaires | Valider les fonctions liées à la sécurité, telles que la validation des entrées et le contrôle d'accès. |
| Test d'intégration | Vérifiez les limites de sécurité entre les composants |
| Les tests de régression | Veillez à ce que les correctifs ne réintroduisent pas d'anciennes vulnérabilités. |
| Couverture de code | Démontrer que le code critique pour la sécurité est testé – viser > 80 % pour les modules de sécurité |
| Traçabilité des exigences | Associez chaque test à une exigence ou à un contrôle de sécurité d'une ARC. |
Pour les équipes de développement C et C++, Solutions de vérification embarquées Parasoft Intégrer l'analyse statique, les tests automatisés, la couverture structurelle du code, la traçabilité des exigences et les rapports de conformité pour soutenir la préparation à la loi sur la cyber-résilience.
L'ARC exige que les organisations prouvent ce qu'elles ont fait, et non qu'elles se contentent d'affirmer avoir suivi une procédure.
Les éléments de preuve prêts pour un audit peuvent inclure des évaluations des risques de cybersécurité, traçabilité des exigences, résultats d'analyse statique, résultats de tests, rapports de couverture de code, enregistrements de correction, documentation SBOM, historiques de vulnérabilités, résultats de validation des correctifs et documentation de version.
Les organisations qui automatisent la production de preuves seront mieux placées pour répondre aux audits et aux évaluations de conformité.
L'une des exigences opérationnelles les plus contraignantes du CRA est le signalement obligatoire des vulnérabilités. Les organisations doivent signaler les vulnérabilités activement exploitées dans les 24 heures suivant leur découverte, fournir des informations techniques complémentaires dans les 72 heures et remettre un rapport complet dans les 14 jours.
Les rapports sont soumis via l'ENISA et coordonnés avec les CSIRT nationaux. L'article 14 est l'un des aspects les plus complexes à mettre en œuvre de la loi sur les rapports d'incidents (CRA). Voici le calendrier précis :
| Date limite de déclaration | Exigence | Bénéficiaire |
|---|---|---|
| Dans les 24 heures suivant la prise de connaissance d'un activement exploité vulnérabilité | Alerte initiale : identification du produit, nature de l’exploit, mesures d’atténuation disponibles | ENISA via la plateforme + CSIRT national |
| Réalisée sous 72h | Détails techniques, évaluation d'impact, score CVSS, étapes intermédiaires | ENISA + CSIRT |
| Dans les jours qui 14 | Rapport complet : cause racine, versions concernées, disponibilité du correctif, preuves de correction | ENISA + CSIRT |
Important : Le délai de 24 heures commence lorsque vous prenez connaissance d’une exploitation active, et non lorsque vous confirmez la cause première, ni lorsque vous avez trouvé une solution.
Le respect de l'obligation de reporting sous 24 heures exige bien plus qu'une simple réponse réactive aux incidents. Les organisations ont besoin de capacités de détection éprouvées, d'une responsabilité clairement définie, de procédures d'escalade, de flux de communication prédéfinis, de modèles de rapports et d'une préparation opérationnelle éprouvée.
Lorsqu'un incident réel survient, il n'y a pas le temps de concevoir un processus à partir de zéro.
N’attendez pas un incident réel. Lancez une simulation d’exploitation active. Mesurez le temps nécessaire entre la détection et la soumission. Entraînez-vous jusqu’à atteindre systématiquement le délai de 24 heures.
H2 : Comment élaborer une feuille de route de préparation à l’accréditation CRA
Les organisations qui se préparent à la CRA devraient aborder la conformité comme une transformation technique progressive plutôt que comme un exercice juridique ponctuel.
Bien que la loi sur la cyber-résilience soit souvent perçue comme un fardeau réglementaire, les organisations qui se préparent tôt peuvent renforcer la qualité de leurs logiciels, améliorer leur maturité opérationnelle, réduire les risques de cybersécurité à long terme et instaurer une plus grande confiance de leurs clients.
Les équipes qui intègrent le développement sécurisé dès la conception, les tests automatisés, la traçabilité et la préparation aux vulnérabilités dans leurs flux de travail d'ingénierie amélioreront non seulement leur conformité, mais proposeront également des produits plus résilients.
Découvrez comment Parasoft prend en charge la conformité CRA pour les logiciels C et C++ avec des tests de sécurité intégrés.
Commencez dès aujourd'hui. Auditez vos processus, automatisez vos preuves et prenez de bonnes habitudes en matière de reporting. Les échéances approchent à grands pas.
