Le cycle de vie de la gestion des vulnérabilités pour les éditeurs de logiciels

Qu'est-ce que le cycle de vie de la gestion des vulnérabilités ?

Le cycle de vie de la gestion des vulnérabilités est le processus reproductible que suit un éditeur de produits pour traiter une vulnérabilité dans un logiciel qu'il livre : la recevoir ou la trouver, la vérifier, déterminer ce qui est touché, la corriger, publier le correctif et informer les clients. Chez un éditeur, il est généralement piloté par une équipe de réponse aux incidents de sécurité produit (PSIRT), les équipes d'ingénierie réalisant les corrections.

Cette page couvre le côté éditeur. La gestion des vulnérabilités IT, qui consiste à scanner et à corriger les serveurs et les ordinateurs portables d'une organisation, partage le vocabulaire mais pas les parties difficiles. Un éditeur doit répondre de chaque release prise en charge entre les mains de ses clients, et doit publier ce qu'il a trouvé.

Les étapes du cycle de vie

1. Recevoir ou découvrir. Les vulnérabilités arrivent de chercheurs externes via votre programme de divulgation, de clients, de coordinateurs tels que les CSIRT nationaux, et de votre propre surveillance : une nouvelle CVE dans une dépendance open source, un résultat de scanner ou un test interne. Consignez chacune avec un identifiant de suivi et accusez réception auprès des auteurs de signalements externes.
2. Vérifier et trier. Reproduisez le problème ou confirmez la correspondance avec la dépendance, déterminez s'il s'agit d'une vulnérabilité de votre produit, et évaluez sa sévérité et son urgence. Clôturez ce qui ne s'applique pas, avec un motif que vous pourrez présenter plus tard. Des signaux de priorisation tels qu'EPSS et le catalogue CISA KEV aident à classer ce qui reste.
3. Évaluer les produits et versions concernés. Trouvez chaque produit, release et branche prise en charge qui contient le code ou le composant vulnérable, ainsi que chaque déploiement client qui en exécute un. Cette étape détermine la portée du correctif et de l'avis de sécurité.
4. Remédier. L'équipe responsable développe et teste un correctif : une dépendance mise à niveau, une modification du code ou une atténuation, comme un changement de configuration, lorsqu'un correctif n'est pas encore possible.
5. Publier le correctif. Livrez des versions mises à jour pour chaque branche prise en charge concernée, par un canal auquel les clients peuvent se fier.
6. Informer et divulguer. Publiez un avis de sécurité qui indique ce qui est touché, la sévérité et ce qu'il faut faire, attribuez ou citez un identifiant CVE et mentionnez l'auteur du signalement. Des formats lisibles par machine tels que CSAF et VEX permettent aux clients de traiter automatiquement les avis.
7. Surveiller et apprendre. Guettez les exploitations et les nouvelles informations, mettez à jour l'avis et réinjectez la cause racine dans le développement, pour que la même catégorie de faille ne soit plus livrée.

ISO/IEC 30111 et ISO/IEC 29147

Deux normes internationales décrivent ce cycle de vie pour les éditeurs. Elles le séparent à la frontière de l'organisation :

	ISO/IEC 30111:2019	ISO/IEC 29147:2018
Titre	Vulnerability handling processes	Vulnerability disclosure
Couvre	Ce qui se passe à l'intérieur : vérifier, enquêter, prioriser et remédier	Les interfaces : recevoir les signalements et publier les avis
Contenu clé	Politique et organisation, responsabilités du PSIRT, phases de traitement, considérations liées à la chaîne d'approvisionnement	Rôles des parties prenantes, traitement des signalements, contenu des avis, coordination, politique de divulgation
Public	Les éditeurs qui traitent des vulnérabilités signalées	Les éditeurs qui reçoivent des signalements et divulguent des vulnérabilités

Ces normes sont conçues pour être utilisées ensemble. ISO/IEC 30111 nomme six phases de traitement : préparation, réception, vérification, développement de la remédiation, publication et post-publication. Elle demande aussi un suivi du processus, la confidentialité des informations sur les vulnérabilités et une attention portée à la chaîne d'approvisionnement, car de nombreuses vulnérabilités se trouvent dans des composants que vous n'avez pas écrits. Les deux normes sont des éditions en vigueur, confirmées lors de leurs dernières revues ISO, et leur révision est prévue.

D'autres cadres suivent la même logique. Le FIRST PSIRT Services Framework regroupe le travail en découverte des vulnérabilités, tri et analyse, remédiation et divulgation, et IEC 62443-4-1 inclut la gestion des mises à jour de sécurité et des défauts dans son cycle de développement sécurisé pour les produits industriels.

Les rôles

• PSIRT ou équipe de sécurité produit : responsable du processus, reçoit les signalements, trie, coordonne les corrections et publie les avis. Voir CRACI pour les équipes PSIRT et ce qui distingue un PSIRT d'un CSIRT.
• Équipes produit et ingénierie : responsables du code, développent et testent les corrections et livrent les releases.
• Gestion des releases : décide quelles branches prises en charge reçoivent un correctif, et quand.
• Support client et communication : gèrent les questions des clients et les destinataires de l'avis.
• Juridique : conseille sur la divulgation, les contrats et les notifications réglementaires.
• Parties externes : auteurs de signalements, coordinateurs tels que le CERT/CC ou un CSIRT national, mainteneurs en amont des composants concernés et clients qui doivent déployer le correctif.

Délais et SLA

Il n'existe pas de délai unique imposé. La plupart des éditeurs fixent des objectifs internes selon la sévérité et publient les délais externes dans leur politique de divulgation. Une structure typique :

• Accuser réception d'un signalement externe en quelques jours ouvrés.
• Trier en quelques jours, pour que l'auteur du signalement et l'équipe responsable sachent où en est le dossier.
• Remédier dans un délai fixé selon la sévérité et l'exploitation, le plus court pour les résultats critiques et tout ce qui est connu pour être exploité.
• Divulguer lorsque le correctif est disponible, ou à une date convenue si le correctif prend du retard.

La pression extérieure fixe la limite. Les chercheurs fixent souvent une date limite de divulgation (Google Project Zero donne 90 jours aux éditeurs), et la réglementation ajoute les siennes : le Cyber Resilience Act de l'UE impose aux fabricants de corriger les vulnérabilités « sans délai » et fixe des délais de signalement pour celles qui sont activement exploitées (voir ce qu'exige le CRA). Lorsqu'une vulnérabilité est déjà exploitée, comme une zero-day, chaque étape se déroule dans le délai le plus court.

Là où le cycle de vie se grippe

La plupart des retards ne viennent pas de l'écriture du correctif. Ils viennent du fait de ne pas savoir ce que vous avez livré.

• Ne pas savoir quelles releases contiennent un composant. Une nouvelle CVE touche une bibliothèque. Lesquelles des releases de l'an dernier l'incluent, et quels clients les exécutent ? Sans enregistrement par release, les équipes reconstruisent d'anciens tags ou fouillent les dépôts à la main, et la liste des versions touchées dans l'avis est une supposition.
• Les dépendances transitives. De nombreux paquets vulnérables ne sont pas des paquets que vous avez choisis. Ils arrivent comme dépendances transitives plusieurs niveaux plus bas : une recherche dans vos manifestes passe donc à côté.
• Le bruit des dépendances de développement. Les scanners qui lisent les lockfiles signalent des frameworks de test et des outils de build qui ne sont jamais livrés. Chacun coûte du temps de tri et enfouit les résultats qui comptent.
• Les composants hors du gestionnaire de paquets. Les binaires téléchargés par les scripts de build, les images de base et les composants de fournisseurs n'apparaissent dans aucun lockfile.
• Une responsabilité floue. Un résultat qu'aucune équipe ne prend en charge attend. Le tri n'est terminé que lorsque le correctif a un responsable.
• Les corrections qui ne tiennent pas. Une version vulnérable revient par une autre dépendance ou une ancienne branche, car rien ne l'empêche d'entrer dans le prochain build.

Les indicateurs

Indicateur	Ce qu'il montre
Délai d'accusé de réception	Si les auteurs de signalements obtiennent une réponse dans le délai promis par votre politique
Délai de tri	Combien de temps un résultat attend avant que quelqu'un sache s'il compte
Délai de remédiation, par sévérité	La vitesse de livraison des corrections, de la réception à une release disponible
Délai de publication de l'avis	Combien de temps les clients attendent l'information après le correctif
Part respectant les objectifs	Si les SLA internes sont tenus, en particulier pour les résultats critiques et exploités
Backlog par ancienneté	Les résultats bloqués, et à quel endroit
Taux de résultats non concernés	La part de l'effort de tri consacrée à des résultats qui ne s'appliquent pas

Mesurez chaque étape séparément. Un long délai de remédiation s'avère souvent être un long délai pour trouver les releases touchées.

Pilotez le cycle de vie à partir d'un enregistrement de ce que vous avez livré

Chaque étape après le tri dépend de la connaissance du contenu de chaque release. CRACI exécute vos builds GitHub Actions sur ses propres runners et enregistre les paquets que chaque job a réellement récupérés, y compris les dépendances transitives, les paquets restaurés depuis les caches CI et les dépendances qu'aucun lockfile ne liste. Chaque SBOM porte un état de complétude et s'exporte en CycloneDX ou SPDX.

CRACI réévalue en continu les SBOM surveillées et les agrège sur l'ensemble des builds et des dépôts, et des SBOM de fournisseurs peuvent être ajoutées pour que les composants achetés soient surveillés aux côtés des vôtres. Lorsqu'une nouvelle CVE apparaît, l'historique des builds montre quels builds passés contenaient la dépendance vulnérable, directe ou transitive : vous connaissez ainsi la période pendant laquelle vous avez été touchés, et la vue d'inventaire montre quelles versions du logiciel sont déployées sur quels produits. Les équipes sécurité trient les résultats dans CRACI et les envoient aux équipes chargées de la correction, CRACI prend en charge VEX, et les gates de politique peuvent bloquer les builds qui contiennent une CVE précise, pour qu'une vulnérabilité corrigée reste à l'écart. Voir le suivi des vulnérabilités.

Cycle de vie de la gestion des vulnérabilités : questions fréquentes

Quelles sont les étapes du cycle de vie de la gestion des vulnérabilités ?

Pour un éditeur de produits : recevoir ou découvrir la vulnérabilité, la vérifier et la trier, trouver les produits et versions concernés, développer la remédiation, publier le correctif, publier l'avis de sécurité, puis surveiller et apprendre. ISO/IEC 30111 nomme les phases préparation, réception, vérification, développement de la remédiation, publication et post-publication.

Qu'est-ce qu'ISO/IEC 30111 ?

ISO/IEC 30111:2019 est la norme internationale sur les processus de traitement des vulnérabilités. Elle donne aux éditeurs des exigences et des recommandations pour traiter et corriger les vulnérabilités signalées dans leurs produits et services, de la politique et du rôle du PSIRT aux phases de traitement et aux considérations liées à la chaîne d'approvisionnement.

Quelle est la différence entre ISO/IEC 30111 et ISO/IEC 29147 ?

ISO/IEC 29147 couvre la partie tournée vers l'extérieur : recevoir les signalements et publier les avis. ISO/IEC 30111 couvre le traitement interne entre les deux : vérifier, enquêter, prioriser et corriger. Les deux sont conçues pour être utilisées ensemble. Voir la divulgation coordonnée des vulnérabilités pour le volet 29147.

Qu'est-ce que le tri des vulnérabilités ?

Le tri est l'étape où une équipe de sécurité confirme qu'une vulnérabilité signalée ou découverte est réelle, évalue sa sévérité et son urgence pour votre produit et l'envoie à l'équipe chargée de la correction. Un bon tri clôture aussi les résultats qui ne s'appliquent pas, avec un motif consigné.

Quelle est la différence entre la gestion des vulnérabilités produit et la gestion des vulnérabilités IT ?

La gestion des vulnérabilités IT corrige les systèmes qu'une organisation exploite. La gestion des vulnérabilités produit traite les failles des logiciels que l'organisation construit et livre à d'autres : elle ajoute donc des étapes que les équipes IT n'ont pas, comme déterminer quelles versions publiées sont touchées, livrer un correctif aux clients et les en informer dans un avis de sécurité.

Quels indicateurs un processus de traitement des vulnérabilités doit-il suivre ?

Le délai d'accusé de réception d'un signalement, le délai de tri, le délai de remédiation et le délai de publication de l'avis, chacun par sévérité, ainsi que la part des résultats qui respectent vos objectifs internes, le backlog ouvert par ancienneté et le nombre de résultats clôturés comme non concernés.