Comment réduire le bruit dans la gestion des vulnérabilités

D'où vient le bruit des vulnérabilités

Prenez un backlog et triez-le selon l'origine de chaque résultat. Les chiffres ci-dessous sont illustratifs, pas un benchmark, mais les catégories sont celles que les équipes trouvent lorsqu'elles échantillonnent leur propre backlog.

Origine du résultat	Sur 1 000 résultats (illustratif)	Étape qui l'élimine
Composants que vous ne livrez pas : entrées de lockfile et de manifeste, couches de build, outils de développement et de test	300	1. Fiabiliser l'inventaire
La même CVE signalée par plusieurs outils, ou une fois par dépôt	250	2. Compter chaque résultat une seule fois
Correspondances erronées : collisions de noms CPE, backports des distributions	80	1. Fiabiliser l'inventaire
Résultats réels non exploitables dans votre produit	150	4. Ajouter le contexte d'exploitabilité
Résultats réels sans correctif disponible	70	5. Une décision de politique avec une date d'expiration
Résultats sans responsable	50	5. Attribuer à un responsable
Reste à classer et à corriger	100	Priorisation

Une distinction simplifie la suite de cette page. Certains de ces résultats sont des faux positifs : le résultat est faux, parce que le composant n'est pas présent ou que la version n'est pas affectée. D'autres relèvent du bruit : le résultat est juste, mais ne change rien à ce que vous ferez cette semaine. Ils appellent des réponses différentes, et les confondre conduit les équipes à masquer de vrais résultats ou à débattre de résultats faux.

Faux positif : le résultat est faux	Bruit : juste, mais pas urgent
Le composant ne fait pas partie de ce que vous livrez	Le code vulnérable ne peut pas être atteint ni déclenché dans votre produit
La correspondance est erronée : une collision CPE, ou un correctif rétroporté que le numéro de version masque	Aucun correctif n'existe encore, ou le produit est interne et non exposé
Se corrige en rectifiant l'inventaire et le rapprochement	Se corrige avec du contexte, une décision consignée et un responsable

Étape 1. Faire correspondre l'inventaire à ce que vous livrez

C'est le levier le plus important, car chaque étape suivante multiplie les erreurs de l'inventaire. Un composant listé mais jamais livré produit un résultat dans chaque scanner, chaque dépôt et chaque release.

• Enregistrer à partir du build. Construisez l'inventaire à partir de ce que le build de release a réellement utilisé, pas à partir des manifestes ou d'un scan de l'artefact final. Une SBOM générée au build contient ce que le job a récupéré, y compris ce qu'aucun lockfile ne liste.
• Identifier les composants par PURL. Une package URL comme pkg:npm/[email protected] désigne précisément l'écosystème, le paquet et la version. Le rapprochement avec des avis indexés par PURL, comme les avis des écosystèmes dans OSV, élimine les correspondances erronées qui viennent d'un CPE deviné à partir d'un nom de produit.
• Utiliser un rapprochement propre à la distribution pour les paquets système. Debian et d'autres distributions rétroportent les correctifs de sécurité sur la version qu'elles ont livrée au lieu de la mettre à niveau : le numéro de version peut donc sembler antérieur au correctif amont. Rapprochez avec le suivi de sécurité de la distribution elle-même, pas avec les plages de versions amont.
• Suivre la complétude. Sachez quand l'inventaire n'a pas pu voir quelque chose, plutôt que de supposer qu'il est complet. Un composant manquant est pire qu'un composant bruyant : il ne produit aucun résultat.

Exemple concret. Le lockfile d'un service Node.js inclut [email protected], une bibliothèque de correspondance de motifs glob dont dépendent des outils de test et de build. Un scan du lockfile signale CVE-2024-4067, un déni de service par expression régulière corrigé en 4.0.8. Le job de release installe uniquement les dépendances de production, avec npm ci --omit=dev : micromatch n'entre donc jamais dans le build livré. Un enregistrement de ce build ne le contient pas, et le résultat n'atteint jamais le backlog. La CVE est réelle ; pour ce produit, le résultat est un faux positif.

Étape 2. Compter chaque résultat une seule fois

La même CVE arrive de l'outil SCA, du scanner de conteneurs et de la plateforme SBOM, puis encore une fois pour chaque dépôt qui utilise la bibliothèque. Dédoublonnez sur une seule clé : package URL, version et CVE. Par exemple, pkg:npm/[email protected] avec CVE-2024-45296 constitue un seul résultat, quel que soit le nombre d'outils qui le signalent.

• Comptez un résultat par artefact livré, pas un par scanner.
• Agrégez entre builds et dépôts, pour que la CVE d'une bibliothèque partagée soit une seule décision appliquée partout, pas quarante tickets.
• Regroupez les scanners qui se recoupent. Une règle simple : les résultats sur les dépendances viennent d'une seule source SCA ou SBOM, ceux sur les images d'un seul scanner de conteneurs, ceux sur votre propre code d'un seul outil SAST. Si deux outils signalent le même signal, gardez celui qui est le plus proche de ce qui est livré (SAST ou SCA).

Étape 3. Livrer moins

Chaque dépendance que vous ne livrez pas est une source de résultats que vous n'aurez jamais à traiter.

• Supprimez les dépendances inutilisées. La plupart des projets traînent quelques paquets que plus rien n'importe.
• Mettez à niveau le paquet qui embarque les paquets vulnérables. Express 4.19.2 fige [email protected] et [email protected], qui portent CVE-2024-45590 et CVE-2024-45296. Vous ne pouvez pas les mettre à jour isolément sans overrides. Express 4.20.0, publié en septembre 2024, dépend des versions corrigées : une seule mise à niveau élimine les deux (dépendances transitives).
• Utilisez des images de base minimales. Les images slim et distroless contiennent moins de paquets système, donc moins d'avis s'y appliquent. Le scan de conteneurs couvre les leviers propres aux images.
• Épinglez et mettez à jour délibérément. Les lockfiles et les digests stabilisent l'inventaire d'un build à l'autre.
• Bloquez les builds qui contiennent une version connue comme vulnérable. Une policy gate qui arrête le build écarte une bibliothèque vulnérable avant qu'elle ne devienne un résultat que quelqu'un devra trier.

example-service
└─ [email protected]          → upgrade to 4.20.0
   ├─ [email protected]    CVE-2024-45590
   └─ [email protected]  CVE-2024-45296

Étape 4. Ajouter le contexte d'exploitabilité

Ce qui reste après les étapes 1 à 3 est réel. Le contexte détermine ce qui est urgent.

• VEX. Consignez « non concerné » une seule fois, avec une justification, sous forme de déclaration VEX, et réutilisez-la d'une release et d'un client à l'autre. Lorsque des clients vous transmettent leurs propres analyses de votre produit, ces mêmes enregistrements leur répondent : consultez faire passer un PSIRT à l'échelle et, pour des modèles de réponse, comment répondre aux clients après une attaque de la chaîne d'approvisionnement.
• L'atteignabilité, lorsque vos outils la proposent, montre si votre code peut appeler la fonction vulnérable. Elle aide, dans certaines limites (analyse d'atteignabilité).
• Les signaux d'exploitation. CISA KEV indique qu'une vulnérabilité est exploitée en conditions réelles ; EPSS estime la probabilité d'exploitation dans les 30 prochains jours.
• L'exposition. Un produit exposé sur Internet passe avant un outil interne sur un réseau privé.

Étape 5. Attribuer les résultats à un responsable, avec une politique

• Écrivez les seuils sous forme de politique. Fixez les seuils de sévérité et d'exploitabilité par produit ou par dépôt dans une politique, pas dans un filtre de tableau de bord qu'une seule personne a appliqué.
• Désignez des responsables par dépôt ou par équipe, pour que chaque résultat ait quelqu'un qui décide.
• Tranchez explicitement les cas « aucun correctif disponible » : accepter avec une date d'expiration, atténuer, ou remplacer le composant. Un résultat sans correctif ne doit pas rester ouvert sans décision.

Les développeurs ignorent les résultats pour quatre raisons : pas de responsable, pas de contexte, pas d'échéance, ou le mauvais canal. Des équipes avec qui nous échangeons racontent que l'ingénierie a désactivé des scanners parce que leur sortie était trop bruyante pour être lue. Traitez chaque raison : un responsable par dépôt, le contexte de l'étape 4 joint, une échéance fixée par la politique, et une diffusion là où l'équipe travaille déjà.

Réduire le bruit ou masquer le risque

Un backlog plus petit n'est meilleur que s'il a diminué pour les bonnes raisons.

• Une suppression sans raison ni date d'expiration est une dette cachée. Elle ressurgit lors d'un audit ou d'un incident, quand plus personne ne se souvient pourquoi.
• Les seuils de sévérité masquent les résultats faux au lieu de les éliminer. « Rien en dessous de CVSS 7 » fait disparaître un faux positif à CVSS 6 et en laisse un autre à CVSS 9.
• Chaque décision de ne pas corriger doit être consignée. Les clients le demandent, tout comme des réglementations telles que le Cyber Resilience Act de l'UE, qui attend des fabricants qu'ils gèrent les vulnérabilités pendant toute la période de support d'un produit.

Comment le mesurer

• Les résultats par release livrée, pas par scan.
• La part des résultats traités : corrigés, atténués ou tranchés.
• Les résultats clos comme non concernés avec une déclaration VEX, face à ceux supprimés sans.
• Le délai entre le build et le responsable : combien de temps un nouveau résultat attend avant que quelqu'un le prenne en charge.
• Le taux de doublons entre outils.

Un échantillon de 50 résultats à analyser en un après-midi. Choisissez 50 résultats ouverts au hasard. Pour chacun, notez si le composant est livré dans la release, si un autre outil ou dépôt signale le même résultat, si la correspondance est juste, s'il est exploitable dans votre produit, si un correctif existe et qui en est responsable. Les totaux vous indiquent par quelle étape commencer. Refaites le même échantillon un trimestre plus tard. Nous ne citons pas de benchmarks sectoriels pour ces chiffres, car aucune source primaire n'en étaye.

La place de CRACI

CRACI intervient sur les étapes 1 et 2, sur la gate de build de l'étape 3 et sur une partie des étapes 4 et 5, pour les logiciels construits dans GitHub Actions.

• L'inventaire. CRACI remplace vos runners hébergés par GitHub et enregistre les paquets que chaque job a réellement récupérés, avec un PURL par composant et un état de complétude par SBOM. Chaque composant d'une SBOM CRACI était dans le build. Cette exactitude porte sur les composants de la SBOM ; une CVE rapprochée peut tout de même ne pas affecter votre produit. C'est le rôle de VEX, et CRACI prend en charge VEX.
• Un résultat, de nombreux builds. Les résultats sont agrégés entre builds et dépôts, et les SBOM surveillées sont réévaluées en continu à mesure que de nouvelles vulnérabilités sont publiées.
• Gates. Les policy gates peuvent arrêter un build en temps réel en fonction des résultats, y compris un build qui contient une CVE précise.
• Tri et attribution. Les équipes de sécurité trient les résultats dans CRACI et transmettent chacun à l'équipe responsable de la correction.
• Notifications. CRACI informe les personnes concernées d'une vulnérabilité et de sa sévérité.

CRACI ne propose pas d'analyse d'atteignabilité, de SAST ni de tableaux de bord MTTR. Consultez le suivi des vulnérabilités pour la fonctionnalité complète, ou voyez ce que contiennent réellement vos builds.

Quand CRACI n'est pas la bonne réponse

• L'essentiel de votre bruit vient de résultats SAST dans votre propre code. C'est un problème de réglage du SAST.
• Votre backlog est surtout composé de résultats réels et exploitables dans le code livré. C'est un problème de capacité de remédiation, pas un problème de bruit.
• Vous avez besoin du contexte d'exécution des workloads de production. Un CNAPP ou un outil de sécurité runtime répond à ce besoin.

Pour le plan d'ensemble, consultez ce qu'il faut automatiser quand le nombre de CVE ne cesse d'augmenter, et les chiffres en direct des tendances de publication des CVE.

Réduire le bruit des vulnérabilités : questions fréquentes

Comment réduire le nombre d'alertes de vulnérabilités ?

Coupez-les à la source, dans l'ordre : faites correspondre l'inventaire à ce que vous livrez, dédoublonnez les résultats par package URL, version et CVE, livrez moins de dépendances, ajoutez le contexte d'exploitabilité comme VEX, KEV et EPSS, et attribuez ce qui reste à un responsable selon une politique écrite. Priorisez ensuite.

Pourquoi notre scanner signale-t-il des milliers de vulnérabilités, et lesquelles comptent ?

Généralement parce qu'il signale des composants que vous ne livrez pas, rapporte la même CVE une fois par outil et par dépôt, et se trompe sur certaines correspondances. Celles qui comptent touchent des composants que votre release contient réellement, sont exploitables dans votre produit, et sont exploitées ou susceptibles de l'être.

Comment dédoublonner les résultats de plusieurs outils de sécurité ?

Indexez chaque résultat sur la package URL, la version et la CVE, et comptez un résultat par artefact livré. Agrégez entre dépôts pour qu'une bibliothèque partagée corresponde à une seule décision. Confiez ensuite chaque type de signal à un seul outil, pour que deux scanners cessent de signaler la même chose.

Faut-il supprimer les vulnérabilités sans correctif ?

Pas en silence. Prenez une décision explicite : accepter le risque avec une raison écrite et une date d'expiration, l'atténuer, ou remplacer le composant. Réexaminez-la lorsqu'un correctif paraît. Une suppression sans raison ni date d'expiration est une dette cachée.

Une vulnérabilité que personne n'a corrigée depuis un an est-elle encore du bruit ?

Pas forcément. L'ancienneté ne dit rien du risque. Si elle est livrée et exploitable, elle exige une décision et un responsable. Si elle n'affecte pas votre produit, consignez-le dans une déclaration VEX pour qu'elle cesse de revenir. Dans tous les cas, elle ne doit pas rester ouverte sans décision.

Comment éviter que les développeurs ignorent les résultats de sécurité ?

Donnez à chaque résultat un responsable, le contexte pour agir, une échéance issue d'une politique écrite, et diffusez-le là où l'équipe travaille déjà. Éliminez d'abord le bruit : les développeurs cessent de lire un canal où la plupart des résultats ne comptent pas.

Quel est un bon nombre de vulnérabilités ouvertes ?

Il n'existe pas de benchmark fiable, et le total brut n'est pas la bonne mesure. Suivez les résultats par release livrée, la part traitée, la part close avec une raison consignée, et la durée pendant laquelle les vulnérabilités connues comme exploitées restent ouvertes dans les logiciels livrés.