Un chercheur en sécurité découvre une vulnérabilité dans votre produit. Il cherche un canal pour vous le signaler de façon responsable. Si vous n’avez pas de processus en place, il peut publier directement la CVE — sans vous laisser le temps de corriger. C’est exactement ce que le CRA cherche à éviter, en imposant aux fabricants de mettre en place une capacité de réponse aux vulnérabilités : le PSIRT.
1. Définition — ce qu’est un PSIRT
Un PSIRT — Product Security Incident Response Team — est l’équipe ou le processus chargé de recevoir les signalements de vulnérabilités sur les produits d’une organisation, de les analyser, de coordonner la réponse et de communiquer avec les parties prenantes (chercheurs, clients, autorités).
Le PSIRT est distinct du CERT ou du SOC d’entreprise. Le SOC gère la sécurité de l’infrastructure interne. Le PSIRT gère la sécurité des produits commerciaux vendus à des tiers — c’est une fonction orientée vers l’extérieur.
Analogie : le SOC est la sécurité de votre usine. Le PSIRT est le service qualité produit pour les défauts de sécurité — celui qui reçoit les rappels, analyse les problèmes et communique avec les clients affectés.
- Surveille l’infrastructure de l’organisation
- Répond aux incidents sur les systèmes internes
- Orienté vers la protection des actifs internes
- Interlocuteurs : équipes IT, direction
- Reçoit les signalements sur les produits commerciaux
- Coordonne l’analyse et la correction avec la R&D
- Orienté vers les produits vendus à des clients
- Interlocuteurs : chercheurs, clients, ENISA, autorités
2. Ce que le CRA impose exactement
L’article 13 du CRA impose aux fabricants de mettre en place une politique de divulgation coordonnée des vulnérabilités (CVD — Coordinated Vulnerability Disclosure). En pratique, cela signifie :
- Un canal de signalement public — une adresse email dédiée, un formulaire ou une page web permettant à tout chercheur ou utilisateur de signaler une vulnérabilité de façon sécurisée.
- Un accusé de réception rapide — le CRA ne fixe pas de délai exact, mais les standards du secteur imposent un accusé dans les 72h.
- Un processus d’analyse documenté — chaque signalement doit être évalué, priorisé et traité selon un processus traçable.
- Une communication avec le signalant — le chercheur qui a signalé la vulnérabilité doit être tenu informé de l’avancement jusqu’à la résolution.
- La publication d’un CVE — une fois corrigée, la vulnérabilité doit être documentée et publiée via un identifiant CVE officiel.
Sans canal de signalement public, vous êtes non conforme CRA dès septembre 2026. Un chercheur qui ne trouve pas comment vous contacter de façon responsable peut publier directement sa découverte — sans délai. Le CRA vous impose de rendre ce canal visible et accessible.
3. Le flux de traitement d’un signalement
Voici le processus standard d’un PSIRT conforme CRA, du signalement à la publication :
Corrélation SBOM → CVE automatique, génération de VEX et traçabilité complète des décisions pour chaque signalement — prêt pour l’audit CRA.
4. PSIRT interne ou externalisé
Monter un PSIRT complet en interne demande des ressources : une équipe dédiée, des outils de ticketing sécurisés, un système de gestion des CVE, une infrastructure de communication avec les chercheurs. Pour les grandes entreprises avec un portefeuille de produits conséquent, c’est incontournable.
Pour les PME industrielles ou les éditeurs de taille intermédiaire, plusieurs alternatives existent :
- PSIRT mutualisé via un prestataire spécialisé — des sociétés proposent des services PSIRT externalisés, avec réception des signalements, triage initial et coordination. Le fabricant garde la décision finale et la R&D.
- Plateforme de bug bounty (HackerOne, Intigriti, YesWeHack) — elles fournissent l’infrastructure CVD et la communauté de chercheurs. Adapté si vous cherchez aussi à tester proactivement vos produits.
- Adresse email dédiée + processus documenté — la solution minimale conforme CRA pour les très petites structures. Une adresse `security@votredomaine.com`, un processus interne écrit et un engagement de délai de réponse publié.
Le minimum viable PSIRT pour le CRA : une adresse email de signalement publiée sur votre site, un engagement de réponse sous 72h visible publiquement, un processus interne documenté pour le triage et la correction, et la capacité à publier une CVE et un advisory. C’est suffisant pour une conformité de base — et c’est ce que les autorités vérifieront en premier.
5. La politique de divulgation — ce qu’elle doit contenir
Le CRA impose de publier une politique de divulgation coordonnée des vulnérabilités. Ce document doit préciser :
- Le canal de signalement — adresse email, formulaire, clé PGP si disponible pour les signalements chiffrés
- Le périmètre — quels produits sont couverts, quels types de vulnérabilités sont dans le scope
- Les délais de réponse — accusé de réception, confirmation, résolution cible
- L’accord d’embargo — combien de temps vous demandez au chercheur d’attendre avant de publier (standard : 90 jours)
- La reconnaissance — comment vous créditez les chercheurs qui signalent de bonne foi
- Les règles de safe harbor — engagement de ne pas poursuivre légalement un chercheur agissant de bonne foi dans le périmètre défini
Le safe harbor est crucial : sans clause de protection légale explicite dans votre politique, les chercheurs en sécurité hésiteront à vous signaler des vulnérabilités. La peur de poursuites est le principal frein à la divulgation responsable. Une politique claire et publique rassure la communauté de recherche et vous garantit un flux de signalements plutôt qu’une publication directe.
6. Par où commencer si vous n’avez rien
Quatre étapes pour un PSIRT minimal conforme CRA en moins de 30 jours :
- Semaine 1 — Canal de signalement : créer l’adresse `security@votredomaine.com`, configurer une réponse automatique avec accusé de réception et délai de traitement. Publier l’adresse dans le footer de votre site et dans votre documentation produit.
- Semaine 2 — Politique CVD : rédiger et publier votre politique de divulgation. Des templates existent (CERT/CC, disclose.io) — adaptez-les à votre contexte. Une page dédiée `/security` sur votre site suffit.
- Semaine 3 — Processus interne : documenter qui fait quoi en cas de signalement — triage (qui ?), analyse technique (qui ?), décision (qui ?), communication externe (qui ?). Définir les SLA internes.
- Semaine 4 — Connexion avec le reste : lier le processus PSIRT à votre SBOM et à vos outils CVE. Chaque signalement doit pouvoir être corrélé aux produits et versions affectés en quelques minutes.