Faire relire son code par une IA, la revue de sécurité automatique

Avant l’outil, le constat. Les failles qui font tomber les sites d’entreprise ne sont pas des exploits de laboratoire.

L’injection SQL. Un champ de recherche envoie ce que l’internaute a tapé directement à la base de données, sans le filtrer. Quelqu’un tape autre chose qu’un mot, et la base répond à une question qu’on ne lui a pas posée. La faille a plus de 20 ans et elle est toujours dans le tiercé de tête.

Le XSS stocké. Un formulaire de commentaire accepte ce qu’on lui donne et l’affiche tel quel à tous les visiteurs suivants. Si on y met du code au lieu d’un texte, ce code s’exécute chez chaque visiteur. Le mécanisme tient en 2 lignes de négligence.

Pourquoi elles survivent. Pas par difficulté. Les 2 se corrigent avec une fonction que tous les cadres de développement fournissent. Elles survivent parce qu’on écrit vite, qu’on teste ce qui doit marcher et jamais ce qui ne doit pas, et que personne ne relit.

Une commande, et l’ensemble du projet passe au crible.

Le principe. On lance la revue de sécurité depuis l’outil de développement, sans rien paramétrer. L’IA parcourt le code, repère les endroits douteux, puis vérifie chacun d’eux avant de conclure. C’est cette deuxième passe qui fait la différence avec un simple détecteur de motifs.

Ce qu’elle cherche. Les familles les plus courantes, injection SQL, failles de type XSS, défauts d’authentification et d’autorisation, mauvaise gestion des données sensibles. Autrement dit, l’immense majorité de ce qui arrive vraiment.

Ce qu’elle rend. Pour chaque problème, l’endroit exact dans le fichier, une gravité, le scénario d’exploitation avec la valeur qu’il faudrait entrer pour déclencher la faille, et la correction à faire. Pas un avertissement vague, une consigne.

Un développeur a introduit 2 failles volontaires dans un projet Laravel pour voir ce qui serait attrapé.

L’injection SQL, trouvée. Le champ de recherche envoyait la saisie brute dans une requête écrite à la main. Repérée, expliquée, avec la recommandation d’employer le constructeur de requêtes du cadre plutôt que d’écrire la requête soi-même.

Le XSS stocké, trouvé. Le commentaire était enregistré sans validation et affiché sans échappement. Repéré, avec le scénario d’attaque et 2 corrections, échapper à l’affichage et valider avant d’enregistrer. Les 2, parce que corriger l’affichage seul laisse la donnée sale en base.

Le temps et le prix. 3 à 5 minutes en tout, et de l’ordre de 60 centimes de consommation. Sur un projet de cette taille, c’est le prix d’un café pour une relecture que personne n’aurait faite.

C’est la partie la plus utile du test, et celle qu’on ne raconte jamais.

Ce qui s’est passé. Une clé d’accès à un service de paiement avait été laissée en dur dans le code, ce qui est une faute classique, la clé finit sur le dépôt et devient publique. L’IA l’a bien repérée.

Puis elle l’a écartée. À la vérification, elle a conclu que ce n’était pas un problème, parce que la variable s’appelait clé publique et que le mot test apparaissait à proximité. Le raisonnement se tenait. Il était faux.

La leçon, et elle vaut pour tout le reste. Une relecture par IA se lit, elle ne s’approuve pas. Elle est excellente pour trouver ce qu’on ne cherchait pas, et faillible quand elle décide toute seule qu’un signalement n’en est pas un. Le tri final reste humain, et c’est pour cette raison que nous ne livrons jamais un rapport automatique tel quel dans nos contre-expertises.

Lancer la relecture à la main, c’est bien. L’automatiser au bon moment, c’est autre chose.

Le contrôle avant fusion. Une intégration officielle analyse chaque proposition de modification du code et publie son verdict directement dans la discussion, avant que le code rejoigne le projet. Note de gravité, classification de la faille, extrait fautif, correctif prêt à appliquer.

Pourquoi ça change tout. Un contrôle qui arrive après la mise en ligne signale un problème déjà exposé. Un contrôle qui arrive avant la fusion empêche le problème d’exister. C’est le même outil, à un moment différent, et l’écart de valeur est énorme.

Ce que ça implique côté organisation. Il faut que le code passe par des propositions de modification relues, et pas directement en production. Beaucoup de petites structures n’en sont pas là, et c’est souvent le vrai chantier, avant l’outil.

Trois limites à poser franchement, parce que le sujet se vend beaucoup.

Ce n’est pas un audit de sécurité. Un audit cherche des enchaînements, des erreurs de logique métier, des failles propres à votre architecture. Une relecture automatique cherche des motifs connus. Les 2 sont utiles, ils ne font pas le même travail.

Ce n’est pas un test d’intrusion. Elle lit le code, elle n’attaque pas le site en fonctionnement. Une configuration serveur bancale, un mot de passe faible sur un compte d’administration, une sauvegarde accessible publiquement, rien de tout cela n’est dans le code.

Ce n’est pas une garantie. Aucun outil ne peut affirmer qu’un projet est sûr. Il peut affirmer qu’il a trouvé telle et telle faille. L’absence de signalement n’est pas une preuve d’absence de faille, c’est une absence de preuve.

Trois décisions, selon votre situation.

Vous avez un développeur ou une agence. Demandez que cette relecture tourne sur chaque modification avant mise en ligne, et que le rapport vous soit transmis. Ce n’est pas une exigence déraisonnable, c’est quelques minutes et quelques centimes par passage.

Votre site a été fait il y a longtemps et personne n’y touche. C’est le cas le plus risqué, parce qu’un site figé n’est pas un site sûr, ce sont les cadres et les greffons autour qui vieillissent. Une relecture ponctuelle donne au moins un état des lieux, et c’est le genre de contrôle que mène notre agent IA cybersécurité sur les sites que nous suivons.

Vous n’avez personne côté technique. Ne lancez pas l’outil seul, et surtout n’appliquez aucun correctif proposé sans comprendre ce qu’il change. Un correctif mal posé casse un site aussi bien qu’une faille l’expose. Faites-le faire, et demandez le rapport.