Failles on BZHunt

Éditeurs : comment passer d’une faille à une CVE (sans y laisser votre réputation) ?

Tue, 07 Apr 2026 16:21:30 +0200

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é.

Pentests LAN : quand les failles viennent de l'éditeur, le RSSI a des armes juridiques

Tue, 20 Jan 2026 18:09:52 +0100

TL;DR Cet article s’inscrit dans la continuité de nos travaux avec Me Marc-Antoine Ledieu sur le droit de pentester l’hébergeur du pentesté. Nous transposons ici le raisonnement juridique aux éditeurs de logiciels dont les produits, déployés dans le LAN de nos clients, introduisent des vulnérabilités structurelles.

Le constat qui revient à chaque mission

Chez BZHunt, nous réalisons des pentests d’infrastructures internes pour des entreprises de toutes tailles et de tous secteurs. Et le constat est récurrent, presque systématique : une part significative des vulnérabilités critiques que nous identifions ne provient pas d’erreurs de configuration du client, mais de défauts structurels introduits par les logiciels déployés dans son LAN.