Atteignabilité
Beaucoup d’alertes sur vos dépendances concernent du code que votre produit n’exécute jamais. Provetry vous montre lesquelles, preuves à l’appui.
Avec le Cyber Resilience Act, chaque vulnérabilité connue d’une version maintenue demande une évaluation. Les évaluer une à une, en lisant le code, c’est là que le temps passe. Provetry cherche des preuves dans un sens comme dans l’autre, dans votre propre CI, et vous donne la réponse avec sa preuve.
Trois réponses, chacune avec sa preuve
Jamais chargé
Le paquet vulnérable est dans votre fichier de verrouillage, mais aucun chemin n’y mène depuis votre code. Provetry donne la chaîne qui l’amène, et propose « non concerné : le composant n’est jamais chargé ».
Chargé, jamais appelé
Votre code charge le paquet, mais ne nomme jamais les fonctions qui mènent au code vulnérable. Provetry liste ces fonctions, et propose « non concerné : le code vulnérable n’est jamais exécuté ».
Appelé
Votre code atteint le code vulnérable : la vulnérabilité remonte dans la liste, avec le fichier et la ligne. Si vous le souhaitez, votre pipeline échoue dessus.
Ce que vous voyez dans l’application
flat@5.0.0 · directePollution de prototype dans flat
Importé par votre code (web/src/config.js:2), chargé par rien d’autre
Proposé : non concerné — le code vulnérable n’est jamais exécuté
La fonction qui mène au code corrigé (unflatten) n’est nommée nulle part dans le dépôt.
Ce qui est couvert
| Écosystème | Niveau paquet | Niveau fonction | Source |
|---|---|---|---|
| Go | Oui | Oui | govulncheck |
| Rust (Cargo) | Oui | Oui | Les fonctions que nomme RustSec |
| JavaScript et TypeScript (npm) | Oui | Pro et Consultant | Les données de fonctions vulnérables de Provetry, et l’analyse des appels Jelly |
| Python (PyPI) | Oui | Pro et Consultant | Les données de fonctions vulnérables de Provetry, et une lecture des appels |
| Java (Maven) | Preuve d’usage seulement | Pro et Consultant, pour les dépendances directes, avec le SBOM CycloneDX de votre build | Les données de fonctions vulnérables de Provetry |
| PHP, Ruby, .NET | Oui | Pas encore | — |
Les résultats arrivent dans Provetry depuis votre CI avec une clé d’API, avec les offres payantes.
Les données de fonctions vulnérables
La plupart des avis de sécurité nomment un paquet et ses versions, pas les fonctions en cause. Chaque jour, Provetry lit le correctif de chaque avis relu, repère les fonctions qu’il modifie, puis les fonctions publiques du paquet qui y mènent. C’est ce qui permet à votre CI de distinguer « chargé » d’« appelé ». Ces données sont servies aux clients Pro et Consultant avec leur clé d’API.
Comment ça tourne
Dans votre CI, sur votre code
Le cœur open source s’exécute dans votre pipeline (action GitHub, modèle GitLab). Votre code source ne quitte jamais votre infrastructure : Provetry reçoit les résultats, pas le code.
Des propositions, jamais des décisions
Chaque « non concerné » est une proposition avec sa preuve. Vous l’acceptez, une à une ou toutes ensemble, et elle devient votre évaluation VEX, publiée si vous le choisissez.
Tout doute compte comme un usage
Là où il voit un import dynamique, un appel par réflexion, une macro, une méthode qu’un framework appelle par convention ou un fichier trop gros pour être lu, l’outil ne conclut rien. Un faux « jamais appelé » est l’erreur qu’il est conçu pour éviter avant tout.
Gardé comme preuve
Les évaluations acceptées entrent dans votre journal de preuves, chaîné et horodaté, prêt pour une autorité de surveillance du marché.
Les limites, dites franchement
- Le niveau fonction lit des noms, pas des types : une fonction que votre code nomme compte comme peut-être appelée, même quand elle ne l’est pas. Pour npm et PyPI, une analyse des appels cherche ensuite l’appel lui-même et, quand elle le trouve, montre le fichier et la ligne ; sinon la mention reste, car ces analyses ratent certains appels. Comme toute analyse de code, il ne peut pas voir un appel fait d’une manière qu’il ne connaît pas.
- Un correctif peut changer plus que le code vulnérable, et un avis peut n’en citer aucun : il n’y a alors pas de réponse au niveau fonction, seulement au niveau paquet.
- Les bibliothèques Java se trouvent aussi entre elles à l’exécution (chargeurs de services, fichiers de fournisseurs, auto-configuration). Un « jamais appelé » n’est donné que pour une dépendance directe, d’après le graphe complet des dépendances qu’écrit votre build, et jamais quand du code généré (Lombok, MapStruct…) ou des jars embarqués peuvent l’appeler.