Le piège du faux positif

Un exemple concret

Reprenons la liste du module 3. L'agent signale une CVE critique sur un paquet présent dans pnpm-lock.yaml. En creusant, on découvre que ce paquet n'est en réalité qu'une dépendance transitive d'un outil de build (un bundler, un linter) — il n'est jamais importé ni exécuté par le code applicatif, et encore moins en production.

L'agent n'a pas menti : la CVE existe, le paquet est bien présent. Mais sa conclusion implicite — "ce projet est exposé" — est fausse.

Pourquoi c'est un vrai piège

Ce type de faux positif est particulièrement trompeur parce qu'il a l'air sérieux : sévérité "critical", paquet bien réel, CVE documentée. Rien à première vue ne le distingue d'un vrai problème urgent.

Le coût n'est pas nul pour autant :

• Du temps perdu sur un correctif qui ne change rien au risque réel.
• Une vraie urgence retardée pendant qu'on traite le faux positif.
• De la confiance érodée dans l'agent, si ça se reproduit trop souvent sans méthode pour le repérer.

Ce qu'il faut en retenir

La présence d'un paquet vulnérable dans le lockfile n'est qu'un signal de départ, pas une conclusion. Reste à savoir si ce code est réellement exécuté, dans un contexte qui nous expose — c'est ce que le module suivant apprend à vérifier, méthodiquement.