Cyber Resilience Act : ce qui change pour les développeurs

Comment expliquer le Cyber Resilience Act à un développeur ?
Imaginez qu’un pirate informatique ait accès aux caméras de sécurité chez vous. Il peut voir la même chose que vous dans le visio-babyphone. Cette histoire s’est vraiment produite, et plusieurs fois. Par exemple avec les caméras Ring.

Pour les développeurs, le “Cyber Resilience Act” est le nouveau règlement européen qui doit donner le pouvoir aux consommateurs d’éviter ça.

Ce texte est déjà entré en vigueur en partie et vient compléter l’angle mort du RGPD. Le RGPD protège les données personnelles. Le CRA complète le dispositif en imposant la cybersécurité des produits, de leur conception à leur maintenance. 

On en parle beaucoup moins que du NIS2 ou qu’ISO 27001. C’est probablement que vous allez avoir un 3ᵉ dossier avec un ruban rouge qui tombe sur le coin du bureau. Ou que vous ne serez jamais concernés.

On va revenir en détail sur les effets du Cyber Resilience Act pour les développeurs. Comprendre si et comment on rentre dans le scope. Et, surtout quel impact cela aura sur le quotidien des développeurs et des développeuses.

5 situations où le Cyber Resilience Act s’applique, ou pas.

1 – Objets connectés : concernés.

Le texte parle très précisément de produits numériques. Donc ça concerne votre Freebox Révolution, vos enceintes Devialet, votre iPhone Duo et votre Switch. Mais pas Tesla Model Y dans le garage (c’est la première exception).

Il prévoit un marquage CE qui indique que le produit est conforme au CRA. Un des effets recherchés est explicitement de permettre aux acheteurs européens de préférer le babyphone fabriqué en Europe avec un marquage CE par rapport à la copie chinoise qui embarquerait probablement des backdoors.

En pratique, cela va sûrement pousser les fournisseurs de “Consumer Electronics” occidentaux à se mettre sérieusement à la cybersécurité.

Bref, si vous êtes développeur ou développeuse dans un produit en rapport avec les objets connectés ou des caméras de surveillance, c’est probable que vous soyez au courant du Cyber Resilience Act depuis 2026.

 

2 – Les éditeurs de logiciels : s’il faut l’installer, oui.

Alors ici, on va bien parler de tous les logiciels qui s’installent sur le matériel du client.
Si votre ERP est accessible uniquement en SaaS, c’est pas dans le périmètre.
Par contre Microsoft Word va rentrer dans le périmètre. Si vous faites des logiciels pour les comptables avec Windev, c’est dans le périmètre.

Le Cyber Resilience Act s’applique à tous les backends ou services (API, SDK), indispensables au fonctionnement de ces logiciels.

Encore une fois, pas de panique, c’est sûrement une autoévaluation. Et cette exigence ne s’appliquera qu’aux versions mises sur le marché à partir du 11 décembre 2027. Vous avez le temps.

3 – Les développeurs de logiciels en SaaS : vous n’êtes pas concernés sauf dans certains cas.

Les logiciels en SaaS ne sont pas dans le périmètre. Par contre, attention, ne franchissez pas le Rubicon.
Par exemple, vous vendez un logiciel d’observabilité avec une mascotte en forme de chien ? Si vous demandez à vos clients d’installer un agent sur les serveurs, il est dans le périmètre.

Vous vendez un logiciel d’automatisation pour LinkedIn avec une mascotte en forme de drap housse de matelas ? Si vous fournissez aux utilisateurs une extension Chrome, même gratuite, elle rentre dans le périmètre du Cyber Resilience Act.

Vous prenez votre application web et vous l’embarquez dans un wrapper Electron comme Slack ou Notion ? Elle passe dans le CRA. Et, son backend aussi. C’est le twist.

4 – Le backend d’un produit numérique est concerné.

Vous imaginez bien que si la webcam est fiable, mais que le service Cloud où on stocke les vidéos n’est pas sécurisé, le Cyber Resilience Act serait bien inefficace. 

Alors, il contamine donc les composants logiciels distants indispensables aux fonctionnalités du produit distant. Cela se limite à ceux que vous avez produits vous-même (ou commandés à un sous-traitant). Donc si vous utilisez une API d’AWS pour de la reconnaissance faciale sur les photos, elle n’est heureusement pas concernée. Et il faut être précis, c’est parce qu’on est sûrs qu’ils ne l’ont pas développée spécifiquement pour vous.

Un produit SaaS qui ne s’installe pas et est complètement autonome reste hors périmètre. Mais dès lors que vous commencez à faire des clients installables, le Cyber Resilience Act commence à affecter fortement les développeurs.

5 – Je travaille dans une grande DSI : je ne suis pas concerné.

En pratique, la majorité des lecteurs ici travaillent dans une DSI, que ce soit directement ou indirectement. Que ce soit sur un plateau chez le client, en centre de service dans une ESN ou en full-remote. 

Si vous travaillez sur un logiciel interne comme un système de CRA ou un système de paie, il y a peu de chance que vous soyez concernés.

Par contre, si votre logiciel est vendu à d’autres entreprises, on change de sujet. Par exemple vous le partagez entre filiales du groupe, cela peut devenir une mise sur le marché et rentrer dans le périmètre.

Si vous travaillez dans la grande distribution, on applique la règle “est-ce que ça s’installe ou pas ?”

Par exemple sur un drive assez classique, on va retrouver dans le périmètre : 

• L’application mobile sur le téléphone du client

Et, hors périmètre : 

• Le site web (même mobile)
• L’application de la borne pour le retrait
• L’application utilisée par le préparateur de commande

En interne dans les DSIs, on va surtout voir apparaître des marquages CE sur les logiciels qu’on achète. Le logiciel de gestion des stocks, le WMS va pouvoir présenter un logo correspondant au Cyber Resilience Act. C’est un indicateur un peu plus clair lorsqu’on achète un produit.

6 – Les logiciels open source : la liberté ne suffit pas à sortir du périmètre

Quand on installe un programme sur notre machine, avec apt ou npm, il sera le plus souvent pas concerné par le Cyber Resilience Act.

Sauf si l’éditeur du composant open-source propose des licences commerciales. 

Par exemple Redis ou un produit HashiCorp peuvent avoir leur code ouvert, et des conditions d’utilisation où ils sont gratuits. Et pour autant ils vont rentrer dans le Cyber Resilience Act. Alors qu’OpenBao l’alternative à HashiCorp Vault reste libre et gratuite, donc hors périmètre. Si l’éditeur d’OpenBao commence à proposer des services d’OpenBao à la demande, il devra sûrement rentrer dans le Cyber Resilience Act.

Vous avez un Steward ?

En pratique, si vous fabriquez et commercialisez un produit numérique, comme le fameux babyphone, et que vous utilisez OpenBao pour gérer les secrets du service Cloud pour stocker les photos. Le logiciel libre reste hors périmètre, mais s’il a un problème qui affecte vos utilisateurs, vous êtes responsable. Aussi vous avez donc besoin d’un tiers qui peut vous assurer que le produit logiciel est sûr, et que vous serez notifiés en cas de faille de sécurité, par exemple. 

Ce rôle est identifié par le Cyber Resilience Act. On l’appelle un Steward dans le texte. Pour OpenBao, cela serait probablement la Linux Foundation. C’est une organisation qui soutient durablement le projet et qui pourrait être responsable d’en organiser la cybersécurité. Tous les paquets NPM n’auront pas le soutien d’un Steward et vous allez sûrement préférer ceux qui en ont un.

Quels sont les critères du Cyber Resilience Act qui ont un impact sur les développeurs ?

En 2012, dans Homeland, le Vice-Président des États-Unis est assassiné à distance, les hackers ont juste arrêté son pacemaker. Et à l’époque c’était très réaliste.

Parce que la sécurité des pacemakers est venue après l’innovation. C’était déjà une innovation tellement incroyable de ne pas avoir à envoyer au bloc chaque patient qu’on n’a pas chiffré les échanges radio. C’est comme laisser un Wi-Fi ouvert sans mot de passe. Depuis la règlementation européenne sur les dispositifs médicaux a couvert ce point, et ils sont exclus du CRA pour éviter la double règlementation.

Mais ça reste typiquement le scénario ciblé par les critères de l’Annexe 1 du Cyber Resilience Act.
Et vous allez comprendre en voyant ces critères pourquoi les services web autonomes ne sont pas vraiment inclus dans le périmètre.

Six critères du Cyber Resilience Act appliqués à votre babyphone connecté

Il y a au total 21 critères, et pour chaque critère il faudra trouver comment il devient applicable à votre produit ou démontrer qu’il n’est pas applicable. Pour rendre les choses concrètes, on va reprendre notre exemple du babyphone.

1. Ne pas livrer une faille connue exploitable. Votre babyphone embarque Java et un Linux pour se connecter au Wi-Fi ? On va faire une SBOM des dépendances et suivre leurs failles connues avec un outil comme OpenCVE.
2. Sécuriser la configuration par défaut. Le babyphone ne doit pas arriver avec un mot de passe par défaut qui est le même pour tous les appareils. Il ne doit pas y avoir besoin de passer de WEP à WPA ou de hotspot ouvert sans protection par défaut. Aucun effort pour le sécuriser ne doit être nécessaire.
3. Protéger les accès et les données. Si vous vous rappelez de l’article sur OWASP, il y avait notamment A01 et la fameuse IDOR. Vous devez vous assurer qu’un parent ne puisse pas accéder aux vidéos du babyphone d’une autre famille. Même en déformant une URL.
4. Limiter la surface d’attaque. Pas de logs dangereux en prod (mots de passe ou secrets), pas de port de débug ouvert par défaut.
5. Pouvoir corriger les appareils déjà vendus. Si une faille apparaît demain, il faut pouvoir patcher les appareils vendus. En pratique c’est quand même très contraignant. Aujourd’hui, beaucoup d’appareils dans nos maisons ont été vendus sans système de mise à jour “over-the-air” et ne sont pas patchables même avec un câble. Le CRA imposera de pouvoir patcher les exemplaires qui seront commercialisés à partir du 11 décembre 2027.
6. Organiser le suivi des vulnérabilités. Vous devez connaître les composants embarqués et tester régulièrement leur sécurité. Si un utilisateur trouve un défaut de sécurité, il doit pouvoir vous contacter. L’équivalent du SECURITY.TXT devient obligatoire pour tous, même les babyphones et les frigos connectés.

Comment faire son auto-évaluation ?

Pour chaque critère, vous devrez donc documenter ce que vous avez mis en place et collecter les preuves que ça fonctionne. Ces éléments constitueront votre dossier technique de conformité. Et dans certains cas, votre produit devra être évalué par un organisme notifié.

Cette liste de critères contient : 

• Un principe général de cybersécurité proportionnée aux risques
• 13 exigences sur le produit
• 8 exigences de gestion des vulnérabilités

Le principe général, c’est de partir des risques : qui pourrait attaquer votre babyphone, par où, et avec quelles conséquences ? Il faut donc faire un minimum de threat modelling, puis prévoir les protections adaptées. Le CRA n’impose pas une méthode comme EBIOS RM : l’essentiel est de documenter vos risques et vos choix de sécurité. 

La sécurité du produit, selon les risques et l’applicabilité :

1. Ne pas commercialiser de vulnérabilité connue exploitable.
2. Fournir une configuration sécurisée par défaut, réinitialisable.
3. Permettre les mises à jour de sécurité.
4. Contrôler les accès et signaler les accès non autorisés.
5. Protéger la confidentialité des données.
6. Protéger l’intégrité et signaler les corruptions.
7. Limiter les données traitées au nécessaire.
8. Préserver les fonctions essentielles, notamment face aux dénis de service.
9. Limiter les perturbations des autres appareils et réseaux.
10. Réduire la surface d’attaque.
11. Limiter les conséquences des incidents.
12. Journaliser les activités pertinentes pour la sécurité, avec désactivation possible.
13. Permettre l’effacement définitif et le transfert sécurisé des données.

La gestion des vulnérabilités :

14. Inventorier les composants et vulnérabilités, avec une SBOM.
15. Corriger sans retard ; séparer si possible correctifs et fonctionnalités.
16. Tester régulièrement la sécurité.
17. Publier les informations sur les vulnérabilités corrigées.
18. Organiser leur divulgation coordonnée.
19. Faciliter les signalements, avec un contact dédié.
20. Distribuer les mises à jour de manière sécurisée.
21. Fournir sans retard les correctifs, gratuitement sauf exception, avec les instructions nécessaires.

Le Cyber Resilience Act va laisser certains développeurs sur le côté.

C’est ma conclusion. Le CRA donne aux consommateurs un repère pour choisir leurs appareils, et aux fabricants des exigences communes de sécurité.

Mais surtout, il creuse le gouffre entre les éditeurs qui ont déjà de bonnes pratiques de cybersécurité et les autres.

Si vous êtes développeur et avez déjà le tooling de l’ISP, en particulier la SBOM et le threat modelling, vous avez une bonne longueur d’avance sur le Cyber Resilience Act. Il restera à documenter vos pratiques et à assurer le suivi du produit. Pour l’indie hacker habitué au « Move fast and break things », c’est différent. Le gap entre la présérie sur Kickstarter et la version commercialisable vient de s’agrandir.

Une bonne raison de vous intéresser à la cybersécurité dans vos projets informatiques dès maintenant.