Faire passer un PSIRT à l'échelle : répondre à « Suis-je concerné ? » quand les questions se multiplient

Recruter ne suffira pas à absorber un volume de demandes croissant, et vous ne pourrez pas trier toujours plus vite. Un PSIRT passe à l'échelle en répondant à la plupart des questions « suis-je concerné ? » à partir de données enregistrées lors du build de chaque version, et en publiant la réponse avant que les clients ne la demandent. L'étape coûteuse aujourd'hui consiste à demander à l'équipe d'ingénierie ce que contient un produit. Déplacez cette étape au moment du build, et la plupart des demandes deviennent de simples recherches que le support peut clore.

Cet article suppose que vous disposez déjà d'un PSIRT ; si vous en créez un, commencez par ce qu'est un PSIRT et comment le mettre en place. Ci-dessous : pourquoi le volume a changé, où passe le temps dans le processus habituel, et ce qu'il faut changer, dans l'ordre.

Pourquoi le volume a changé

La hausse est structurelle, pas le fait d'un mauvais trimestre. Quatre facteurs pèsent en même temps sur la même file d'attente.

Plus de CVE. Le programme CVE a publié 39 718 enregistrements CVE en 2024 et 47 801 en 2025. En 2026, le décompte a dépassé le total de toute l'année 2025 bien avant la fin de l'année ; nos tendances de publication des CVE en direct le suivent jour après jour. La mise à jour 2026 des prévisions de vulnérabilités de FIRST (15 juin 2026) a relevé son estimation pour l'année à environ 66 000 CVE et en donne clairement la cause : l'IA peut trouver nettement plus de failles que les analystes humains, et « la contrainte n'est plus la découverte ; c'est la capacité humaine à vérifier, coordonner et corriger ». Un PSIRT est précisément cette capacité humaine.

Les clients scannent votre produit. Les clients passent des scanners sur vos images, vos firmwares et vos appliances et transmettent chaque résultat sous forme de ticket. La plupart de ces résultats sont du bruit de scanner concernant des composants que vous ne livrez pas ou des versions non affectées, et ce bruit devient votre flux entrant. Réduire le bruit des vulnérabilités traite du côté scanner.

La réglementation ajoute des délais. Depuis le 11 septembre 2026, les obligations de signalement du Cyber Resilience Act de l'UE s'appliquent. Une vulnérabilité activement exploitée dans un produit vendu dans l'UE exige une alerte précoce dans les 24 heures suivant la prise de connaissance par le fabricant.

Moins d'aide de la NVD. Le 15 avril 2026, le NIST a fait passer la National Vulnerability Database à un enrichissement fondé sur le risque : les CVE du catalogue KEV de la CISA, les logiciels utilisés par le gouvernement fédéral et les logiciels critiques au sens de l'EO 14028 passent en premier, et les autres sont marquées « Lowest Priority - not scheduled for immediate enrichment ». Moins de CVE arrivent avec des données CPE : la correspondance par nom de produit se dégrade au moment même où le volume augmente.

Facteur	Effet sur la file d'attente du PSIRT
Volume de CVE, découverte assistée par IA	Plus de CVE tierces à évaluer par produit, chaque mois
Scans des clients	Plus de demandes par CVE, souvent sur des composants que vous ne livrez pas
Signalement CRA	Un délai de 24 heures pour les vulnérabilités activement exploitées
Moins d'enrichissement de la NVD	Plus de travail manuel pour relier une CVE aux produits qu'elle affecte

Où passe le temps : le traitement des demandes tel qu'il fonctionne d'habitude

Les équipes de sécurité produit nous décrivent sans cesse le même processus. Un PSIRT de deux personnes chez un fabricant de matériel nous l'a décrit ainsi : un client pose la question au support, le support la transmet au PSIRT via le CRM, le dossier arrive dans l'outil de suivi du PSIRT, le PSIRT examine les produits sur lesquels les clients posent le plus de questions, puis transmet la question à l'ingénierie et attend.

Prenons une demande à titre d'illustration. Un client transmet un rapport de scanner qui liste 40 CVE pour la version X d'un firmware. Le support ouvre un dossier et joint le rapport, mais pas le build exact qu'exécute le client. Le PSIRT vérifie lesquelles des 40 il a déjà évaluées, en trouve une douzaine qu'il n'a pas évaluées, et demande à l'équipe d'ingénierie responsable si les composants se trouvent dans la version X. L'ingénierie doit retrouver les sources de la version X, déterminer quelles versions de dépendances y sont entrées, puis répondre. Les chiffres sont inventés ; le schéma, lui, ne l'est pas.

L'analyse elle-même prend rarement le plus de temps. Deux coûts cachés pèsent davantage :

1. La même CVE est réexaminée pour chaque client qui pose la question. Quand la réponse se trouve dans un fil d'e-mails, le client suivant relance l'analyse depuis le début.
2. « Les produits les plus demandés d'abord » laisse la longue traîne sans réponse. Les produits plus anciens encore en service ne sont jamais vérifiés, et c'est souvent là que se trouve le risque : composants plus anciens, moins de mises à jour, moins de personnes qui se souviennent de la façon dont ils ont été construits.

Entrée : séparer les questions des signalements

Le signalement de vulnérabilité d'un chercheur et la question « suis-je concerné ? » d'un client sont deux tâches différentes, qui demandent deux circuits différents. Le FIRST PSIRT Services Framework s'attend déjà à des entrées hétérogènes : un PSIRT doit « s'attendre à recevoir des vulnérabilités par divers canaux et de qualité variable » (sous-fonction 2.1.1.1). Son domaine de services consacré au tri va plus loin : « Lorsque les organisations reçoivent un volume élevé de signalements de vulnérabilités, elles peuvent envisager d'effectuer un tri initial afin de valider les signalements avant la création des dossiers. » Voyez-y l'autorisation de ne pas ouvrir un dossier PSIRT pour chaque demande.

Répartissez les demandes dès le support en trois circuits :

Le client pose une question sur	Circuit	Qui répond
Une CVE publiée dans un composant tiers que vous avez déjà évalué	Réponse à partir de la déclaration VEX ou de l'avis de sécurité publié ; pas de dossier PSIRT	Le support
Une CVE publiée que vous n'avez pas encore évaluée	Un dossier PSIRT par CVE, et non par client ; chaque demande y est rattachée	Le PSIRT, puis le support répond à tous les demandeurs rattachés
Une nouvelle vulnérabilité dans votre propre code	Un signalement de vulnérabilité : le processus complet de divulgation coordonnée des vulnérabilités	Le PSIRT

Pour traiter le premier circuit, le support a besoin de deux choses : une liste consultable des CVE évaluées par produit et par version, et des modèles de réponse. Comment répondre aux clients après une attaque de la chaîne d'approvisionnement propose des modèles que vous pouvez adapter.

Relevez dès l'entrée le produit et la version exacte qu'exécute le client. Sans la version, toute réponse est « ça dépend », et le dossier revient.

Prioriser selon l'exposition, pas seulement la popularité

« Les produits les plus demandés d'abord » est une heuristique raisonnable. Elle a besoin d'un second axe. Conservez la popularité (base installée, chiffre d'affaires, fréquence des questions du support) et ajoutez l'exposition : le produit est-il toujours pris en charge, est-il exposé à Internet dans les déploiements typiques, et la CVE figure-t-elle dans le catalogue KEV de la CISA ou a-t-elle un score EPSS élevé ? Le guide sur la priorisation des vulnérabilités détaille ces signaux.

	Faible exposition	Forte exposition
Base installée importante	Répondre à partir de l'inventaire ; publier un VEX pour les versions non affectées	Analyser en premier ; avis de sécurité et correctif dans le délai le plus court
Base installée réduite	Répondre à partir de l'inventaire sur demande ; pas de travail proactif	Ne pas l'ignorer : répondre à partir de l'inventaire, puis décider d'un correctif ou d'un avis d'atténuation

L'intérêt de la matrice tient à la colonne de gauche et à la ligne du bas. La longue traîne obtient une réponse issue des données, et non d'une analyse pour laquelle personne n'a le temps.

Au titre du CRA, la période de support que vous avez déclarée pour chaque produit détermine pour quels produits plus anciens vous devez encore des réponses et des mises à jour de sécurité (ce qu'exige le CRA).

La transmission à l'ingénierie est le goulet d'étranglement

Cette section s'adresse au responsable d'ingénierie qui reçoit les escalades du PSIRT.

Les échéances du PSIRT sont publiques : un client, un régulateur ou une date de divulgation attend. Celles de l'ingénierie ne le sont généralement pas, et c'est le PSIRT qui absorbe l'écart. Un problème critique transmis un lundi et toujours sans réponse le mardi ne laisse que deux jours avant l'échéance de la réponse publique.

Le PSIRT pose à l'ingénierie deux questions différentes, et une seule devrait la mobiliser :

• « Le composant est-il dans le produit ? » est une question de données. Elle devrait trouver sa réponse dans un enregistrement, pas chez une personne qui lit des fichiers de build.
• « Pouvez-vous le corriger d'ici la date X ? » est une question de travail. Celle-là relève de l'ingénierie.

Le cadre de FIRST indique comment retirer la première question du bureau de l'ingénierie. La fonction 2.3.5 demande aux PSIRT de « mettre en place des canaux automatisés pour distribuer les notifications de vulnérabilités tierces identifiées directement aux équipes de développement des produits affectés », afin que les avis tiers soient traités dans le processus de développement et que le PSIRT en gère moins à la main.

Convenez de trois choses avec l'ingénierie :

1. Un responsable par produit. Chez les grands fournisseurs, la remédiation est répartie entre les équipes produit ; le modèle distribué du cadre existe parce qu'il permet à la mission du PSIRT de passer à l'échelle grâce aux ingénieurs responsables des produits.
2. Des objectifs de réponse par gravité, mis par écrit, pour le correctif plutôt que pour l'analyse.
3. Ce qui se passe quand un objectif n'est pas tenu. La fonction 4.2.4 demande « un processus d'acceptation formelle du risque pour toute vulnérabilité non corrigée dans les délais des SLA internes ». Une personne habilitée signe l'acceptation du risque ; le dossier ne reste pas simplement ouvert.

Le rythme des correctifs varie. Une équipe livre un patch du jour au lendemain, une autre a besoin d'une mise à niveau de plateforme de six mois. L'avis de sécurité doit dire de quel cas il s'agit, pour que les clients puissent s'organiser.

Faire de « sommes-nous concernés ? » une simple recherche : une SBOM pour chaque version livrée

C'est le changement qui supprime le plus de travail. La fonction 2.3.1 de FIRST, l'inventaire des composants de produits, le juge « essentiel pour identifier rapidement les produits affectés par des vulnérabilités héritées ». Les niveaux de maturité d'un PSIRT placent un registre de produits avec cartographie des dépendances au niveau intermédiaire, et la surveillance des vulnérabilités des composants de produits au niveau avancé.

Un inventaire ne supprime du travail que s'il tient face au volume. Chaque exigence ci-dessous a sa raison d'être :

• Une SBOM par version livrée, et non par dépôt ni pour la branche par défaut. Les clients exécutent des versions, pas des branches.
• Issue du build qui a produit la release. Un nouveau build ultérieur, ou un scan du dépôt actuel, décrit un autre logiciel (SBOM au moment du build).
• Dépendances transitives et cachées incluses. Le paquet vulnérable est rarement un paquet que vous avez ajouté vous-même (dépendances transitives), et les scripts d'installation, les images de base et les caches restaurés apportent des composants qu'aucun lockfile ne liste.
• Un indicateur de complétude. Un enregistrement partiel traité comme complet produit des réponses « non affecté » assurées, mais fausses.
• Conservée aussi longtemps que la version est prise en charge. L'enregistrement d'une version d'il y a trois ans est celui dont vous aurez besoin quand plus personne ne se souviendra de la façon dont elle a été construite.
• Des SBOM fournisseurs pour les composants achetés, afin que les logiciels tiers figurent dans le même inventaire que les vôtres.
• Une nouvelle correspondance en continu à mesure que de nouvelles CVE sont publiées, au lieu d'un nouveau scan quand quelqu'un pose la question.

Un exemple concret. Une nouvelle CVE est publiée dans une bibliothèque de compression très répandue. Sans l'inventaire, le PSIRT interroge chaque équipe produit, les réponses arrivent au compte-gouttes pendant des jours, et les produits les plus anciens ne sont jamais vérifiés. Avec lui, une seule requête renvoie les produits et versions affectés, ainsi que le premier et le dernier build qui contenaient la version vulnérable. C'est la fenêtre d'exposition que les clients demandent ensuite ; sommes-nous concernés par une CVE ? montre comment l'établir pour un cas donné.

Les portefeuilles embarqués et Yocto sont les plus difficiles. Les scanners qui lisent une image firmware finie doivent deviner ce qui y a été compilé, et des équipes avec lesquelles nous échangeons ont vu des preuves de concept de scanners échouer sur des produits basés sur Yocto. Enregistrer le build pendant son exécution évite de deviner (builds Yocto sur CRACI).

Lorsqu'un client demande ensuite la SBOM elle-même, dans un format particulier, consultez répondre aux demandes de SBOM des clients.

Côté sortie : des avis de sécurité et des VEX qui répondent avant qu'on ne pose la question

La demande la moins coûteuse est celle qui n'arrive jamais.

• Publiez les « non affecté » sous forme de VEX, pour que les scanners des clients cessent de signaler la CVE, et publiez les « affecté » et « corrigé » sous forme d'avis de sécurité avec les versions exactes.
• Rendez-les lisibles par machine. La sous-fonction 5.3.2.3 de FIRST suggère aux PSIRT d'« envisager de publier les avis dans un format lisible par machine tel que le Common Security Advisory Framework (CSAF) », afin que les clients puissent les exploiter avec leurs propres outils. Le guide CSAF explique comment passer des pages web et des flux RSS à CSAF.
• Informez le support avant de publier. Fonction 5.3.4 : « Fournir à l'avance une notification confidentielle et une FAQ sur les avis à venir prépare ceux qui pourraient être interrogés à leur sujet lors de la publication. » Le support peut alors répondre le jour même.
• Diffusez, ne vous contentez pas de publier. La sous-fonction 5.4.1.3 note qu'un faible nombre de consultations des avis « peut orienter votre stratégie vers une notification proactive ». Les flux et les notifications atteignent les clients qui ne visitent jamais une page d'avis.

Le CRA fait d'une partie de ce travail une obligation. L'article 14, paragraphe 8, impose au fabricant, après avoir pris connaissance d'une vulnérabilité activement exploitée ou d'un incident grave, d'en informer les utilisateurs touchés « et, le cas échéant, tous les utilisateurs », et de le faire « le cas échéant, dans un format structuré, lisible par machine et facilement traitable automatiquement ». Le règlement ne désigne aucun format.

Quoi automatiser, dans l'ordre

Chaque étape supprime un type de travail ; la métrique montre si c'est bien le cas.

Étape	Travail supprimé	Métrique qui montre que cela fonctionne
1. Un inventaire par version issu du build	La question « qu'y a-t-il dedans ? » posée à l'ingénierie	Le nombre de demandes d'analyse à l'ingénierie par mois baisse
2. La correspondance continue des nouvelles CVE avec chaque version prise en charge	Les nouveaux scans à la demande	Le délai entre la publication de la CVE et une décision affecté ou non affecté
3. Un dossier par CVE, avec les demandes rattachées	Les analyses en double	Les demandes par dossier augmentent, les dossiers par CVE restent à un
4. L'acheminement automatique des résultats affectés vers l'équipe responsable (FIRST 2.3.5)	Les transmissions manuelles	Le délai entre la décision et sa prise en compte par un responsable
5. Une bibliothèque consultable des déclarations VEX et avis de sécurité publiés	L'intervention du PSIRT sur les questions récurrentes	La part des demandes closes par le support
6. La publication lisible par machine (CSAF)	Les clients qui demandent ce que leurs outils auraient pu récupérer	Les demandes par avis de sécurité publié baissent
7. L'assistance de l'IA pour rédiger les avis et les réponses	Le temps de rédaction	Le délai entre la décision et la publication de l'avis

L'IA arrive en dernier pour une raison. Elle rédige bien à partir de données enregistrées, et elle ne devrait jamais être la source de la décision « affecté ».

Certaines choses ne devraient pas être automatisées : le jugement « non affecté » et l'évaluation de la gravité restent entre les mains d'une personne, preuves à l'appui. L'automatisation détermine la vitesse à laquelle cette personne obtient les preuves.

Les métriques qui montrent que le PSIRT passe à l'échelle

• La part des demandes traitées sans dossier PSIRT.
• Le délai entre la publication d'une CVE et une décision affecté ou non affecté, par produit.
• Le nombre de demandes d'analyse à l'ingénierie par mois. Il devrait baisser.
• Le taux de remédiation dans les délais par gravité ; la sous-fonction 4.4.2.4 du cadre le définit comme la capacité des équipes produit à respecter le délai convenu entre le signalement et le correctif.
• La couverture VEX et avis de sécurité des versions que vous prenez encore en charge.

Nous ne citons pas de références sectorielles pour ces métriques. Aucune source primaire en laquelle nous avons confiance n'en publie.

La place de CRACI

CRACI couvre les étapes 1 et 2, ainsi qu'une partie des étapes 4 et 5, pour les logiciels construits dans GitHub Actions. Vos builds s'exécutent sur les runners de CRACI, et CRACI enregistre ce que chaque job a réellement récupéré pendant son exécution : dépendances directes et transitives, paquets installés par des scripts et paquets restaurés depuis les caches CI. La SBOM de chaque job porte un état de complétude, afin qu'un enregistrement partiel ne soit jamais pris pour un enregistrement complet.

CRACI conserve l'historique des builds : quand une nouvelle CVE est publiée, vous voyez quels builds contenaient la dépendance vulnérable, et depuis quand, aussi loin que remonte votre conservation. Les SBOM surveillées sont réévaluées en continu, les résultats sont agrégés entre builds et dépôts, et des SBOM fournisseurs peuvent être ajoutées pour que les composants achetés soient surveillés aux côtés de vos propres builds. CRACI informe les personnes concernées d'une nouvelle vulnérabilité et de sa gravité. La vue d'inventaire montre quelles versions logicielles sont déployées sur quels produits, et les équipes de sécurité trient chaque résultat dans CRACI et le transmettent à l'équipe responsable de la correction. CRACI prend en charge VEX. Consultez CRACI pour les PSIRT et le suivi des vulnérabilités.

Voyez lesquelles de vos versions livrées contiennent une CVE.

Quand CRACI n'est pas la réponse

• Votre goulet d'étranglement est l'entrée et la gestion des dossiers, la partie qui va du CRM à l'outil de suivi. CRACI n'est pas un outil de gestion de dossiers ni de publication d'avis de sécurité ; il vous faut un outil de gestion de dossiers pour cette moitié (comparatif des outils PSIRT).
• Vos produits ne sont pas construits dans GitHub Actions sur des runners Linux. GitHub Actions est la CI prise en charge aujourd'hui ; GitLab CI et Jenkins sont sur la roadmap, sans date.
• Vous avez besoin d'une analyse de binaires ou de firmwares de produits que vous n'avez pas construits vous-même. C'est le rôle des outils d'analyse du produit fini (comparatif des outils de sécurité embarquée).
• Vous avez besoin d'une analyse d'atteignabilité pour justifier un « non affecté ». CRACI ne la propose pas.

Questions fréquentes

Comment faire passer un PSIRT à l'échelle sans recruter ?

Cessez d'analyser encore et encore la même question. Enregistrez ce que contient chaque version livrée au moment de son build, comparez-y en continu les nouvelles CVE, décidez une fois par CVE et publiez la décision sous forme de VEX ou d'avis de sécurité vers lequel le support peut renvoyer. Le PSIRT traite alors les dossiers réellement ouverts, et l'ingénierie est sollicitée pour corriger, pas pour enquêter.

Comment un PSIRT doit-il traiter les demandes « sommes-nous concernés ? » des clients ?

Traitez-les comme un flux d'entrée distinct des signalements de vulnérabilités. Le support répond aux questions sur les CVE que vous avez déjà évaluées à partir des éléments publiés. Une CVE que vous n'avez pas encore évaluée donne lieu à un seul dossier PSIRT, auquel chaque demande client est rattachée. Seule une nouvelle vulnérabilité dans votre propre code suit le processus complet de divulgation.

Que dit le FIRST PSIRT Services Framework sur le volume et l'automatisation ?

Il s'attend à des signalements « par divers canaux et de qualité variable », autorise un tri avant la création des dossiers quand le volume est élevé, juge un inventaire des composants de produits « essentiel pour identifier rapidement les produits affectés », et demande des canaux automatisés qui transmettent les notifications de vulnérabilités tierces directement aux équipes de développement des produits affectés (fonction 2.3.5).

Que doit automatiser un PSIRT en premier ?

L'inventaire par version issu du build, puis la correspondance continue des nouvelles CVE avec chaque version prise en charge. Ces deux étapes suppriment le plus de travail répétitif : la question « qu'y a-t-il dedans ? » posée à l'ingénierie et le nouveau scan à la demande. La déduplication des dossiers, l'acheminement, une bibliothèque consultable de VEX et d'avis de sécurité, et la publication CSAF viennent ensuite.

Comment obtenir de l'ingénierie qu'elle réponde à temps aux questions du PSIRT ?

Posez moins de questions à l'ingénierie. Répondez à « le composant est-il dans le produit ? » à partir de l'enregistrement du build, et ne posez à l'ingénierie que la question « pouvez-vous le corriger d'ici cette date ? ». Convenez d'un responsable par produit, d'objectifs de réponse par gravité pour le correctif, et d'une acceptation formelle du risque quand un objectif n'est pas tenu.

Pourquoi une SBOM par release est-elle importante pour un PSIRT ?

Les clients exécutent des versions précises, souvent anciennes. Une SBOM de la branche par défaut ne dit rien de la version X d'il y a deux ans. Une SBOM par version livrée, enregistrée à partir du build qui l'a produite et conservée pendant la période de support, est ce qui permet à un PSIRT de répondre pour chaque version encore en service, fenêtre d'exposition comprise.

Les clients veulent-ils des VEX ou des avis de sécurité ?

Les deux, pour des statuts différents. Le VEX indique aux scanners des clients quelles CVE n'affectent pas un produit, et les résultats cessent. Les avis de sécurité indiquent aux personnes ce qui est affecté, ce qui est corrigé et ce qu'il faut faire. Publier les deux, sous forme lisible par machine lorsque c'est possible, répond à la plupart des questions avant qu'elles ne soient posées.