Comment l’IA accélère la recherche de vulnérabilités

Annonce · Contenu partenaire de F5, relayé par Fink & Fuchs. La rédaction de SecurityToday a préparé le texte sur le plan formel.

Les logiciels évoluent de plus en plus vite, si bien que les processus de contrôle classiques ne permettent plus de détecter toutes les nouvelles vulnérabilités potentielles. L’IA générative analyse en temps réel et à grande échelle le code source et, dans certains cas, les fichiers binaires et le code compilé. Elle ne remplace ni développement sécurisé ni évaluation humaine : les fabricants doivent l’intégrer à un processus d’analyse, priorisation, vérification, correction et preuve.

À lire aussi : Triage des vulnérabilités : le CVSS seul induit en erreur · Sécurité des API : l’angle mort derrière chaque intégration

L’Agence européenne pour la cybersécurité (ENISA) a analysé dans son Threat Landscape Report 2025 au total 4 875 incidents survenus entre juillet 2024 et juin 2025. Elle cite comme voie d’accès importante pour les attaquants la compromission de logiciels dans la chaîne d’approvisionnement numérique par des vulnérabilités révélées. Elle décrit en même temps l’intelligence artificielle comme un facteur qui optimise les attaques tout en créant de nouvelles surfaces d’attaque dans les entreprises. La pression sur l’industrie du logiciel s’accentue donc sur deux fronts : elle doit détecter les vulnérabilités plus tôt dans le processus de développement et traduire plus rapidement, après leur évaluation, les défauts connus en mesures efficaces.

Pourquoi l’audit des logiciels exige aujourd’hui plus de contexte

Les applications se composent rarement aujourd’hui d’un programme de taille limitée et facile à appréhender. Elles combinent différents langages de programmation, bibliothèques, systèmes d’exploitation, fichiers de configuration, API et interfaces d’administration. Une vulnérabilité ne se situe donc pas toujours dans une seule ligne de code, mais aussi dans une lacune lors de l’intégration de plusieurs modules, un réglage par défaut non sécurisé ou une chaîne d’approvisionnement insuffisamment protégée. Les investigations classiques, analyses statiques et dynamiques, fuzzing, revues de code, contrôles des dépendances et tests reproductibles, apportent chacune des résultats importants. Leurs limites résident surtout dans la montée à l’échelle et le traitement du contexte. Sur de grandes bases de code apparaissent de nombreux constats techniquement plausibles mais, dans le contexte applicatif concret, souvent non exploitables. La véritable tâche n’est donc pas de « trouver plus de failles », mais de « établir de manière fiable la validité des constats pertinents ».

Ce que des modèles d’IA performants peuvent apporter

Les grands modèles génératifs d’IA peuvent repérer des liens entre différents fichiers et modules, signaler des flux de données inhabituels et formuler à partir d’un constat une hypothèse vérifiable. Dans des environnements de test appropriés, ils soutiennent en outre la création de cas de test, l’analyse des causes et la préparation d’un correctif. Cela s’avère particulièrement utile lorsqu’il faut combiner l’expertise en cybersécurité, la compréhension du code et l’analyse du renseignement sur les menaces.

La technologie présente toutefois des limites structurelles. Les modèles peuvent surestimer des constats, interpréter le contexte à tort ou fournir des explications convaincantes en apparence, mais non reproductibles. Dans les domaines critiques pour la sécurité s’ajoute un autre risque : un rapport sur une vulnérabilité jusque-là inconnue est lui-même à protéger, afin qu’il ne tombe pas entre de mauvaises mains. Des droits d’accès stricts, une journalisation traçable, des environnements de test isolés et des règles claires pour le partage des résultats font donc partie du processus d’audit, et non seulement de la réaction à un incident.

Exemple pratique : F5 relie l’analyse par IA et la sécurité des produits

F5 montre, avec l’utilisation systématique de modèles d’IA performants pour auditer ses propres logiciels, à quoi peut ressembler une telle approche en pratique. L’important n’est pas une exécution isolée d’un modèle, mais une infrastructure qui analyse la base de code de façon répétée, structure les constats, vérifie les résultats et ne transmet au développement que les problèmes confirmés. Ce cas d’usage est pertinent pour le secteur de la sécurité, car les logiciels F5 sont utilisés chez plus de 80 % des entreprises du Global Fortune 500, souvent dans des parties particulièrement exposées de l’architecture IT : aux interfaces entre utilisateurs et applications, entre agents d’IA et API, ainsi que dans des infrastructures qui pilotent la disponibilité et l’accès.

Des défauts dans de tels composants peuvent avoir une portée nettement plus grande qu’un problème isolé dans une application interne. Analyse, couverture de tests et livraison doivent donc être pensées ensemble. L’expérience acquise lors du développement du processus d’audit permet d’en tirer trois enseignements généraux : premièrement, l’IA doit travailler avec le contexte réel d’implémentation, au lieu d’évaluer uniquement des résumés ou des abstractions. Deuxièmement, chaque constat automatisé exige une vérification avant de servir de base de décision au développement. Troisièmement, le traitement sécurisé des résultats fait partie de la sécurité du produit, car un constat valide contient des informations sur un vecteur d’attaque possible.

Un processus d’audit robuste comporte cinq étapes

Les fabricants de logiciels peuvent en déduire un processus d’audit reproductible. Il combine analyse automatisée et vérifications strictes et évite ainsi qu’une masse gigantesque de résultats d’IA non vérifiés n’entre dans le processus de développement.

1. Établir le contexte. Les zones de code source pertinentes, les dépendances, les configurations, les artefacts de build et les conditions de déploiement connues sont définies. Les données sensibles restent ici dans des environnements contrôlés.
2. Analyser. Une analyse statique pilotée par IA recherche les flux de données risqués, les enchaînements suspects, une logique d’authentification défectueuse, une cryptographie non sécurisée et des problèmes de sécurité de la mémoire.
3. Prioriser. Les constats sont enrichis de critères techniques tels que l’exploitabilité, des rattachements CWE, des évaluations de gravité ainsi que des références de fichier et de ligne.
4. Vérifier. Une seconde méthode de vérification, par exemple un autre modèle, un test reproductible, du fuzzing ou une analyse manuelle, sépare les résultats solides des faux positifs. Un constat n’est jugé valide que lorsque son impact réel est démontrable ; il est ensuite transmis pour être corrigé en fonction de sa priorité.
5. Corriger et retester. Le correctif est vérifié dans une matrice de tests adaptée, soumis à des tests de non-régression et intégré à une version à publier. Après la livraison, on contrôle en supplément si la mesure est efficace dans les configurations réellement prises en charge.

Opérateurs et clients doivent adapter leurs cycles de mises à jour

Par rapport aux méthodes d’audit classiques, ces analyses assistées par IA plus performantes mettent au jour davantage de nouvelles vulnérabilités. En parallèle, des failles de sécurité apparaissent, avec le développement logiciel accéléré par l’IA, toujours plus vite, et sont exploitées par des attaquants dans des délais plus courts. Face à cette évolution, les clients et les opérateurs de logiciels doivent revoir leurs cycles de mises à jour. Les correctifs trimestriels ne suffisent plus aujourd’hui. Ils devraient être déployés au moins une fois par mois et, pour les applications critiques, ponctuellement dès que nécessaire.

Afin que cela n’entraîne pas d’interruptions de production, la protection doit être garantie par une sécurité à l’exécution (runtime). Des corrections plus fréquentes ne sont pas un signe de mauvaise qualité. Au contraire : elles prouvent une capacité d’analyse améliorée et un délai plus court entre la découverte et la mesure de protection. Il est décisif ici que le fabricant présente de manière transparente les impacts possibles d’un exploit ainsi que les versions prises en charge, les chemins de mise à niveau et les tests nécessaires. Pour que les correctifs soient déployés aussi facilement que possible dans leur infrastructure, les entreprises devraient mettre en œuvre les mesures d’accompagnement suivantes :

• Tenir l’inventaire à jour. Supprimer les applications, modules, interfaces et configurations devenus inutilisés et préparer les composants utilisés à des mises à jour régulières.
• Planifier la capacité de mise à jour : adapter aussi, pour son propre environnement, les processus de maintenance, de rollback, de haute disponibilité et de tests à des mises à jour fréquentes.
• Exploiter la télémétrie. Contrôle permanent des logs et des alertes permettant de détecter une exploitation ou une mauvaise configuration avant qu’un correctif ne soit disponible.
• Prioriser les risques. Analyser quelle vulnérabilité révélée touche un composant exposé, est déjà exploitée ou permet une élévation de droits de grande ampleur.
• Tenir compte des avis. Vérifier les informations du fournisseur sur le correctif concerné, tester les corrections et protéger les informations relevant de la sécurité.

Voici les principales leçons pour les fabricants

Les modèles d’IA actuels comme Claude Mythos ou GPT Cyber évoluent à une vitesse énorme. Ils mettent désormais au jour des failles de sécurité réelles, montrent des exploits possibles et aident à élaborer des correctifs. Ils peuvent pour cela analyser du code compilé, identifier des chaînes de vulnérabilités complexes et produire des proofs of concept élaborés. Cela fonctionne non seulement sur du code source, mais dans certains cas aussi sur des fichiers binaires et du code compilé. Pour que les modèles contribuent efficacement à la vérification des logiciels, il convient notamment de respecter les points suivants :

• Trop de faux positifs surchargent les processus de développement. L’IA a tendance à détecter davantage de problèmes plutôt qu’à en détecter moins. Des investissements dans des processus de vérification, une automatisation du triage et des boucles de rétroaction sont donc nécessaires. Ce n’est qu’alors que les développeurs se voient transmettre des problèmes de sécurité et des défauts avérés qu’ils doivent corriger en priorité.
• Les modèles d’IA deviennent toujours plus rapides et plus performants. Chaque nouvelle génération de modèles représente un énorme pas vers plus de performance. Les entreprises doivent donc auditer leur code avec les modèles les plus récents pour tenir face à des attaquants qui utilisent, eux aussi, les versions les plus récentes.
• Les rapports de vulnérabilités générés doivent être strictement protégés. Les nouvelles failles de sécurité sont pour les cybercriminels une invitation à l’attaque. De tels rapports ne doivent donc être mis à la disposition que du personnel autorisé ou de modèles d’IA soumis à des droits d’utilisation stricts.

La vitesse exige de la gouvernance

Les cybermenaces, encore nettement amplifiées par l’IA, imposent des contrôles continus des logiciels. L’IA peut, de son côté, aider à examiner de grandes bases de code plus rapidement et avec plus de contexte. Sa valeur en matière de sécurité n’apparaît toutefois qu’une fois intégrée dans un processus contrôlé : règles d’accès claires, vérification indépendante, priorisation fondée sur les risques, tests reproductibles et voies de mise à jour fiables. Pour les fabricants de logiciels critiques, c’est en même temps une question produit très concrète. Les éditeurs qui relient analyse, développement, gestion des releases et communication client peuvent traduire plus vite les nouvelles connaissances en une protection résiliente. Ainsi, F5 remplace actuellement son rythme de publication trimestriel par des mises à jour plus fréquentes pour l’ensemble de ses logiciels. Pour les clients, la capacité à évaluer et à mettre en œuvre rapidement des mises à jour continues devient, en retour, une composante centrale de leur propre résilience.

Conclusion

L’IA ne rend pas les vulnérabilités automatiquement maîtrisables. Elle accélère plutôt le rythme auquel les défauts sont trouvés, évalués, puis potentiellement exploités, mais aussi corrigés. Pour les fournisseurs et les clients d’applications critiques, un processus de mise à jour continu, fluide et traçable gagne donc toujours en importance.

Vous souhaitez en savoir plus sur F5 et sur des stratégies efficaces contre les attaques fondées sur l’IA ? Nous nous réjouissons de votre visite sur notre stand 7A-531 pendant le salon it-sa à Nuremberg.

Questions fréquentes

Touchez une question pour afficher la réponse.

Pourquoi le contrôle logiciel classique ne suffit-il plus ?

Les applications combinent aujourd’hui de nombreux langages de programmation, bibliothèques, configurations et API. Analyses statiques et dynamiques, fuzzing et revues de code atteignent leurs limites d’échelle et de traitement du contexte sur les grandes bases de code. Beaucoup de résultats ne sont pas exploitables dans le contexte réel de l’application.

Quand un résultat de l’IA est-il considéré comme valide ?

Seulement lorsqu’une seconde voie de contrôle démontre de manière traçable son impact réel. Il peut s’agir d’un autre modèle, d’un test reproductible, de fuzzing ou d’une analyse manuelle. Le résultat passe ensuite à la correction priorisée.

À quelle fréquence les exploitants doivent-ils appliquer les correctifs ?

Selon F5, des correctifs trimestriels ne suffisent plus. Les mises à jour devraient intervenir au moins une fois par mois et, pour les applications critiques, dès que nécessaire. Entre-temps, la sécurité à l’exécution protège la production.

Pourquoi faut-il protéger les rapports de vulnérabilités ?

Un résultat valide décrit un chemin d’attaque possible. Des droits d’accès stricts, une journalisation traçable, des environnements de test isolés et des règles claires de diffusion font donc partie du processus de contrôle.

Sélection de la rédaction

À lireSécurité des API : le point aveugle derrière chaque intégration

Plus du réseau MBF Media

Digital ChiefsCRA impose aux fabricants de déclarer sous 24 heuresMyBusinessFutureLes fabricants signalent les incidents CRA à l’ENISA avant le CSIRTcloudmagazinQuand l’IA écrit 80 % du code, qui le vérifie ?

Source de l’image : Getty Images / 1169539468

Traduit de l’original allemand par intelligence artificielle. La version allemande fait foi.