Contexte et problème
Les scanners de vulnérabilité livrent chaque matin une liste de paquets, leurs versions, un score de gravité et parfois le texte d’un avis. Cette information ne contient aucune donnée sur la façon dont le paquet est intégré dans l’environnement de production. Sans connaître la chaîne de dépendances, l’image Docker, le déploiement ou le graphe d’appels, il est impossible de dire si la faille est réellement exploitable. Le texte souligne que les équipes de sécurité répondent souvent « personne ne sait encore », car la preuve peut nécessiter plusieurs heures d’investigation.
Modélisation du graphe de la chaîne d’approvisionnement
La solution proposée consiste à représenter la chaîne logicielle comme un graphe typé. Les nœuds typiques sont : paquet, artefact, build, image, application, environnement, scan et exception de politique. Les arêtes décrivent les relations : « depends on », « contains », « produced by », « deployed as », « promoted by », « calls ». La plupart des organisations possèdent déjà ces métadonnées, réparties entre registres, métadonnées de construction, enregistrements de déploiement, SBOM, inventaires d’exécution et graphes d’appels. Le défi consiste à agréger ces sources disparates en un graphe cohérent.
Analyse de l’architecture déterministe
Une fois le graphe construit, un moteur de traversée peut calculer la « reachability » de chaque vulnérabilité. La traversée transforme la question d’exploitabilité en une opération de recherche de chemin : paquet → artefact → image → application → environnement → symbole vulnérable. Si aucun chemin n’existe, la faille n’est pas exploitable dans le contexte actuel. Cette approche rend chaque conclusion inspectable : le système renvoie le chemin complet, permettant à l’auditeur de vérifier chaque étape et de corriger les enregistrements erronés. Un test de robustesse consiste à désactiver le modèle de langage ; le moteur doit toujours produire le même résultat et le même chemin, prouvant que le raisonnement repose sur des faits déterministes.
Rôle limité des modèles de langage
Les grands modèles restent utiles pour interpréter des requêtes ambiguës, sélectionner le workflow d’analyse approprié et reformuler les résultats sous forme de texte compréhensible. Leur fonction doit se limiter à la narration et à la génération d’intentions de recherche structurées (portée du dépôt, motif de nom, type de paquet, seuil d’âge, limite de résultats). Un composant de construction de requêtes transforme ensuite ces intentions en requêtes sécurisées, en appliquant les politiques d’accès et en empêchant toute opération destructive. Ainsi, le modèle ne crée jamais de nouvelles arêtes dans le graphe ; il ne fait que consommer les preuves déjà établies.
