Tag : Cyber resilience act
Tous les articles du blog avec ce tag.
- 07 Sep, 2026
Cyber Resilience Act : préparer le signalement des incidents pour logiciels, scripts et SDK
Le Cyber Resilience Act entre progressivement dans la vie opérationnelle des éditeurs logiciels. À partir du 11 septembre 2026, les fabricants concernés devront signaler les vulnérabilités activement exploitées et les incidents graves ayant un impact sur la sécurité des produits comportant des éléments numériques. Pour un SaaS B2B, un outil analytics, un script JavaScript, un SDK ou un composant distribué à des clients, le sujet mérite d’être analysé avec prudence. Il ne faut pas conclure que tout service SaaS est automatiquement concerné de la même façon. Il ne faut pas non plus attendre décembre 2027 pour organiser la réponse aux incidents. Cet article ne remplace pas une qualification juridique. Il propose une méthode de préparation pour les équipes produit, sécurité et engineering qui distribuent du logiciel ou des composants utilisés par leurs clients. Ce qui change le 11 septembre 2026 La Commission européenne indique qu’à compter du 11 septembre 2026, les fabricants doivent notifier certaines situations concernant des produits comportant des éléments numériques : les vulnérabilités activement exploitées et les incidents graves affectant la sécurité du produit. Les délais sont courts :alerte précoce sans retard indu et dans les 24 heures après la prise de connaissance ; notification de vulnérabilité dans les 72 heures ; rapport final dans les délais prévus, notamment 14 jours après disponibilité d’une mesure corrective ou de mitigation pour une vulnérabilité activement exploitée, ou dans le mois suivant la notification à 72 heures pour certains incidents graves.Les notifications passent par la CRA Single Reporting Platform, opérée par l’ENISA, avec transmission aux CSIRT compétents selon les règles applicables. Le point essentiel : ces obligations de signalement arrivent avant l’application complète des principales obligations produit du Cyber Resilience Act. Elles doivent donc être préparées maintenant, même si une partie du régime se déploie plus tard. Pourquoi les scripts et SDK doivent être regardés de près Les équipes analytics pensent souvent à la sécurité de leur application principale : authentification, accès au dashboard, exports, bases de données. Mais la surface produit peut inclure d’autres éléments :un script JavaScript installé sur les sites clients ; un SDK côté client ou côté serveur ; une librairie open source maintenue par l’éditeur ; un connecteur ou plugin ; une API utilisée pour collecter ou exposer des données ; une interface d’administration permettant de modifier du code injecté.Tous ces éléments n’ont pas automatiquement la même qualification. Mais ils doivent figurer dans un inventaire de sécurité, car une vulnérabilité dans un composant distribué peut toucher plusieurs clients en même temps. Pour un outil analytics, un script de collecte est particulièrement sensible : il s’exécute sur des sites tiers, dans le navigateur des visiteurs, et peut être mis à jour de manière centralisée. Une faille de distribution, une compromission de build ou une modification non autorisée peut avoir un impact bien plus large qu’un bug d’affichage dans un tableau de bord. Ne pas confondre bug, vulnérabilité et incident grave Tout incident technique n’est pas un signalement CRA. Un graphique cassé, un rapport qui ne se charge pas ou une erreur d’agrégation ne constituent pas nécessairement une vulnérabilité activement exploitée ou un incident grave de sécurité. La première étape du runbook doit donc être la qualification.Situation Question à poserBug fonctionnel Affecte-t-il la sécurité du produit ou seulement l’expérience utilisateur ?Faille identifiée en interne Est-elle exploitable, exposée, corrigée, communiquée ?Vulnérabilité activement exploitée Existe-t-il des indices d’exploitation réelle ?Incident de sécurité A-t-il un impact grave sur la sécurité du produit ou de ses utilisateurs ?Incident de données personnelles Nécessite-t-il aussi une évaluation RGPD distincte, incluant la notification si elle est requise ?Le danger est double. Sous-déclarer un incident réellement grave expose l’organisation. Sur-déclarer chaque bug non qualifié peut saturer la réponse et créer du bruit. La décision doit être tracée, même lorsqu’elle conclut à l’absence de signalement. Le runbook minimal à préparer Un runbook utile doit être concret. Il ne doit pas seulement dire « prévenir le juridique ». Il doit permettre à l’équipe de réagir dans les premières heures. 1. Inventaire des composants Listez les produits, scripts, SDK, plugins et connecteurs distribués ou mis à disposition des clients. Pour chacun, documentez : propriétaire interne, dépôts, pipeline de build, mécanisme de mise à jour, clients exposés, dépendances critiques et canaux de communication. 2. Critères de qualification Définissez une grille simple : sécurité affectée ou non, exploitation observée ou non, impact potentiel, périmètre client, correctif disponible, preuves techniques, obligations parallèles possibles. 3. Équipe de décision Identifiez les personnes qui peuvent qualifier l’incident : engineering, sécurité, produit, direction, juridique, DPO lorsque des données personnelles sont concernées. Les suppléants doivent être connus. Les week-ends et jours fériés doivent être couverts. 4. Horodatage Le délai court à partir de la prise de connaissance. Il faut donc consigner le moment où l’organisation a eu suffisamment d’informations pour suspecter ou qualifier l’événement. Un ticket sans horodatage fiable rendra la conformité plus difficile à démontrer. 5. Preuves et journalisation Préservez les logs, versions, hashes de build, artefacts déployés, traces d’exploitation, messages clients, alertes internes et décisions de qualification. Les preuves doivent être suffisantes pour reconstruire la chronologie. 6. Canal de signalement La plateforme unique de signalement est opérée par l’ENISA. Les équipes doivent savoir qui dispose des accès nécessaires, quelles informations préparer et comment agir si l’accès principal est indisponible. L’ENISA a indiqué qu’il n’y avait pas d’API prévue à ce stade pour le signalement, ce qui rend les procédures humaines encore plus importantes. 7. Communication client Un signalement réglementaire ne remplace pas la communication aux clients. Préparez des modèles sobres : ce qui est connu, ce qui est incertain, ce que le client doit faire, quand une mise à jour sera fournie. Cas particulier : analytics et scripts tiers Un script analytics devrait être traité comme un actif sensible, même lorsqu’il collecte peu de données. Il peut être intégré à des pages publiques, à des tunnels de conversion ou à des environnements authentifiés. La sécurité du script ne concerne donc pas seulement l’éditeur, mais aussi les sites qui l’installent. Quelques contrôles concrets :séparation des droits entre code applicatif, pipeline de build et publication du script ; revue des dépendances ; signature ou contrôle d’intégrité des artefacts lorsque pertinent ; détection de modification inattendue ; capacité de rollback rapide ; procédure de désactivation ou de mitigation ; documentation des versions déployées chez les clients.Ces pratiques sont utiles au-delà du CRA. Elles réduisent le risque opérationnel et facilitent la communication en cas de crise. Ce qu’il faut décider maintenant Les équipes qui attendent le premier incident pour organiser leur réponse perdront du temps dans les 24 premières heures. Or ce sont précisément les heures les plus contraintes. D’ici la fin septembre, une équipe logicielle devrait pouvoir répondre à quatre questions :Quels composants distribués à des clients pourraient entrer dans le périmètre ? Qui qualifie une vulnérabilité activement exploitée ? Qui peut soumettre une notification dans les délais ? Comment prouver la chronologie de décision ?Si ces réponses n’existent pas, le sujet n’est pas encore maîtrisé. Conclusion Le Cyber Resilience Act ne doit pas être résumé à une échéance lointaine de 2027. Les obligations de signalement applicables à partir du 11 septembre 2026 imposent dès maintenant une discipline de préparation aux fabricants concernés. Pour les éditeurs SaaS et analytics, la priorité n’est pas de paniquer, ni de supposer que tout est automatiquement dans le périmètre. La priorité est d’inventorier les composants, qualifier les rôles, préparer le runbook et documenter les décisions. Un bon dispositif de signalement n’est pas seulement une réponse réglementaire. C’est une preuve de maturité produit. FAQ Le CRA concerne-t-il tous les dashboards SaaS ? Pas automatiquement. La qualification dépend du produit, du rôle de l’organisation et de la manière dont les composants logiciels sont mis sur le marché ou fournis. L’article sert de checklist de préparation, pas de qualification juridique pour tous les cas SaaS. Faut-il signaler chaque bug de sécurité ? Non. L’obligation évoquée ici concerne les vulnérabilités activement exploitées et les incidents graves ayant un impact sur la sécurité, selon le cadre du CRA. Les bugs ordinaires doivent être traités, mais ils ne doivent pas être confondus avec un déclencheur réglementaire. Pourquoi une équipe analytics doit-elle s’en préoccuper ? Une stack analytics inclut souvent scripts, SDK, clés API, configuration côté client et dépendances tierces. Même lorsque l’obligation juridique repose ailleurs, l’équipe doit savoir remonter l’incident et contacter les bons fournisseurs. SourcesCommission européenne - Cyber Resilience Act reporting obligations Commission européenne - Cyber Resilience Act summary ENISA - CRA Single Reporting Platform FAQ