04/05/2026
Cybersecurity Insights
PSIRT : l’arme (souvent) manquante pour être « CRA ready »
Alors que le Cyber Resilience Act entre dans sa phase d’application, celui-ci intègre une nouvelle obligation inédite et dimensionnante pour les éditeurs : devoir détecter, analyser et traiter les vulnérabilités qui surviendraient sur leurs produits numériques. Cette obligation de « maîtriser le cycle de vulnérabilités » des produits va transformer l’industrie numérique européenne.
Derrière les débats sur les niveaux d’assurance, les exemptions ou les délais, ce sujet demeure sous-estimé. Les fabricants de produits numériques devront structurer le suivi et le traitement de ces vulnérabilités, la solution la plus efficace étant via la mise en place d’un véritable PSIRT — Product Security Incident Response Team.
Un changement de paradigme imposé par le CRA
Dans son annexe I[1], le CRA intègre cette nouvelle obligation sous la forme de 8 exigences de sécurité essentielles. Celles-ci imposent, entre autres, aux éditeurs de devoir :
- détecter (au travers de campagnes de tests), analyser et qualifier les vulnérabilités qui impacteraient le produit ou ses dépendances
- y répondre « sans retard », notamment en diffusant des mises à jour
- partager ces vulnérabilités, leur description et leur impact, par exemple via des CVE
De nombreuses entreprises traitent ces vulnérabilités de manière décentralisée, générant des délais ou traitements incomplets :
- des développeurs corrigeant les sujets sans les documenter
- des équipes R&D sans process de détection et de suivi
- un RSSI sans information à centraliser
- une incapacité à agréger des preuves de conformité
- une difficulté à dialoguer avec les auditeurs techniques
Ces obligations imposent donc d’aller plus loin qu’une simple pipeline de patch management et de release des nouvelles versions. Cela impose un processus industrialisé, documenté et coordonné, géré par une équipe centrale capable d’interagir avec l’ensemble des acteurs internes. La réponse à ces vulnérabilités est pilotée de bout en bout et peut être synchronisée avec les acteurs externes (utilisateurs et CERT nationaux).
Le PSIRT apparaît donc comme l’interlocuteur technique légitime pour occuper ce rôle.
[1] https://eur-lex.europa.eu/legal-content/FR/TXT/HTML/?uri=OJ:L_202402847#anx_I
Pourquoi un PSIRT structuré devient indispensable
Les équipes de CERT/CSIRT ont longtemps été considérées uniquement comme des outils de gestion de crise cyber. Or le CRA ne vise pas la cybersécurité du SI de l’éditeur : il met sous contrainte réglementaire la sécurité du produit lui-même, tout au long de son cycle de vie. C’est exactement le territoire du PSIRT (Product Security Incident Response Team).
- L’industrialisation de la gestion des vulnérabilités
Le CRA fixe un horizon clair : corriger les vulnérabilités dans des délais proportionnés et démontrables et communiquer autour de celles-ci. Sans workflow clair, sans identification préalable des acteurs et sans coordination avec la supply chain logicielle, il est presque impossible de tenir la cadence.
En dehors des exigences du CRA, un PSIRT outillé facilitera :
- l’étude préalable de l’applicabilité de chaque vulnérabilité
- la priorisation des correctifs basée sur l’impact réel de chacune
- la publication de bulletins de sécurité
- la coordination avec la R&D pour rechercher des vulnérabilités du même type dans la codebase et tenter de les détecter automatiquement au cours du développement, par exemple via la CI/CD
En complément, le PSIRT sera le point d’entrée unique de l’ensemble des remontées de vulnérabilités sur les produits de l’entité. Qu’elles proviennent de chercheurs indépendants, de bug bounty ou d’audits programmés, chaque faiblesse sera adressée dans un processus commun, objectivé et maîtrisé.
- La relation avec l’écosystème : CERT, ENISA, clients, distributeurs
A la suite de la correction des vulnérabilités et de la mise à jour, le CRA instaure un schéma de notification qui se rapproche des pratiques en vigueur dans les équipes SOC « classiques ».
Un PSIRT mature pourra donc :
- dialoguer avec les CERT nationaux
- gérer la divulgation coordonnée de la vulnérabilités aux utilisateurs
- coordonner la diffusion des patchs avant la publication des bulletins de CVE
- maintenir une posture de transparence maîtrisée et être le point de contact unique
- Un avantage stratégique et concurrentielle, « hors-CRA »
À court terme, le PSIRT va devenir un élément de différenciation dans les réponses aux appels d’offres. Acheter des produits robustes et incassables n’est plus qu’un rêve illusoire. Des vulnérabilités existeront sur tous les produits, qu’ils soient édités par des groupes mondiaux ou des start-ups.
Chaque éditeur devra donc désormais démontrer sa capacité à les traiter efficacement.
Tout comme elles sont utilisées pour comparer des SOC, les clients — en particulier dans les secteurs régulés — demanderont prochainement aux éditeurs des métriques permettant de démontrer la maturité de leur process de gestion des vulnérabilités, leur délai moyen de correction, ou encore leur capacité à fournir des bulletins de sécurité structurés.
Le CRA agit aujourd’hui comme un catalyseur : il normalise les attentes prochaines des acheteurs et permet aux éditeurs motivés de prendre de l’avance sur leurs concurrents
Comment un PSIRT peut sécuriser la trajectoire vers la conformité au CRA
Voici quelques leviers concrets pour démarrer la mise en place d’un PSIRT efficace.
- Construire une taxonomie commune
Le PSIRT devient l’endroit où vont converger :
- l’inventaire des dépendances logicielles (SBOM)
- les politiques internes de divulgation
- les contacts sécurité des clients et autorités
- les matrices d’estimation du risque
Toutes ces informations permettent de mettre en place le monitoring nécessaire et dresser le processus de traitement des vulnérabilités.
- Définir des SLA internes réalistes mais opposables
Pour chaque étape du process, le PSIRT pourra définir avec l’équipe SSI les SLA de traitement des différents niveaux de vulnérabilités. Il est évident qu’une vulnérabilité de score CVSS 9.0 doit être traitée avec plus d’importance qu’une vulnérabilité avec moins d’impact.
Le PSIRT sera également en charge de centraliser ces temps de traitement et de capitaliser des KPI opposables, dans différents objectifs : améliorer les process, revoir les méthodes de traitement et prouver le bon respect des exigences du CRA.
- Recentrer le sujet sur l’ingénierie produit
Bien qu’imposé réglementairement, le CRA n’est pas et ne doit pas être traité comme un simple projet de mise en conformité. Son objectif initial est de renforcer la sécurité des produits pour en réduire le nombre de vulnérabilités.
La mise en place d’un PSIRT ancre donc la sécurité à toutes les étapes du cycle de vie des produits :
- dans le pipeline de développement
- dans la conception du produit
- au moment des arbitrages techniques
La conformité réglementaire devient donc un « effet collatéral » positif d’une démarche d’intégration globale de la sécurité dans la gestion des produits.
- Préparer l’éditeur à la certification EUCC (pour ceux qui la viseront)
La logique de mettre en place un processus de gestion continue des vulnérabilités, la prise en compte formelle des risques liés à celles-ci, la capacité à produire des preuves… Tout cela prépare naturellement un futur passage du produit dans une évaluation formalisée par un CESTI.
Bien que n’étant pas une exigence formelle des schémas de certifications, la mise en place d’un PSIRT formalisé et documenté facilitera, pour les éditeurs qui le souhaitent, l’obtention de leurs certifications cyber. Plus généralement, cela permettra facilement de prouver sa conformité au CRA, pour tous les types de produits et d’évaluation (qu’elles soient internes ou externes).
Ce qui est en place chez les éditeurs les plus avancés
Sans citer de noms, les acteurs les plus matures du marché ont déjà mis en place un certain nombre d’actions de coordination de vulnérabilités :
- surveillance des publications de CVE
- étude de chaque vulnérabilité, avec scoring appliqué au contexte d’usage du produit
- processus industrialisé de coordination de la correction à la publication
- alignement des actions de détection sur les pratiques des laboratoires d’évaluation
- rapprochement avec des équipes d’ingénierie de la cybersécurité applicative (analyse statique, fuzzing, hardening)
On retrouve souvent, dans ces organisations, une culture de rigueur héritée des évaluations CESTI ou de projets sensibles, combinée aux méthodes d’automatisation et d’industrialisation en place dans les SOC (systèmes de ticketing, alertes, mécanismes d’escalade en cas de découverte critique, etc.).
Dans certains cas, les PSIRT peuvent se transformer en Centres Opérationnels de gestion des Vulnérabilités (VOC, Vulnerability Operation Center).
En conclusion, le PSIRT, un pivot discret mais décisif du CRA
Le CRA va créer un avant/après pour les éditeurs de produits numériques, quels qu’ils soient.
Ceux qui réussiront ne seront pas forcément ceux qui patchent le plus vite, mais ceux qui sauront démontrer — preuves à l’appui — la maîtrise complète de la sécurité de leurs produits. Pas seulement une obligation réglementaire, le PSIRT permettra de combiner les deux, pour allier un processus structuré au service de la rapidité de traitement des vulnérabilités :
- identification plus large en amont
- rigueur dans l’analyse
- industrialisation du traitement correctif
- traçabilité des actions
- dialogue avec les tiers
- articulation avec les pratiques d’évaluation
Il ne s’agit pas simplement d’une nouvelle case à cocher dans un tableau de bord réglementaire. Il s’agit d’une fonction stratégique, indispensable à tout fabricant qui veut aborder le CRA sans naïveté, se donner les moyens de traiter efficacement la sécurité de ses produits et, surtout, préparer dès aujourd’hui un futur où la sécurité des produits sera évaluée avec les mêmes exigences que la sécurité des infrastructures critiques.
