Sécurité des applications : l'IA ne vous sauvera pas

Bonjour les cyber-constructeurs 🖖

Poursuivant notre série de juillet sur la sécurité des applications, je souhaite discuter de quelque chose qui est actuellement partout : IA et « codage vibratoire ».

Si vous n'avez pas joué avec GitHub Copilot, Cursor ou demandé à Claude, Gemini ou ChatGPT de générer un site Web à partir de zéro, vous manquez l'excitation. C'est sauvage. Ajoutez quelques conseils de haut niveau et vous obtenez un code utilisable : mise en page, style et même quelques tests.

C'est impressionnant. C'est rapide. C'est pratique. Cela vous donne le sentiment que « le logiciel est devenu plus simple ».

Mais voici le problème…L'IA ne nous sauvera pas des problèmes de sécurité de nos applications.

J'entends toujours les mêmes illusions :

« Et si l’IA corrigeait simplement toutes les vulnérabilités pour nous ?
“Ne pouvons-nous pas simplement déléguer le codage sécurisé aux LLM ?”

Non, pas encore. Peut-être jamais.

La sécurité reste un problème humain. C'est toujours un problème de conception. encore un collaboration problème.

Dans cet article, je voudrais me concentrer sur trois changements qui

• Pourquoi l'IA ? ne nous sauvera pas tous…mais l’IA est un parfait multiplicateur de sécurité

• Parce que Les équipes de sécurité doivent construire

• Comme fermer la dette de sécurité

• Comme donner du sens à la sécurité (spoiler : avec des tâches de réparation que les développeurs comprennent et intéressent)

Nous espérons tous que l’IA contribuera à améliorer la sécurité. Nous voulons des outils qui analysent le code, trouvent les bogues, les corrigent et font tout cela plus rapidement que nous. Nous voulons des pentesters assistés par l’IA. Nous voulons que la génération de code sécurisé soit l'option par défaut.

Et bien sûr, L'IA est excellente dans la mise en œuvre—Ouais vous savez quoi réparer.

Fournissez des directives claires et vous refactoriserez le code cassé ou même dangereux. Donnez-lui des instructions détaillées et il rédigera un texte standard pour vous.

Mais demandez-lui de trouver des vulnérabilités. seul-à partir de zéro, sans instructions claires- et vous vous retrouverez rapidement dans un mur.

Le tableau suivant donne un aperçu de l'état actuel des meilleurs modèles LLM.

Il est extrait de Banque de récompensesun projet de recherche de l'Université de Stanford explorant l'utilisation de modèles d'IA pour la cybersécurité.

Il est clair que :

• Lorsqu’ils y sont correctement invités, les modèles d’IA peuvent automatiser efficacement le processus de correction des vulnérabilités. Ils nécessitent un message (ou une définition de tâche) clair et spécifique, et comme toute autre tâche de mise en œuvre, le LLM générera un nouveau code plus sécurisé.

• Mais lorsqu’on leur demande de détecter des problèmes sans se référer à un journal d’alertes ou à une ligne de code spécifique, les LLM sont très faibles pour identifier de nouveaux problèmes. Un taux de réussite de 5 % est presque une valeur aberrante. De plus, le coût est supérieur à la tâche de mise à jour. Le LLM doit lire tout le code source, et avec un modèle économique calculé par jeton, le prix est plus de 10 fois plus élevé.

Donc, si l’IA n’est pas (encore ?) efficace pour détecter les problèmes et les résoudre automatiquement, où est l’IA ?

Sur la base de nos tests et de mon analyse, j'aimerais partager quelques idées.

Quelle IA ? Exc.els at est l'agrégation, le résumé et l'automatisation du flux de travail. Vous pouvez afficher 50 alertes et marquer les plus intéressantes. Vous pouvez ajouter du contexte aux résultats. Il peut extraire les CVE pertinents, corréler les journaux, consulter votre manuel d'analyse et vous aider à classer.

C'est la vraie valeur. mais c'est augmenterpas de remplacement. Ces outils amplifient vos détections et hypothèses. Et si vos hypothèses sont fausses, le résultat le sera aussi.

L'IA ne répare pas votre processus. Cela le reflète.

C'est pourquoi nous avons encore besoin analyse rigoureuse du code, une formation sûre dès la conceptionet collaboration en temps réel entre les développeurs et les équipes AppSec.

Trop de RSSI sont issus du milieu des infrastructures. Ils savent comment sécuriser les réseaux, configurer des pare-feu et gérer les centres de données. Mais la sécurité des applications ? C'est le problème de quelqu'un d'autre (indice : ingénieurs logiciels). Alors que se passe-t-il ?

Ils sélectionnent certains outils, achètent peut-être un scanner et les mettent en œuvre. Ils établissent des mesures (telles que le nombre de vulnérabilités trouvées, le temps de correction, la couverture, etc.) et chargent les développeurs de résoudre les problèmes. Ils surveillent. Ils informent. Ils « autorisent ».

Mais voici la vérité : Ils ne sont pas impliqués dans le véritable travail de sécurité.. La sécurité des applications se produit dans la base de code, pas dans les tableaux de bord.

Les meilleures organisations investissent dans ce modèle. Leurs ingénieurs en sécurité rencontrent les développeurs. Ils coder ensemble. Ils aident à mettre en œuvre de nouveaux schémas cryptographiques. Ils corrigent la logique d'authentification. Ils optimisent la gestion sécurisée des séances. Ils ne se contentent pas d'attribuer des tickets : ils résolvent des problèmes.

Les applications sécurisées ne sont pas créées en suivant les progrès. Vous les créez en fournissant des tâches de correction exploitables.

👉 Ce que vous pouvez faire ensuite : Voulez-vous de la confiance? Soyez dans la pull request.

Aujourd'hui, de nombreux systèmes acceptent encore les entrées HTTP non validées et les transmettent directement aux requêtes SQL sans validation. On voit toujours les entrées rendues directement sur les pages sans s'échapper : XSS classique. Rien de spécial. Juste insouciant.

Et c'est là le vrai problème : Vous ne pouvez pas collaborer lorsque vous vous noyez sous les dettes techniques.

J'ai vu des entreprises avec des milliers… oui, des milliers de vulnérabilités connues et non corrigées. Il s’agit d’un « retard de sécurité », mais aussi d’un responsabilité. Et plus la dette en titres augmente, moins toute nouvelle initiative devient significative.

C'est comme essayer de s'entraîner pour un marathon avec une jambe cassée. Vous n'allez nulle part rapidement.

Ce dont la plupart des équipes ont besoin, c'est d'un engagement systématique à réparer ce qui est déjà brisés, à commencer par des lacunes critiques et exploitables qui mettent en danger les données réelles des utilisateurs.

Vous ne pouvez pas gagner une place à la table des développeurs lorsque vous traînez derrière vous 1 000 découvertes non résolues.

👉 Ce que vous pouvez faire ensuite : Auditez votre backlog. Corrigez les bases : SQLi, XSS et les contrôles d'accès manquants. Mesurer les progrès en termes de réductionpas seulement la détection.

J'ai vu de nombreux développeurs traiter la sécurité comme de la paperasse fiscale.

Ils reçoivent une alerte. Ils obtiennent un score CVSS. On leur dit de le réparer « pour se conformer ». Mais demandez-leur pourquoi c'est important. Des regards vides. Personne n’a expliqué ce qui pourrait mal tourner ou ce que les utilisateurs pourraient perdre.

Une partie du problème réside dans la surcharge des outils. Les scanners inondent encore parfois les tableaux de bord d'alertes en double des centaines de trouvailles qui soulignent la cause profonde exacte. Ils créent de la confusion, pas de la clarté.

Chaque vulnérabilité doit être transformée en une tâche de remédiation unique et riche, destinée aux développeurs.

Cette tâche doit avoir un contexte :

• Pourquoi c'est important. Est-ce exploitable ? Quelle est la trajectoire de l’attaquant ?

• Qui est concerné ? S'agit-il d'un flux de travail client principal ou d'une fonctionnalité peu connue ?

• À quoi ressemble la solution. Quelle partie du code, quelles bibliothèques et combien de temps cela prendra-t-il ?

Et surtout, il doit être lié au histoire d'utilisateur que les équipes de développement comprennent. Si vous souhaitez que votre demande de sécurité soit prioritaire, ne dites pas « XSS dans login.html ». Dites : “Ce bug permet à quelqu'un de voler un jeton de session pendant le flux de connexion.” Maintenant, vous avez de l'attention.

Nous devons également humaniser la remédiation.

• Connectez-le aux objectifs du Premier ministre.

• Montrez comment vous protégez le parcours utilisateur.

• Aidez les développeurs à avoir l'impression qu'ils ne se contentent pas de mettre à jour des correctifs, mais qu'ils protecteur.

C’est ainsi que nous passons d’une réflexion par cases à cocher à une sécurité significative.

👉 Ce que vous pouvez faire ensuite : Choisissez un type de vulnérabilité courant (par exemple, XSS ou contrôle d'accès rompu). Créez un modèle qui inclut : le risque d'exploitation, l'impact sur l'utilisateur, le plan de remédiation et l'équipe responsable.

L'agitation est forte. Les outils sont géniaux. Mais voici la réalité : l’IA ne va pas construire votre posture de sécurité à votre place, ni s’asseoir avec vos développeurs pour réécrire une logique brisée. Cela dépend toujours de vous.

L’IA est un puissant multiplicateur, mais seulement lorsque vous savez déjà où vous allez.

En 2025, les organisations qui réussiront seront celles où les développeurs, les équipes de sécurité et les équipes produit collaborent étroitement.

Construisez mieux. Ensemble. C'est la règle d'or.

Laurent 💚