Analyse d'atteignabilité

Pourquoi elle existe

Un scan SCA compare les versions de paquets aux avis de sécurité. Il sait qu'une version contient une faille, mais pas si votre application utilise la partie concernée. Une bibliothèque comptant des centaines de fonctions et un seul parseur vulnérable est signalée de la même manière, que vous appeliez ce parseur ou non, et sur un grand arbre de dépendances, cela finit par former un backlog que personne ne peut terminer.

Comment fonctionne l'analyse d'atteignabilité

1. Trouver le code vulnérable. L'outil doit savoir dans quelle fonction se situe une vulnérabilité. Les avis de sécurité ne le disent souvent pas : les éditeurs maintiennent donc leurs propres données.
2. Construire un graphe d'appels. Il cartographie quelles fonctions appellent quelles autres, depuis votre code jusque dans les dépendances.
3. Chercher un chemin. Si une chaîne d'appels mène de votre code à la fonction vulnérable, le résultat est atteignable. Sinon, il est marqué comme non atteignable et classé plus bas.

Niveaux d'atteignabilité

Niveau	Question à laquelle il répond	Compromis
Dépendance	Le paquet est-il réellement importé ?	Peu coûteux, et n'écarte que les dépendances inutilisées
Fonction	Un chemin d'appels peut-il atteindre la fonction vulnérable ?	L'objectif courant, qui nécessite un graphe d'appels et des données de vulnérabilité par fonction
Exécution	Ce code a-t-il été chargé ou exécuté en production ?	Des preuves issues du trafic réel, mais uniquement pour ce qui s'est exécuté pendant l'observation

Une véritable exploitation exige plus qu'un chemin. L'entrée doit atteindre la fonction sous une forme qui déclenche la faille, ce que peu d'outils savent déterminer.

Où l'analyse d'atteignabilité atteint ses limites

• Non atteignable ne signifie pas sûr. Cela signifie que l'outil n'a trouvé aucun chemin. La réflexion, les imports dynamiques et le chargement de plugins peuvent créer des chemins que l'analyse statique ne voit pas.
• La couverture varie selon les langages. Les langages compilés statiquement sont plus faciles à tracer que les langages dynamiques, et les outils diffèrent sur les écosystèmes qui bénéficient d'une analyse au niveau des fonctions.
• Les données de vulnérabilité sont incomplètes. Si personne n'a associé un avis de sécurité à une fonction, l'outil n'a rien à chercher.
• Elle change avec votre code. Un résultat non atteignable aujourd'hui peut devenir atteignable après la prochaine release : la réponse doit donc être revérifiée.
• Elle ne classe que ce qui a été identifié. Un composant que le scanner n'a jamais trouvé ne peut pas être analysé. Sans inventaire complet, l'atteignabilité ne trie qu'une partie du tableau.

Comment l'utiliser en toute sécurité

• Servez-vous-en pour ordonner le travail, pas pour l'écarter. Corrigez d'abord les résultats atteignables et planifiez le reste, plutôt que de le clôturer.
• Ne la laissez pas primer sur une exploitation active. Un résultat figurant dans le catalogue KEV de la CISA ou doté d'un score EPSS élevé mérite une décision humaine, même s'il est marqué comme non atteignable.
• Soyez prudent avec les services exposés à Internet. Le coût d'une mauvaise réponse est le plus élevé là où les attaquants peuvent vous atteindre directement.
• Consignez le raisonnement. Si vous décidez qu'un résultat ne s'applique pas, une déclaration VEX conserve la décision et en explique la raison à vos clients.

Pour savoir comment l'atteignabilité s'articule avec la sévérité, les données d'exploitation et le contexte métier, voir comment prioriser les vulnérabilités.

Quels outils proposent l'analyse d'atteignabilité ?

De nombreux outils SCA commerciaux la proposent, dont Snyk, Endor Labs, Mend, Checkmarx, Semgrep et Aikido, et la profondeur varie selon le langage. govulncheck, pour Go, est un exemple gratuit limité à un écosystème. Consultez le comparatif des meilleurs outils SCA pour voir ce que chacun couvre.

La place de CRACI

CRACI ne propose pas d'analyse d'atteignabilité. Il intervient à l'étape précédente : savoir ce que contient réellement le build. C'est un runner GitHub Actions qui enregistre chaque paquet récupéré par chaque job, y compris les dépendances cachées que les scanners de lockfiles manquent, et continue de réévaluer les SBOM de ce qui a été livré à mesure que de nouvelles vulnérabilités sont publiées. Si l'atteignabilité est votre priorité absolue, utilisez un outil conçu pour cela à côté de CRACI. Consultez la place de CRACI à côté de vos outils SCA.

Analyse d'atteignabilité : questions fréquentes

Qu'est-ce que l'analyse d'atteignabilité en SCA ?

Elle vérifie si votre code peut réellement appeler la fonction vulnérable d'une dépendance, afin de classer plus bas les résultats pour lesquels aucun chemin ne part de votre code.

L'analyse d'atteignabilité est-elle précise ?

Elle est utile, mais ce n'est pas une preuve. Un résultat atteignable a un chemin réel, tandis qu'un résultat non atteignable signifie seulement que l'outil n'en a trouvé aucun. La réflexion, le chargement dynamique et les lacunes des données de vulnérabilité peuvent tous masquer un chemin.

Peut-on ignorer les vulnérabilités non atteignables ?

Ne les ignorez pas purement et simplement. Planifiez-les après les résultats atteignables, revérifiez-les après chaque modification du code, et accordez une attention particulière à tout ce qui est activement exploité ou s'exécute dans un service exposé à Internet.

Quelle est la différence entre atteignabilité et exploitabilité ?

L'atteignabilité demande si le code peut parvenir à la fonction vulnérable. L'exploitabilité demande si un attaquant peut se servir de ce chemin pour nuire. Une faille peut être atteignable sans être exploitable dans votre configuration.

L'analyse d'atteignabilité réduit-elle les alertes ?

Oui, c'est son objectif principal. L'ampleur dépend du langage, de l'outil et de la part de chaque dépendance que votre code utilise.