Atteignabilité : le code vulnérable est-il utilisé ?

Beaucoup de vulnérabilités dorment dans du code que votre produit n’utilise jamais. L’étape CI de Provetry, provetry reach, cherche des preuves dans un sens ou dans l’autre et envoie des suggestions ; rien n’est décidé sans votre clic.

Ce qu’elle peut dire

• Appelée par votre code (Go avec govulncheck, et les langages ci-dessous) : la fonction vulnérable est atteinte. La vulnérabilité remonte.
• Appel trouvé dans votre code (npm et PyPI) : une analyse des appels trouve où votre code appelle une fonction qui mène au code corrigé, avec le fichier et la ligne. La vulnérabilité remonte.
• Chargée par votre code (tous les langages) : le paquet vulnérable est importé, avec le fichier et la ligne. À ce niveau, on ne sait pas si la fonction vulnérable elle-même est appelée.
• Jamais chargée ou jamais appelée : proposée non concernée, avec l’explication de l’outil comme preuve. Acceptez les suggestions une par une, ou toutes d’un coup.

Pour Rust, le niveau fonction vient des fonctions que nomme RustSec. Pour npm et PyPI, avec les offres Pro et Consultant, votre CI reçoit aussi les fonctions publiques qui mènent au code corrigé de chaque faille, pour distinguer « chargée » d’« appelée ».

Quand votre code nomme l’une de ces fonctions, une analyse des appels cherche ensuite l’appel lui-même, à travers les alias et les imports : Jelly (un analyseur de graphe d’appels de l’université d’Aarhus) pour JavaScript et TypeScript, une lecture des imports et des appels de chaque fichier pour Python. Elle ne fait qu’ajouter une preuve : ces analyses ratent certains appels (une fonction passée en rappel, une réexportation), donc un appel qu’elle ne trouve pas ne change rien. En CI, Jelly tourne avec npx ; provetry reach --no-calls le désactive.

Pour Java (Maven), les mêmes données donnent les méthodes publiques qui mènent au code corrigé. Mais les bibliothèques Java se trouvent aussi entre elles à l’exécution (chargeurs de services, fichiers de fournisseurs, auto-configuration) : un « jamais appelé » demande donc deux conditions de plus. La bibliothèque doit être une dépendance directe de votre projet, et votre build doit écrire son SBOM CycloneDX, qui donne le graphe complet des dépendances. Ajoutez le plugin CycloneDX au build avant que provetry reach ne s’exécute : mvn org.cyclonedx:cyclonedx-maven-plugin:makeAggregateBom (il écrit target/bom.json), ou le plugin Gradle org.cyclonedx.bom (build/reports/). Sans lui, Java en reste au niveau paquet.

La règle

Chaque doute compte comme un usage. Un import dynamique, une macro, une méthode qu’un framework appelle par son nom : l’outil ne conclut alors rien. Et le pipeline n’échoue que sur des appels prouvés, jamais sur des suggestions.