# Sinks dangereux dans du code source

## Objectif

Un agent IA qui exécute une action à partir de ce qu'un modèle vient de
produire — plutôt que d'une entrée strictement contrôlée — reproduit
exactement le patron classique entrée non fiable vers point dangereux,
sauf que la source non fiable est ici la sortie du modèle lui-même,
potentiellement influencée par un contenu externe qu'il vient de lire.
`detecteur-sinks-llm-dangereux` scanne du code source Rust ou Python et
détecte les cas où une variable capturant probablement une sortie de LLM
atteint, plus loin dans une fenêtre de lignes bornée, un point d'exécution
dangereux — commande shell, évaluation dynamique, écriture de fichier,
requête SQL — sans qu'un appel de validation identifiable n'intervienne
entre les deux sur le même identifiant.

## Conception : un compromis honnête

Corrélation par identifiant textuel dans une fenêtre de 25 lignes, pas une
vraie analyse de flot de données ni un suivi de portée de fonction réel.
Viser deux langages dont un (Python) n'a pas d'accolades aurait demandé
deux implémentations de parsing de portée complètement séparées pour un
gain de précision marginal — documenté honnêtement comme une fenêtre
bornée plutôt que présenté comme plus rigoureux qu'il ne l'est. Masquage
des chaînes et des commentaires propre à chaque langage, testé isolément.

> ATTENTION : présence d'un mot-clé de validation ne veut pas dire
efficacité réelle de cette validation. L'outil vérifie qu'un appel
`sanitize`/`valider_`/etc. existe entre la source et le sink, jamais que
cet appel neutralise effectivement le risque concerné.

## Deux bugs réels trouvés et corrigés avant publication

Un test manuel — pas une supposition — a révélé deux défauts distincts
avant que l'outil ne soit publié.

1. Faux négatif par nom de variable nu comme motif source : la première
   version incluait des noms de variable bruts en plus des formes
   d'appel. Une ligne de réaffectation après validation matchait
   elle-même comme un second point source, sans protection derrière —
   un signalement fantôme malgré la validation déjà appliquée en amont.
   Corrigé en restreignant les motifs source aux formes d'appel
   uniquement.
2. Faux négatif par collision de préfixe d'identifiant : un nom de
   variable est une sous-chaîne d'un autre nom de variable plus long. La
   vérification de corrélation utilisait une simple inclusion de
   sous-chaîne, donc une ligne de validation sur la variable la plus
   longue neutralisait à tort un signalement réel sur la variable la plus
   courte, totalement différente.

> ASTUCE : le second bug est le pire type d'erreur pour un outil de
sécurité — un vrai risque masqué, pas un simple faux positif gênant.
Corrigé par une vérification stricte de frontière de mot, avec un test
de non-régression dédié pour qu'il ne réapparaisse jamais.

## Limites assumées

Aucune résolution d'alias : une variable réaffectée à une autre par simple
copie n'est pas suivie. Le motif d'ouverture de fichier générique en
Python est un motif de sink très fréquent en usage légitime, source
possible de faux positifs si une variable de sortie LLM sert par ailleurs
de nom de fichier déjà validé autrement. Cet outil ne remplace ni une
revue de sécurité humaine ni une vraie analyse de flot de données — c'est
un outil de dégrossissage rapide, pas une preuve d'absence de risque.