Je n'automatise pas la décision, j'automatise le fait qu'elle expire

Une CVE tombe sur un composant que tu exploites. La dépendance fautive est corrigée depuis des semaines en amont, mais l'éditeur de l'image n'a pas republié. Il n'y a rien à mettre à jour. Ton scanner, lui, voit un correctif disponible et refuse de laisser passer la livraison.

Tu ne peux pas patcher. Tu ne peux pas livrer. Et tu ne peux pas oublier.

C'est là que commence le travail réel, et c'est exactement là qu'on me propose de mettre un agent.

La détection est le problème facile

On me demande de plus en plus souvent de construire un assistant qui lit les bulletins et répond si on est impacté. C'est une démo qui marche. C'est aussi une place déjà prise, par quelque chose de gratuit et de reproductible.

Un scanner passe sur les images modifiées à chaque livraison, croise ce qu'il trouve avec les bases publiques, et rend une liste. Il ne comprend rien, et c'est précisément ce qui le rend utile : il compare. Deux fois la même image donne deux fois la même liste.

L'agent, lui, devine, faute de source de vérité sur ce qui tourne réellement chez toi. Tu peux objecter qu'il suffit de lui fournir l'inventaire, et c'est là que ça devient intéressant : il l'aura, et il comparera des numéros de version en langage naturel. Savoir si une version tombe dans une plage annoncée n'est pas une affaire de compréhension, c'est une comparaison ordonnée. Un modèle la réussit souvent. Souvent n'est pas un critère d'exploitation.

L'exploitabilité ne se lit pas dans le bulletin

Voilà le vrai travail. Une fois la liste établie, il faut décider, ligne par ligne, si la faille est atteignable chez toi. Et cette information n'est écrite nulle part dans l'avis de sécurité.

Trois décisions que j'ai prises et notées, telles quelles.

Une bibliothèque HTTP visée par une attaque de request smuggling. Sauf que dans ce déploiement, elle sert de pile cliente sortante. Il n'y a pas de serveur entrant derrière un proxy partagé, donc la frontière que l'attaque exploite n'existe pas.

Un pilote PostgreSQL vulnérable, embarqué dans un service dont le journal de requêtes est configuré en CSV. Aucune cible PostgreSQL, aucun identifiant de base, aucun chemin réseau vers une base pour ce service. Le code fautif est présent et n'est jamais appelé.

Une faille OpenSSL sur le traitement de très grands certificats X.509 en 32 bits. L'image est épinglée en linux/amd64. Le chemin vulnérable est hors de la cible d'exécution.

Aucune de ces trois phrases ne se trouve dans un bulletin. Elles se trouvent dans ma configuration, et dans ce que je sais de la façon dont le service est joignable. Un modèle qui n'a ni l'une ni l'autre ne peut pas produire ce raisonnement. Et même en lui donnant tout, il manquerait l'essentiel : quand j'écris « chemin non utilisé » dans un fichier versionné, je signe. Lui ne signe rien.

Ce que j'automatise n'est pas la décision

Accepter un risque est un jugement, et il reste le mien. Ce que j'automatise, c'est le fait que ce jugement ne puisse pas être oublié.

Le mécanisme tient en une contrainte de format. Toute exception porte une échéance, et un contrôle vérifie ces échéances avant même que le scanner démarre. Une exception périmée ne dégrade pas la sévérité, elle casse la chaîne de livraison.

# Toute entrée porte une échéance et une raison. Un script de validation
# tourne AVANT le scan : une date dépassée fait échouer la livraison,
# même si la CVE est listée ici.
CVE-2026-XXXXX  # expires 2026-08-14 : pile cliente sortante, pas de serveur
                # entrant derrière un proxy partagé, aucune image corrigée publiée

# Et le gate lui-même, volontairement étroit.
trivy image --scanners vuln --severity CRITICAL,HIGH \
  --ignore-unfixed --exit-code 1 --ignorefile /dev/stdin "$image"

Deux règles encadrent ce que j'ai le droit d'acquitter. Une faille critique n'est quasi jamais acquittée, sauf preuve explicite de non-exploitabilité du type de celles décrites plus haut. Une faille haute peut l'être trente jours au maximum, le temps que l'éditeur publie.

Et un choix que je défends : --ignore-unfixed. Je ne bloque pas sur des vulnérabilités que personne ne peut corriger. Un gate qui hurle sur ce qui n'a pas de solution finit ignoré, et un gate ignoré ne protège rien. Ce qui reste sur ma table, ce sont les failles qui ont un correctif publié quelque part et que je n'ai pas encore.

L'automate ne décide pas à ma place. Il m'empêche d'oublier ce que j'ai décidé.

Une exception doit être aussi étroite que la décision

C'est le détail qui coûte le plus de travail et dont je suis le plus content.

Une exception, par défaut, s'applique partout. Tu acquittes une CVE parce qu'elle est inatteignable sur un service précis, et tu viens de la rendre invisible sur tous les autres, y compris ceux où elle est parfaitement exploitable. Le fichier d'exceptions devient alors le point aveugle du dispositif.

J'ai donc des exceptions à portée limitée : un bloc délimité, associé à une image identifiée par son empreinte, et un filtre qui ne laisse passer ces lignes que si la cible en cours de scan est exactement cette image. Ailleurs, les mêmes identifiants ne masquent rien.

C'est la traduction technique d'une phrase simple : j'ai accepté ce risque ici, pas j'accepte ce risque.

Pourquoi un modèle ne tient pas ce poste

Deux raisons, et aucune n'est le hasard de génération.

La première, il n'a pas d'état. Il peut analyser une vulnérabilité remarquablement bien, aujourd'hui. Il ne reviendra pas dans trente jours te dire que l'exception qu'il a validée arrive à terme. Un risque accepté est une dette, et une dette a besoin d'un registre, pas d'un avis.

La seconde, son comportement n'est spécifié nulle part. On m'objecte souvent qu'une température à zéro suffit à le rendre reproductible. Ça règle la variance d'échantillonnage, pas le vrai problème : mon script ne change que le jour où je le change, alors qu'un modèle change quand son fournisseur décide de le mettre à jour. Tu peux fixer une température. Tu ne peux pas fixer un contrat.

Ce que je cherche en choisissant un automate plutôt qu'un agent, ce n'est pas de l'intelligence. C'est de la stabilité dans le temps.

Ce que ce dispositif coûte

Il serait malhonnête de le présenter comme gratuit, alors voici ses trois défauts, dont deux m'ont déjà coûté du temps.

Les échéances groupées produisent des avalanches. Quand un lot entier d'exceptions a été posé le même jour, il arrive à terme le même jour, et il casse la chaîne de livraison d'un coup, au milieu d'un travail qui n'avait rien à voir. Le mécanisme est conçu pour me forcer à revenir. Il ne choisit pas le moment, et le moment est rarement bon.

Renouveler n'est pas décider. Il m'est arrivé de reconduire une exception uniquement parce qu'aucune image corrigée n'existait encore. Ce n'est pas un arbitrage, c'est un constat, et la seule façon honnête de le traiter est de l'écrire tel quel dans le fichier plutôt que de laisser croire à une décision. Le jour où renouveler devient un réflexe, le dispositif ment.

Enfin, il ne couvre que ce qui se déclare par un numéro de version sur un composant inventorié. Une faille de configuration par défaut, une bibliothèque embarquée que l'inventaire ne liste pas comme produit, et l'automate se tait. De façon parfaitement traçable, et parfaitement fausse. Un automate déterministe qui se trompe se trompe toujours à l'identique, sans jamais te réveiller. C'est le prix de la reproductibilité, et il faut le connaître pour l'accepter.

Où le modèle entre quand même

Là où il n'y a rien à comparer, seulement à lire. Un scanner croise des versions avec une base publique. Il ne lit pas la note de version en prose d'un équipementier télécom qui corrige un défaut sans jamais publier d'avis formel. Ça, c'est du texte écrit pour des humains, et c'est le poste du modèle : convertir un texte en champs, avec le droit de dire qu'il n'a pas compris. Sans cette porte de sortie, un modèle à qui on impose une liste de réponses en choisit toujours une, et tu obtiens une réponse propre, bien formatée et fausse.

La liberté que je lui laisse ensuite dépend de sa distance au geste réel. Sur un diagnostic d'interop SIP, je lui donne un pcap et il rédige une hypothèse, le test à rejouer et le patch complet, parce que c'est moi qui l'applique et qu'un patch faux me coûte une relecture. Sur un agent vocal, il comprend l'intention de l'appelant puis choisit une destination déclarée dans le plan de numérotation, sans jamais composer un numéro qu'il a produit lui-même. Dans aucun des deux cas il ne décide de mettre quelque chose en production.

Ce qu'il en reste

La question à poser devant un projet d'automatisation n'est pas de savoir si on y met de l'IA. C'est de savoir ce qui doit encore être vrai dans trente jours.

Un scanner te dit ce qui est vrai aujourd'hui. Un modèle te donne une lecture d'aujourd'hui, et une autre demain. Ce qui te sauve le jour où un client te demande pourquoi son équipement est resté exposé, c'est un automate ennuyeux qui n'a rien oublié, et une décision datée, signée, que tu peux défendre.

Notes et sources

• Trivy, fichier d'exceptions, --ignore-unfixed et sévérités : ce qu'on choisit de ne pas bloquer fait partie de la politique.
• Épinglage par empreinte, mise à jour surveillée et scan en garde-fou de livraison : la version déployée est une donnée, pas une supposition.
• Sortie contrainte d'un modèle : lui imposer des champs plutôt que du texte libre, et lui laisser une valeur pour dire qu'il ne sait pas.
• Deux articles à venir sur l'interop SIP et sur l'isolation d'un datacenter par le DNS, dont sont tirés le diagnostic et le principe du garde-fou qui bloque dur.

Une chaîne de livraison à rendre défendable, une veille qui produit du bruit plutôt que des décisions, un agent vocal à borner ? Prendre contact.