La sécurité produit tout au long du cycle de vie

La sécurité informatique d'entreprise protège l'infrastructure de l'organisation et est généralement pilotée par un SMSI conforme à l'ISO/IEC 27001. La sécurité produit, elle, protège le produit sur le terrain – dans l'environnement du client, souvent avec un accès physique possible pour les attaquants, et sur des durées qui dépassent largement les cycles de support informatique habituels. Une vulnérabilité ne touche alors pas un système isolé, mais l'ensemble du parc installé, et peut entraîner des conséquences en matière de sûreté de fonctionnement (safety), des rappels ou la perte de l'homologation de type. Sur le plan organisationnel, la responsabilité se déplace ainsi de l'exploitation informatique vers le développement produit – avec ses propres systèmes de management (CSMS), processus de développement (Secure Development Lifecycle) et structures de réaction (PSIRT).

L'ISO/SAE 21434:2021 définit l'ingénierie de la cybersécurité des véhicules routiers sur l'ensemble du cycle de vie – de la phase de concept à la mise hors service. Sa pièce maîtresse est la Threat Analysis and Risk Assessment (TARA) selon le chapitre 15 : de l'identification des actifs à la décision de traitement du risque, en passant par les scénarios de menace et l'analyse des dommages et des chemins d'attaque. Les règlements de l'UNECE rendent le sujet contraignant : l'UN R155 exige un système de management de la cybersécurité (CSMS) certifié comme condition de l'homologation de type, l'UN R156 un système de gestion des mises à jour logicielles (SUMS). Dans l'UE, les deux s'appliquent via le règlement General Safety Regulation (EU) 2019/2144 – depuis juillet 2022 pour les nouveaux types de véhicules, depuis juillet 2024 pour tous les véhicules neufs ; l'ISO/SAE 21434 est considérée comme l'état de l'art reconnu pour la mise en œuvre des exigences CSMS.

Pour les composants des systèmes d'automatisation industrielle, la série IEC 62443 distingue exigences de processus et exigences produit. L'IEC 62443-4-1:2018 décrit un cycle de développement produit sécurisé en huit practices – du management de la sécurité et de la spécification des exigences à la gestion des défauts et des correctifs et aux guides de sécurité pour les utilisateurs, en passant par la conception sécurisée, l'implémentation et la vérification – qui s'étend expressément jusqu'à la fin de vie du produit et s'évalue selon quatre niveaux de maturité. L'IEC 62443-4-2:2019 spécifie les exigences techniques applicables aux composants eux-mêmes : des Component Requirements pour quatre types de composants (embedded devices, host devices, composants réseau, applications logicielles), dérivées de sept Foundational Requirements et échelonnées en Security Levels SL 1 à SL 4. Pour les fabricants, ces deux parties deviennent de plus en plus des critères d'achat, car les exploitants demandent concrètement des preuves et des Security Levels.

Le règlement délégué (UE) 2022/30 active les exigences de cybersécurité de l'art. 3, paragraphe 3, points d) à f) de la directive sur les équipements radioélectriques (RED) ; depuis le 1er août 2025, elles constituent une condition contraignante de mise sur le marché des équipements radioélectriques connectés à Internet. Les normes EN 18031-1, -2 et -3 (édition 2024) servent de normes harmonisées pour la protection du réseau, la protection des données personnelles et la protection contre la fraude ; la Commission européenne les a inscrites au Journal officiel en janvier 2025 – avec toutefois des restrictions. Si un produit permet par exemple de renoncer à un mot de passe (sections 6.2.5.1/6.2.5.2), ou si un contrôle parental garanti fait défaut au titre de l'EN 18031-2 (sections 6.1.3–6.1.6), la présomption de conformité ne s'applique pas et un organisme notifié doit être impliqué. Les fabricants devraient donc examiner ces restrictions tôt dans la procédure d'évaluation de la conformité.

Un Product Security Incident Response Team (PSIRT) traite les vulnérabilités des propres produits de l'entreprise – à la différence du CSIRT, qui gère les incidents touchant sa propre infrastructure. Le PSIRT Services Framework v1.1 de FIRST (2020) structure les missions en six domaines de services – Stakeholder Ecosystem Management, Vulnerability Discovery, Triage, Remediation, Disclosure ainsi que Training et Education – et décrit des modèles d'organisation distribués, centralisés et hybrides. Au plus tard avec le Cyber Resilience Act (règlement (UE) 2024/2847), cette capacité devient une obligation : à partir du 11 septembre 2026, les fabricants devront signaler les vulnérabilités activement exploitées, conformément à l'art. 14, selon un échelonnement de 24 heures, 72 heures et 14 jours, au CSIRT désigné comme coordinateur et à l'ENISA ; le même échelonnement s'applique aux incidents graves, avec un mois pour le rapport final. Sans processus PSIRT rodés, ces délais sont pratiquement intenables.

La sécurité produit ne s'arrête pas au lancement sur le marché : la gestion des vulnérabilités, les mises à jour de sécurité et la surveillance doivent être planifiées et financées sur toute la durée d'utilisation. Le Cyber Resilience Act exige une période de support qui reflète la durée d'utilisation attendue du produit et qui est en règle générale d'au moins cinq ans (art. 13, paragraphe 8) ; les mises à jour de sécurité doivent être fournies gratuitement, et la période de support doit être communiquée de manière transparente avant l'achat. Les normes sectorielles intègrent elles aussi la fin de vie : l'IEC 62443-4-1 l'inclut expressément dans le cycle de développement, l'UN R156 exige des mises à jour logicielles gérées sur toute la durée de vie du véhicule. Une fin de vie ordonnée comprend l'annonce anticipée de la fin du support, de derniers avis de sécurité et des trajectoires de migration pour les clients existants.