TL;DR — Éditeurs, les vulnérabilités de vos produits sont inévitables — mais ne pas les traiter, les ignorer ou refuser de les formaliser (CVE) ne l’est pas. Entre divulgation responsable, exigences CRA/NIS2 et attentes clients, vous avez tout intérêt à reprendre la main : corriger vite, communiquer clairement et standardiser votre gestion des failles. À défaut, d’autres le feront à votre place — et rarement à votre avantage.
Transformer une contrainte en levier !
Dans un précédent article (cf. Quand les failles viennent de l’éditeur, le RSSI a des armes juridiques), nous donnions des éléments aux RSSI pour se défendre face à des éditeurs parfois peu enclins à assumer leurs responsabilités en matière de sécurité.
Aujourd’hui, nous proposons de renverser la perspective.
Car la réalité terrain est plus nuancée : les éditeurs ne sont pas seulement une source de risque. Ils sont aussi — et surtout — un maillon clé de la chaîne de sécurité. Et lorsqu’une vulnérabilité est découverte dans un produit, ils sont les plus à même de pouvoir corriger le problème à la source.
Encore faut-il qu’ils disposent des bons réflexes, des bons outils… et du bon cadre.
Cet article s’adresse aux éditeurs de logiciels, avec un objectif clair : transformer une contrainte (la vulnérabilité) en levier de crédibilité, de conformité et de maturité.
Quand la vulnérabilité vient du produit
Dans le cadre de nos activités en cybersécurité, nous adoptons une approche offensive et pragmatique visant à identifier des vulnérabilités exploitables dans des conditions réelles pour nos clients.
À travers nos travaux d’audit, de pentest ou de Bug Bounty, nous analysons des environnements variés. Et un constat revient régulièrement :
Une part non négligeable des vulnérabilités identifiées ne provient pas d’une mauvaise configuration… mais directement des logiciels utilisés.
Autrement dit : le problème est parfois structurel, et ne peut être corrigé que par l’éditeur lui-même.
Dans ce contexte, la collaboration entre chercheurs, RSSI et éditeurs devient inévitable.
Divulgation responsable : une opportunité, pas une menace
Lorsqu’une vulnérabilité est identifiée, une démarche de divulgation responsable est généralement engagée.
Concrètement, cela signifie que l’éditeur reçoit gracieusement :
- une description détaillée de la vulnérabilité ;
- des éléments techniques permettant sa reproduction ;
- un proof of concept ;
- et des recommandations de correction.
L’objectif est simple :
- corriger efficacement ;
- éviter une exploitation malveillante ;
- améliorer durablement la sécurité du produit à sa source.
Contrairement à une perception encore répandue, cette démarche n’est pas une mise en cause publique. C’est une opportunité.
Une opportunité de corriger avant exposition. Une opportunité de démontrer sa maturité. Une opportunité de collaborer avec l’écosystème sécurité.
Le nouveau cadre réglementaire change la donne
Les choses évoluent rapidement côté réglementation et viennent profondément modifier les attentes vis-à-vis des éditeurs. Notamment au travers des textes comme :
- le Cyber Resilience Act (CRA) (Règlement UE 2024/2847),
- la directive NIS2,
- ou encore DORA pour le secteur financier,
Ces réglementations imposent notamment :
- une prise en compte de la sécurité dès la conception (security by design) ;
- une gestion active des vulnérabilités ;
- une capacité à corriger et notifier rapidement ;
- une traçabilité des failles et des correctifs.
Ignorer une remontée de vulnérabilité n’est plus seulement un risque technique ; cela devient potentiellement un risque juridique, réglementaire et un risque réputationnel majeur.
Le CRA est entré en vigueur le 10 décembre 2024. Les obligations de signalement des vulnérabilités s’appliqueront à partir du 11 septembre 2026. L’ensemble des exigences sera pleinement obligatoire le 11 décembre 2027.
CVE : parler un langage commun
Une CVE (Common Vulnerabilities and Exposures) est un identifiant unique attribué à une vulnérabilité. Format type : CVE-2025-12345.
Derrière cet identifiant, on retrouve :
- une description de la vulnérabilité ;
- les versions affectées ;
- l’impact ;
- et les références vers les correctifs.
Les CVE sont utilisées mondialement par les éditeurs, les RSSI, les CSIRT/CERT, les outils de sécurité (scanners, SIEM, etc.). Elles alimentent notamment des bases comme le NVD.
Sans CVE, une vulnérabilité existe… mais elle reste difficile à suivre, à prioriser et à corriger à grande échelle.
Pourquoi les éditeurs ont tout intérêt à déclarer des CVE ?
Trop souvent, la déclaration de CVE est perçue comme risquée : “publier une faille, c’est exposer une faiblesse”.
En réalité, c’est l’inverse.
1. Renforcer la confiance
Déclarer une CVE montre que l’éditeur :
- prend la sécurité au sérieux ;
- agit de manière transparente ;
- adopte une posture professionnelle.
C’est un signal fort envoyé aux clients et partenaires.
2. Garder le contrôle de la communication
Si l’éditeur ne déclare pas la vulnérabilité :
- un chercheur peut le faire ;
- ou un tiers peut publier sans coordination.
Résultat :
- perte de contrôle du calendrier ;
- description potentiellement inexacte ;
- impact réputationnel amplifié.
Déclarer soi-même, c’est maîtriser le narratif.
3. Structurer la gestion des vulnérabilités
Une CVE permet de :
- référencer précisément une faille ;
- l’associer à un correctif ;
- suivre son cycle de vie.
C’est un élément clé d’un processus de Secure Software Development Lifecycle (SSDLC).
4. Faciliter la vie des clients
Avec une CVE :
- les clients peuvent suivre automatiquement les vulnérabilités ;
- les outils de sécurité peuvent les détecter ;
- les équipes IT peuvent prioriser les correctifs.
Moins d’opacité = moins de friction avec les clients.
5. S’aligner avec les exigences réglementaires
Dans un contexte CRA / NIS2 :
- la traçabilité des vulnérabilités devient essentielle ;
- la transparence est valorisée ;
- la gestion proactive est attendue.
La CVE devient un outil de conformité.
6. Encourager la divulgation responsable
Un éditeur ouvert à la déclaration de CVE :
- incite les chercheurs à signaler proprement ;
- réduit le risque de divulgation sauvage ;
- construit une relation de confiance avec l’écosystème.
Ne pas traiter une vulnérabilité : un risque sous-estimé
À l’inverse, ignorer ou minimiser une remontée peut entraîner :
- une divulgation publique non maîtrisée ;
- une exploitation active avant correction ;
- une perte de confiance des clients ;
- une mise en cause contractuelle ;
- voire des sanctions réglementaires à terme.
Dans le contexte actuel, ne rien faire est souvent plus risqué que de publier.
Bonnes pratiques côté éditeur
Face à une remontée de vulnérabilité, quelques réflexes clés :
1. Accuser réception rapidement
Même sans solution immédiate, montrer que le sujet est pris en compte.
2. Qualifier la vulnérabilité
- reproductibilité ;
- impact ;
- périmètre concerné.
3. Définir une stratégie de correction
- correctif ;
- mitigation temporaire si nécessaire.
4. Coordonner la divulgation
- aligner publication du correctif et de la CVE ;
- communiquer auprès des clients.
5. Déclarer une CVE
Que ce soit via MITRE ou une CNA (ex : CERT-FR / ANSSI).
6. Capitaliser
- améliorer les process internes ;
- intégrer les enseignements dans le cycle de développement.
Exemple de démarche de déclaration de CVE
Pour soumettre une demande de CVE en tant qu’éditeur pour chacune des vulnérabilités remontées, se rendre au formulaire suivant (ou auprès d’une autre CNA tel que le CERT-FR / ANSSI) :
Exemple de demande de CVE :
# Demande de CVE
## Informations générales
- **Organisation déclarante** : [Nom de l’entreprise ou de l’équipe]
- **Nom du produit** : [Nom exact du logiciel ou composant]
- **Versions affectées** : [Liste ou intervalle des versions concernées]
- **Date de découverte** : [JJ/MM/AAAA]
- **Date de publication prévue** : [JJ/MM/AAAA]
- **Date de correctif (le cas échéant)** : [JJ/MM/AAAA]
- **Page de sécurité de l’éditeur** (si existante) : [URL]
## Détail de la vulnérabilité
- **Type de vulnérabilité** : [ex. : Injection SQL, Cross-Site Scripting, Buffer Overflow]
- **Score CVSS estimé** : [Ex. : 7.8 - Haute gravité] (optionnel)
- **Composant affecté** : [Fichier ou fonction précise, ex : /api/login.php]
- **Vector d’attaque** : [Local, réseau, authentifié/non-authentifié, etc.]
### Description technique
> Une vulnérabilité a été identifiée dans [produit], versions [versions].
> Le problème réside dans [explication technique, cause, impact].
> Cela permet à un attaquant [conséquences : exécuter du code, exfiltrer des données, etc.].
> Le correctif consiste en [solution technique appliquée, ex. : ajout de filtres, requêtes préparées].
### Étapes de reproduction (Proof of Concept)
1. [Étape 1 – contexte initial]
2. [Étape 2 – action de l’attaquant]
3. [Résultat attendu – preuve de la faille]
## Informations sur la correction
- **Correctif disponible** : Oui / Non
- **Version corrigée** : [version]
- **Notes de version / changelog** : [lien si disponible]
- **Mesures de mitigation possibles** : [si pas de correctif]
## Demande de réservation de CVE
Nous sollicitons la **réservation d’un identifiant CVE** pour cette vulnérabilité, dans le cadre d'une divulgation responsable, coordonnée avec la publication du correctif prévue le [date].
## Crédits
> Cette vulnérabilité a été découverte par L’Équipe BZHunt
> Organisation (si applicable) : BZHunt
> Contact (email ou lien vers page publique) : https://bzhunt.fr
> Nous remercions les chercheurs pour leur collaboration responsable.
## Contact de l’éditeur
- **Nom du responsable sécurité** : [Nom]
- **Email** : [adresse email sécurité]
- **PGP (facultatif)** : [clé publique ou lien]
Conclusion : reprendre la main
Les vulnérabilités ne sont pas une anomalie ; elles sont une réalité inhérente au développement logiciel.
La différence ne se fait pas sur leur existence… mais sur la manière dont elles sont gérées.
Un éditeur qui écoute les remontées, corrige rapidement, communique de manière transparente, et déclare ses CVE, ne s’expose pas. Il se distingue.
Dans un contexte où les exigences réglementaires et les attentes clients ne cessent d’augmenter, la gestion des vulnérabilités devient un avantage concurrentiel.
À condition de jouer le jeu.
Chez BZHunt, nous accompagnons les éditeurs et les organisations dans l’identification, la compréhension et la remédiation des vulnérabilités, dans une logique pragmatique et responsable. Toute vulnérabilité identifiée impactant un produit et identifiée au cours d’un audit d’un client final — qu’il soit propriétaire ou open source — fait systématiquement l’objet d’un security advisory (anonymisé) et du déclenchement d’une procédure de responsible disclosure auprès de l’éditeur concerné.