MtoM Mag - Le journal de l'MtoM.

 1. De la divulgation d’une vulnérabilité à son exploitation : quelques heures suffisent désormais

Le délai entre la publication d’une vulnérabilité et son exploitation se réduit considérablement. Il y a encore six mois à un an, les cybercriminels avaient besoin de plusieurs jours pour développer une preuve de concept (PoC) exploitant une CVE critique. Aujourd’hui, quelques heures peuvent suffire. Les attaquants s’appuient notamment sur des essaims d’agents IA capables d’identifier à grande échelle les systèmes exposés. Ils ne ciblent d’ailleurs plus uniquement les failles critiques : en combinant plusieurs vulnérabilités moyennes ou faibles, ils peuvent parvenir à des résultats tout aussi dommageables. Face à cette accélération, les processus de remédiation traditionnels, souvent séquentiels et dépendants des équipes, deviennent trop lents. Les entreprises doivent donc évoluer vers une sécurité continue, fondée sur l’analyse automatisée du code, la priorisation des risques et la proposition de correctifs, tout en laissant au développeur la validation finale avant la mise en production.

 2. L’accumulation des vulnérabilités devient un point de rupture pour les équipes de sécurité

Les équipes de sécurité concentrent généralement leurs efforts sur les vulnérabilités critiques et élevées, faute de ressources suffisantes pour traiter l’ensemble des failles détectées. Les vulnérabilités moyennes ou faibles s’accumulent alors même que leur combinaison peut ouvrir la voie à des attaques particulièrement dommageables. L’intelligence artificielle peut accélérer leur détection, mais elle ne règle pas tout : ses résultats restent parfois variables et l’analyse du code peut être coûteuse. Elle risque aussi de générer un trop grand nombre de demandes de modification du code (pull requests), de faux positifs ou de corrections peu prioritaires, déplaçant ainsi le goulot d’étranglement vers les développeurs. L’enjeu sera donc de combiner deux approches : une analyse déterministe pour repérer les failles bien identifiées, comme les injections SQL, et l’IA pour détecter des problèmes plus complexes liés à la logique métier ou à la combinaison de plusieurs vulnérabilités. Cette complémentarité permettra de produire des résultats plus fiables sans saturer les équipes.

 3. L’AppSec évolue : les équipes devront piloter des agents IA plutôt que relire chaque ligne de code

Avec la généralisation du développement assisté par IA, les volumes de code générés pourraient être multipliés par 10 à 30. Une revue manuelle exhaustive ne sera donc plus réaliste. Le rôle des équipes de sécurité applicative (AppSec) va progressivement évoluer : elles devront configurer, superviser et orienter des agents IA chargés d’analyser le code. Pour être efficaces, ces agents devront toutefois comprendre le contexte des applications, leur architecture, leurs fonctionnalités et leur environnement d’exécution. C’est indispensable pour distinguer les vulnérabilités réellement exploitables des faux positifs. Les équipes devront également suivre les demandes de correction en attente et intervenir lorsque les développeurs contestent une détection. Enfin, la gestion des accès devra évoluer en parallèle : les secrets et jetons intégrés directement au code devront laisser place à des secrets à usage unique et à des autorisations temporaires, accordées au moment où elles sont nécessaires (Just-in-Time).

 4. Le Shadow AI fait émerger un nouveau risque : celui des agents autonomes incontrôlés

Le risque lié au Shadow AI ne concerne plus seulement l’utilisation d’outils d’intelligence artificielle non autorisés. Il s’étend désormais aux agents capables d’exécuter des actions de manière autonome, depuis les postes de travail comme dans les environnements de production. Or, les organisations ne savent pas toujours quels agents sont installés ni à quelles ressources ils ont accès. Certains peuvent consulter des fichiers, des courriels, des données sensibles ou des identifiants. Ils peuvent également être manipulés par des techniques de prompt injection, qui détournent leur comportement à l’aide d’instructions malveillantes. Un agent compromis pourrait ainsi transmettre des données à un site externe ou envoyer des messages frauduleux en usurpant l’identité d’un collaborateur. Pour reprendre le contrôle, les RSSI devront recenser les agents présents sur les terminaux et dans le cloud, surveiller leurs activités et limiter leurs accès. Des mécanismes comme les canary tokens, des jetons leurres qui déclenchent une alerte lorsqu’ils sont consultés, pourront également aider à détecter des accès non autorisés.

 5. Le nombre de vulnérabilités encore présentes en production devient un indicateur suivi par les conseils d’administration

En 2027, les conseils d’administration devraient accorder davantage d’attention au nombre de vulnérabilités qui subsistent dans les environnements de production. Cet indicateur devra diminuer régulièrement. S’il augmente, cela pourra révéler un manque de moyens pour détecter et corriger les failles, ou montrer que les impératifs de livraison prennent le pas sur la sécurité. Les dirigeants devront alors demander des explications et s’assurer que des mesures correctives sont engagées. La cybersécurité s’imposera ainsi de plus en plus comme un sujet de gouvernance à part entière. Les RSSI devront être en mesure de démontrer, trimestre après trimestre, que l’exposition de l’entreprise diminue grâce à des indicateurs concrets. Cette évolution ne devra toutefois pas conduire à négliger les menaces traditionnelles au profit des seuls risques liés à l’IA.

 6. Grâce à l’IA, le phishing devient plus personnalisé et beaucoup plus difficile à repérer

Les campagnes de phishing génériques, souvent reconnaissables à leurs formulations maladroites ou à leurs fautes, vont progressivement céder la place à des attaques beaucoup plus ciblées. Grâce à l’IA, les cybercriminels peuvent analyser les informations disponibles publiquement, notamment sur les réseaux sociaux et dans les publications professionnelles, pour dresser le profil de leurs victimes. Ils peuvent ainsi identifier les collaborateurs qui disposent d’accès sensibles, notamment aux systèmes financiers ou aux données stratégiques, et adapter leurs messages à leurs fonctions, leurs habitudes ou leurs centres d’intérêt. Le résultat est un hameçonnage ciblé (spear phishing) plus crédible et donc plus difficile à détecter. Ces messages peuvent également contenir des pièces jointes ou des liens malveillants destinés à compromettre un poste de travail ou à exfiltrer des données. Les entreprises devront donc adapter leurs dispositifs de protection à des attaques qui exploitent désormais autant la connaissance de la cible que la sophistication technique.

 7. Les équipes de sécurité devront devenir véritablement « AI Native »

D’ici fin 2027, les métiers de la cybersécurité et la composition des équipes devraient évoluer sensiblement. Les professionnels devront non seulement maîtriser les infrastructures, les réseaux, les pare-feu, les outils de protection des terminaux ou le DLP, mais aussi être capables de travailler avec l’IA, de comprendre le code et d’évaluer les solutions qui intègrent ces technologies. Ils devront également savoir intégrer l’IA dans leurs processus et superviser des agents autonomes. Cette transformation ne signifie pas pour autant que l’humain deviendra secondaire. L’IA peut analyser de grandes quantités de données, repérer des tendances et classer les risques, mais elle ne comprend pas toujours le contexte propre à une organisation ni les menaces qui n’ont pas encore été identifiées. La créativité, le recul critique et la capacité à sortir des schémas habituels resteront donc essentiels pour repérer les angles morts. L’objectif sera surtout d’automatiser les tâches répétitives afin de permettre aux équipes de se concentrer sur les menaces émergentes.

 8. Les clés API ne suffiront plus à établir une relation de confiance entre applications

Les intégrations entre services SaaS reposent encore largement sur des clés API ou des jetons OAuth pour authentifier les applications. Mais ces mécanismes ne garantissent plus, à eux seuls, un niveau de confiance suffisant. Lorsqu’une clé ou un jeton est volé, un attaquant peut se faire passer pour une application légitime et accéder aux ressources auxquelles elle est autorisée. La compromission d’un fournisseur peut ainsi avoir des conséquences sur l’ensemble de ses clients. Dans certains cas, un jeton d’accès déjà authentifié peut également permettre de contourner les mécanismes habituels d’authentification, y compris la MFA. Les entreprises devront donc aller au-delà de la simple vérification d’une clé ou d’un jeton et contrôler systématiquement l’identité de l’intégration, ses permissions et l’origine de la connexion. Cela passera notamment par des restrictions d’accès fondées sur les adresses IP autorisées, des jetons liés à une application précise et des identifiants à durée de vie limitée. En 2027, une clé API statique, sans contrôle supplémentaire, constituera un risque majeur : aucune application ne devra être considérée comme fiable par défaut.