PSIRT et divulgation coordonnée des vulnérabilités produit sous CRA

PSIRT et divulgation coordonnée des vulnérabilités produit sous CRA

Un PSIRT (Product Security Incident Response Team) est l’équipe qui traite les vulnérabilités des produits qu’une organisation vend ou distribue : réception du signalement, analyse, correctif, identifiant public, avis. Le sujet est vu ici depuis le siège de l’éditeur ou du fabricant, avec les normes ISO/IEC (Organisation internationale de normalisation et Commission électrotechnique internationale) 29147 et 30111 pour le processus, et le CRA (Cyber Resilience Act, règlement (UE) 2024/2847) pour les délais qui ne se négocient plus.

Explication de la marmotte

Un fabricant de vélos apprend qu’un de ses freins peut lâcher. Soit il fait semblant de ne rien avoir entendu, soit il tient un guichet où l’on vient signaler le défaut, répare, puis prévient tous les cyclistes concernés. Cette page parle de ce guichet, version logiciel : celui qui évite d’apprendre la mauvaise nouvelle par le journal.

→ Lire l’explication complète de la marmotte

PSIRT, CSIRT et normes ISO/IEC 29147 et 30111 : qui répond de quoi

Un CSIRT (Computer Security Incident Response Team) répond aux incidents qui frappent le système d’information de sa propre organisation ; ses missions sont décrites dans la page sur le CSIRT interne. Un PSIRT répond des défauts que l’organisation a livrés chez les autres. L’adversaire, le calendrier et le public ne sont pas les mêmes : le CSIRT contient une intrusion, le PSIRT pilote un correctif et une communication vers des clients qu’il ne connaît pas tous. Côté exploitant, appliquer ces correctifs relève de la gestion des vulnérabilités, pas de cette page.

Deux normes se partagent le terrain, et la répartition mérite d’être retenue parce qu’elle structure l’organisation :

• ISO/IEC 29147:2018 couvre la face externe : recevoir les signalements, dialoguer avec le découvreur, publier les avis.
• ISO/IEC 30111:2019 couvre la face interne : vérifier, analyser, résoudre, préparer la publication.

Le « PSIRT Services Framework » du FIRST (Forum of Incident Response and Security Teams), en version 1.1, complète l’ensemble avec un catalogue de services : gestion de l’écosystème des parties prenantes, découverte, tri et analyse, remédiation, divulgation, formation. La page sur le FIRST situe l’organisme. Les normes disent quoi faire, le cadre du FIRST aide à dimensionner l’équipe.

Le compromis central tient en une ligne : publier vite informe les défenseurs et les attaquants en même temps, publier tard laisse les clients exposés à un défaut que quelqu’un d’autre a peut-être déjà trouvé. La position défendue ici : une date de publication fixée dès le tri, un embargo borné, et l’avis publié le même jour que le correctif. Le correctif silencieux (glissé dans une version mineure sans avis) est la pire des options : l’attaquant compare les binaires, l’exploitant ne priorise rien. L’expérience montre que « personne ne le remarquera » désigne en général tout le monde sauf les clients.

Prérequis : ce qui doit exister avant le premier signalement

Un PSIRT sans fondations est une boîte aux lettres. Avant d’ouvrir le guichet :

• Un inventaire des produits et des versions supportées, avec les dates de fin de support. Sans lui, la question « quelles versions sont touchées » n’a pas de réponse.
• Un SBOM (Software Bill of Materials) par version livrée, archivé avec l’artefact. C’est lui qui permet de savoir en minutes si un composant tiers vulnérable est embarqué ; voir la page sur le SBOM.
• La capacité de reconstruire une ancienne version : chaîne de compilation, dépendances et clés de signature d’époque. Un rétroportage impossible à compiler n’est pas un rétroportage.
• Un canal de mise à jour signé, dont l’intégrité est vérifiable par le client (signature des artefacts).
• Un mandat écrit : le PSIRT doit pouvoir imposer un correctif dans une feuille de route produit. Sans arbitrage en sa faveur, chaque dossier se perd dans un comité de priorisation.
• Un outil de suivi cloisonné, distinct du gestionnaire de tickets que toute l’ingénierie consulte.
• Une politique de divulgation publiée, validée par le juridique, qui engage à ne pas poursuivre la recherche menée de bonne foi dans le périmètre annoncé.

Point d’entrée : politique de divulgation, security.txt et accusé de réception

La politique de divulgation coordonnée dit au découvreur ce qu’il peut tester, comment signaler, quels délais attendre et ce qu’il recevra en retour (un crédit, une prime, ou rien, mais écrit noir sur blanc). Elle s’accompagne d’une adresse dédiée, d’un formulaire en alternative et d’une clé OpenPGP pour chiffrer les détails. Le tout est annoncé par un fichier security.txt, défini par la RFC (Request for Comments) 9116.

L’accusé de réception part vite, par un humain, avec un identifiant de dossier et un interlocuteur nommé. ISO/IEC 29147 pose le principe d’un accusé rapide (de l’ordre de sept jours calendaires) ; viser deux jours ouvrés coûte peu et change tout, car un découvreur sans réponse conclut que personne ne lit et publie. La page sur l’écriture d’un rapport de vulnérabilité décrit l’autre côté du guichet.

Exemple : un security.txt conforme à la RFC 9116

Le fichier se sert en HTTPS (HyperText Transfer Protocol Secure) sous /.well-known/security.txt. Deux champs sont obligatoires : Contact et Expires.

# Servi sur https://www.example.com/.well-known/security.txt
# Contact : obligatoire, plusieurs lignes possibles, par ordre de préférence
Contact: mailto:psirt@example.com
Contact: https://www.example.com/security/report
# Expires : obligatoire, une seule occurrence, moins d'un an recommandé
Expires: 2027-06-30T22:00:00.000Z
# Clé publique pour chiffrer le signalement
Encryption: https://www.example.com/.well-known/psirt-pubkey.asc
# Politique de divulgation coordonnée
Policy: https://www.example.com/security/policy
Preferred-Languages: fr, en
# Emplacement de référence, à vérifier si le fichier est signé
Canonical: https://www.example.com/.well-known/security.txt
# Métadonnées du fournisseur d'avis CSAF
CSAF: https://www.example.com/.well-known/csaf/provider-metadata.json

Deux pièges. Le champ Expires dépassé rend le fichier caduc pour tout outil qui respecte la RFC : la date se supervise comme un certificat. Et un fichier non signé peut être réécrit par quiconque compromet le site vitrine, qui détourne alors les signalements ; la RFC prévoit une signature OpenPGP en clair du fichier, à employer.

Parcours d’un signalement : tri, étendue, correctif et rétroportage

Le schéma se lit de haut en bas : le PSIRT est le seul point de contact du découvreur et le seul à parler aux clients ; les équipes produit ne voient que ce dont elles ont besoin. Deux sigles y apparaissent : CVE (Common Vulnerabilities and Exposures), l’identifiant public d’une vulnérabilité, et CNA (CVE Numbering Authority), l’organisation habilitée à l’attribuer.

Tri et reproduction. Le tri répond à trois questions : est-ce reproductible, est-ce une vulnérabilité (et non un durcissement souhaitable), est-ce dans un produit supporté. La preuve de concept s’exécute en environnement isolé, sans exception.

Analyse de l’étendue. Le défaut signalé sur une version existe souvent depuis bien plus longtemps : il faut remonter à la version qui l’a introduit, puis balayer les autres produits qui partagent le code. Le SBOM répond pour les composants tiers. Si la cause est dans un composant amont, le défaut se signale à son mainteneur ; l’article 13 du CRA en fait d’ailleurs une obligation, correctif éventuel compris. La page sur les dépendances transitives explique pourquoi cette étape réserve des surprises. Corriger la ligne signalée sans chercher les variantes du même défaut garantit un deuxième avis trois semaines plus tard.

Correctif et rétroportage. Le correctif sur la branche principale ne s’applique presque jamais tel quel aux branches anciennes dont le code a divergé : chaque branche maintenue se corrige et se teste séparément. Sur un dépôt public, le commit correctif met fin à l’embargo, quel que soit son intitulé ; comparer deux versions pour en extraire la faille est un exercice de routine. Le correctif se prépare donc dans un dépôt privé et se pousse le jour de l’avis.

Retour d’expérience. Chaque dossier clos alimente le développement : classe de défaut selon la CWE (Common Weakness Enumeration), test de non-régression, règle de revue de code, mise à jour du modèle de menace. Un PSIRT qui ne renvoie rien vers l’amont traite la même faille tous les ans avec un numéro différent.

Identifiant CVE, rôle d’une CNA et score CVSS

Une CNA attribue des identifiants CVE dans un périmètre déclaré (en général ses propres produits) et publie les enregistrements correspondants. Un éditeur qui n’est pas CNA s’adresse à une CNA dont le périmètre le couvre, ou à la CNA de dernier recours, rôle tenu par MITRE. Devenir CNA donne la maîtrise du calendrier et du contenu, au prix d’obligations de publication ; la question se pose quand le volume d’avis devient régulier.

Le piège classique : réserver un identifiant, publier l’avis, puis oublier de publier l’enregistrement CVE. L’identifiant reste à l’état réservé, les scanners des clients n’en savent rien, et l’avis vit seul sur une page que personne n’interroge automatiquement.

Le CVSS (Common Vulnerability Scoring System), maintenu par le FIRST et dont la version 4.0 date de novembre 2023, mesure une gravité, pas un risque. L’éditeur fournit le score de base et surtout le vecteur complet : c’est le vecteur qui permet à l’exploitant d’ajuster selon son contexte. Publier un chiffre sans vecteur revient à donner une température sans préciser l’unité. Et minorer un score pour soigner l’image se voit immédiatement dès qu’un tiers recalcule.

Embargo et coordination multi-parties

L’embargo est la période pendant laquelle l’information reste confinée aux parties qui préparent le correctif. Sa durée se négocie avec le découvreur. Le chiffre de 90 jours circule partout : c’est une convention répandue, pas une norme, et aucun des textes cités ici ne l’impose. La bonne durée dépend de la complexité du correctif, du nombre de branches à rétroporter et de l’existence d’une exploitation en cours, qui raccourcit tout.

Quand le défaut touche un composant partagé, un protocole ou plusieurs éditeurs, un coordinateur tiers devient nécessaire : en France, le CERT-FR joue ce rôle. Trois règles tiennent en production :

• La probabilité de fuite croît avec le nombre de parties informées ; on prévient qui doit corriger, pas qui aimerait savoir.
• Livrer un binaire corrigé à quelques clients « sous embargo » équivaut à publier la faille à quiconque sait comparer deux fichiers.
• Si une exploitation active apparaît pendant l’embargo, on publie des mesures d’atténuation sans attendre le correctif complet.

Avis de sécurité : contenu minimal, format CSAF et déclaration VEX

Un avis exploitable contient au minimum : un identifiant d’avis et sa date, les produits et plages de versions touchés, les versions corrigées, une description de l’impact sans mode d’emploi pour l’attaquant, l’identifiant CVE, le score et le vecteur CVSS, les mesures d’atténuation en attendant la mise à jour, le crédit du découvreur et un historique des révisions. L’annexe I du CRA exige de son côté, une fois la mise à jour disponible, une publication qui décrit la vulnérabilité, permet d’identifier le produit touché, donne l’impact, la gravité et de quoi corriger. Le même point admet, dans des cas dûment justifiés, de retarder cette publication le temps que les utilisateurs appliquent le correctif : une exception à motiver par écrit, pas une habitude.

Le crédit se demande, il ne se devine pas : nom, pseudonyme, organisation ou anonymat, au choix du découvreur. Il ne suppose aucune prime ; sur ce que les programmes de primes changent ou ne changent pas, voir l’éditorial sur le bug bounty.

La version lisible par un humain ne suffit plus. Le CSAF (Common Security Advisory Framework), publié par le consortium OASIS et dont la version 2.0 est un standard depuis 2022, décrit l’avis en JSON (JavaScript Object Notation) : arbre de produits, vulnérabilités, statut par produit, remédiations. Un fichier provider-metadata.json annonce où trouver les avis. La condition de réussite est ingrate : des identifiants de produit stables dans l’arbre, par exemple purl (package URL) ou CPE (Common Platform Enumeration). Sans eux, l’outil du client ne rapproche rien de son inventaire et le format lisible par machine redevient un document à lire.

La déclaration VEX (Vulnerability Exploitability eXchange), disponible comme profil CSAF, répond à la question que posent tous les scanners : ce produit embarque un composant vulnérable, est-il exploitable ? Quatre statuts : touché, non touché, corrigé, en cours d’analyse. Le statut « non touché » exige une justification (code vulnérable absent, non atteignable, non contrôlable par l’adversaire, atténuation déjà intégrée). C’est un engagement : une déclaration erronée conduit les clients à faire taire l’alerte sur une faille exploitable.

CRA : gestion des vulnérabilités de l’annexe I et signalement de l’article 14

Les obligations générales du règlement sont décrites dans la page sur le Cyber Resilience Act. Seule la partie qui concerne le PSIRT est reprise ici.

Annexe I, partie II. Le fabricant doit notamment : identifier et documenter les vulnérabilités et les composants, avec un SBOM dans un format lisible par machine couvrant au moins les dépendances de niveau supérieur ; corriger sans retard, par des mises à jour de sécurité séparées des mises à jour fonctionnelles quand c’est techniquement faisable ; tester régulièrement ; publier l’information sur les vulnérabilités corrigées ; appliquer une politique de divulgation coordonnée ; fournir une adresse de contact ; distribuer les mises à jour de façon sécurisée, sans retard et gratuitement. L’article 13 impose de tenir ce régime pendant toute la période d’assistance (le nom que le règlement donne à la durée de support), qui est d’au moins cinq ans sauf durée d’utilisation prévue plus courte.

Article 14. Une vulnérabilité activement exploitée (des éléments fiables montrent qu’un acteur malveillant l’a utilisée sans l’accord du propriétaire du système) se notifie simultanément au CSIRT désigné comme coordinateur (celui de l’État membre où le fabricant a son établissement principal dans l’Union) et à l’ENISA (Agence de l’Union européenne pour la cybersécurité), par la plateforme unique de signalement de l’article 16. Le schéma donne les trois échéances ; le chronomètre démarre à la prise de connaissance, pas à la confirmation confortable trois réunions plus tard.

Un incident grave ayant un impact sur la sécurité du produit suit un calendrier voisin : alerte précoce sous 24 heures, notification sous 72 heures, rapport final dans le mois qui suit cette notification.

Ces obligations de signalement s’appliquent depuis le 11 septembre 2026, y compris aux produits mis sur le marché avant le 11 décembre 2027 (article 69) ; le reste du règlement s’applique à partir du 11 décembre 2027. L’article 64 plafonne les amendes pour manquement aux obligations des articles 13 et 14 à 15 millions d’euros ou 2,5 % du chiffre d’affaires annuel mondial, le montant le plus élevé étant retenu ; le même article écarte l’amende pour les microentreprises et les petites entreprises lorsque le seul manquement est le dépassement du délai de 24 heures de l’alerte précoce. Suivre ISO/IEC 29147 et 30111 structure le processus mais ne vaut pas, à lui seul, présomption de conformité : l’état des normes harmonisées se vérifie au Journal officiel de l’Union européenne. Savoir si une organisation donnée est dans le périmètre ou en règle se tranche texte en main avec un juriste, pas avec une page de documentation.

Surface d’attaque d’un PSIRT et contre-mesures

Un PSIRT concentre ce qu’un attaquant rêve de lire : la liste des failles non corrigées.

• L’outil de suivi. Sa compromission livre des failles prêtes à l’emploi. Contre-mesures : cloisonnement par dossier, accès limité au besoin d’en connaître, authentification forte, journalisation des consultations.
• La boîte de réception. Elle reçoit par construction du code d’exploitation venu d’inconnus. Les pièces jointes s’ouvrent sur un poste isolé, jamais sur celui qui détient les accès de signature.
• L’usurpation. Un faux avis qui pousse un faux correctif est une attaque de chaîne d’approvisionnement à peu de frais. Contre-mesures : avis signés, emplacement canonique unique, mises à jour signées.
• Les fuites d’embargo. Commits publics, journaux d’intégration continue, notes de version rédigées trop tôt, enregistrement CVE publié avant l’heure. Chaque canal se vérifie avant la date.
• Le bruit. Signalements en double, rapports générés à la chaîne, demandes de prime sans faille : un critère de reproductibilité écrit dans la politique permet de clore sans débat.

Limites du PSIRT : ce qu’il ne garantit pas

Un PSIRT est réactif : il ne trouve pas les failles, il traite celles qu’on lui apporte. La découverte vient des tests, de la revue et de la modélisation des menaces en amont. Il ne fait pas non plus installer les correctifs : un avis parfait sur un parc jamais mis à jour ne protège personne, et cette partie dépend du mécanisme de mise à jour et de l’exploitant. Un identifiant CVE ne dit rien de la qualité de l’analyse, et son absence ne prouve pas l’absence de faille. Enfin, le PSIRT ne couvre ni les exigences de conception du CRA (annexe I, partie I) ni les incidents sur l’infrastructure de l’éditeur, qui restent l’affaire du CSIRT ; une compromission de la chaîne de fabrication mobilise les deux.

Conditions d’exploitation : clés, astreinte, supervision et reprise

Clés. La clé OpenPGP de réception porte une date d’expiration, se partage entre plusieurs membres par sous-clés et se renouvelle avec une transition signée par l’ancienne clé. Une clé détenue par une seule personne part en congés avec elle. La clé de signature des avis se gère comme une clé de signature de code.

Astreinte. Un délai de 24 heures ne connaît ni week-end ni jour férié. Il faut une astreinte capable de qualifier une exploitation active, et au moins deux personnes disposant d’un accès testé à la plateforme de signalement. Découvrir que le compte est verrouillé à la vingt-troisième heure est une expérience dont on se passe.

Supervision. Indicateurs à suivre : délai d’accusé de réception, délai de tri, délai de correctif par niveau de gravité, âge des dossiers ouverts, part des branches maintenues effectivement corrigées, récidive par classe de défaut. S’y ajoutent la date Expires du security.txt et la validité de la clé publiée.

Sauvegarde et reprise. L’outil de suivi se sauvegarde chiffré et se restaure en test. Un canal de secours hors messagerie principale existe pour le jour où celle-ci fait partie du problème. Un exercice annuel sur un dossier fictif vérifie la chaîne entière, du signalement à l’avis.

FAQ

Faut-il devenir CNA pour attribuer ses propres identifiants CVE ?

Non. Une CNA existante dont le périmètre couvre le produit, ou la CNA de dernier recours, attribue l’identifiant sur demande. Devenir CNA se justifie quand les avis sont réguliers et que la maîtrise du calendrier de publication devient un enjeu.

Le délai de 90 jours est-il une obligation ?

Non. C’est une convention répandue chez les chercheurs et quelques grands programmes, pas une exigence d’ISO/IEC 29147 ni du CRA. Le règlement demande de corriger sans retard ; la durée d’embargo se négocie dossier par dossier.

Un petit éditeur a-t-il besoin d’une équipe dédiée ?

Il a besoin des fonctions, pas d’un organigramme. Deux personnes mandatées, une adresse, une politique, un outil cloisonné et une astreinte couvrent le parcours. Ce qui ne se réduit pas : le mandat et les délais de signalement.

🐝 Ce qui arrive si on s’en passe

Sans guichet, le signalement arrive au support, qui le range parmi les demandes d’évolution ; le découvreur, sans réponse, publie les détails avant qu’un correctif existe. Sans analyse d’étendue, la branche principale est corrigée et les branches anciennes, encore vendues, restent ouvertes. Sans identifiant public ni avis structuré, les outils d’inventaire des clients ne remontent rien et la mise à jour passe pour facultative. Sans déclaration sur les composants tiers, le support absorbe une à une les questions de chaque client dont le scanner s’alarme. Et le jour où une exploitation est constatée, l’horloge réglementaire tourne pendant que l’on cherche qui a le droit de décider et qui détient l’accès pour notifier.

🦫 Explication de la marmotte 🍫

Une entreprise qui fabrique un logiciel ou un objet connecté finit toujours par apprendre qu’il contient un défaut de sécurité. Une équipe est chargée de s’en occuper. Elle publie d’abord une adresse et des règles, pour que n’importe qui puisse signaler un défaut sans risquer d’ennuis. Quand un signalement arrive, elle répond vite à son auteur, puis demande aux développeurs de refaire la manipulation pour vérifier que le défaut existe. Elle cherche ensuite toutes les versions et tous les produits touchés, y compris à cause de morceaux de code empruntés à d’autres. Les développeurs écrivent une réparation pour la version récente et pour les anciennes encore suivies. Le défaut reçoit un numéro public mondial et une note de gravité. Tant que la réparation n’est pas prête, l’information reste secrète, pour une durée fixée à l’avance. Le jour dit, l’entreprise publie ensemble la réparation et un avis qui indique quoi installer, sous une forme que des programmes savent lire. La personne qui a trouvé le défaut est remerciée par écrit. Si des pirates utilisent déjà le défaut, la loi européenne oblige à prévenir les autorités en vingt-quatre heures, à donner des détails sous trois jours, puis à remettre un rapport final. Quand une étape échoue, le secret fuit avant la réparation, ou les clients ignorent qu’ils doivent mettre à jour. À la fin, l’équipe explique aux développeurs l’origine de l’erreur pour qu’elle ne revienne pas.

À lire aussi

• Comment lire un rapport OWASP Top 10Lire un rapport de scan OWASP Top 10 sans confondre signal technique, risque exploitable et bruit de détection.
• Images Docker de base et confiance héritéeGérer la généalogie des images de base Docker pour maîtriser la confiance, les vulnérabilités et l'exploitation.
• CERT-EU réponse aux incidents des institutions européennesCERT-EU est le service opérationnel de réponse aux incidents des institutions, organes et agences de l’Union européenne, distinct d’ENISA et d’Europol.
• AI Act : articuler les obligations de sécurité avec NIS 2, le CRA et le RGPDComment le règlement (UE) 2024/1689 sur l'IA s'articule avec NIS 2, le Cyber Resilience Act et le RGPD : qui relève de quoi, quels ponts présument la conformité, ce qu'il faut refaire, comment notifier un incident en parallèle et mutualiser les preuves.

Pages voisines

La citent

• Bug bounty gouvernemental et immunité pénale

PSIRT et divulgation coordonnée des vulnérabilités produit sous CRA

Elle cite

• ⇄Lien dans les deux sens :SBOM pour inventorier les composants réellement exécutés
• ⇄Lien dans les deux sens :Comment écrire un rapport de vulnérabilité corrigé
• ⇄Lien dans les deux sens :Exigences CRA pour produits connectés sécurisés
• ⇄Lien dans les deux sens :Monter un CSIRT interne, missions, services FIRST et rattachement
• ⇄Lien dans les deux sens :Prioriser les vulnérabilités avec CVSS 4.0, EPSS, KEV et exposition
• Comment revoir le code de sécurité au-delà du linter
• Threat modeling STRIDE avant écrire le code
• Maîtriser le risque des dépendances transitives (npm, pip, Maven, Go)
• Signer commits et artefacts contre quelles attaques
• Bug bounty et inégalités structurelles de la chasse aux primes
• CERT-FR alertes et avis de sécurité

⇄ : les deux pages se citent l’une l’autre.