Les agents de codage basés sur l’IA facilitent plus que jamais la création de logiciels. S’assurer que ces logiciels sont sécurisés avant leur déploiement est une autre affaire ; une question pour laquelle AWS estime que l’IA devrait également apporter son aide. À mesure que les entreprises adoptent des workflows de développement agentique, le volume de code propriétaire créé et modifié augmente rapidement. Pourtant, le processus consistant à valider les vulnérabilités, à déterminer si elles sont exploitables et à les corriger repose encore souvent sur le travail manuel des développeurs et des équipes de sécurité. AWS vise à remédier à ce déséquilibre avec Continuum, un service conçu pour détecter, analyser et corriger en continu les vulnérabilités dans les environnements d’entreprise, que le code soit le leur ou celui de tiers.
Plutôt que de se contenter de générer des alertes, le service est destiné à aider les entreprises à faire évoluer les résultats tout au long du cycle de vie de la remédiation, a écrit Chet Kapoor, vice-président d’AWS chargé de la sécurité et de l’observabilité, dans un billet de blog. Pour les applications propriétaires, Continuum analyse le code, vérifie si les vulnérabilités sont exploitables, générer des recommandations de remédiation et proposer des correctifs pouvant être examinés via les workflows de développement logiciel existants. Le but : aider ainsi les développeurs à résoudre les problèmes de sécurité sans que les équipes de sécurité aient à examiner manuellement chaque résultat, a déclaré M. Kapoor.
Une fois que les utilisateurs estiment que Continuum en sait suffisamment sur leur environnement et comprend leurs limites, ils peuvent le mettre dans ce qu’AWS appelle le « mode d’application » afin de corriger de manière autonome toute faille de code, a poursuivi M. Kapoor. Continuum emprunte certaines de ses fonctionnalités, notamment les tests d’intrusion et l’analyse de code, à un service existant, Security Agent. D’autres fonctionnalités sont entièrement nouvelles, notamment la modélisation des menaces, conçue pour générer automatiquement des modèles de menaces à partir du code source ou de documents de conception, et les exporter au format STRIDE.
Suivre le rythme du développement logiciel piloté par l’IA
Les analystes estiment que Continuum aidera les équipes de développeurs à livrer du code plus sécurisé tout en suivant le rythme des outils de codage basés sur l’IA. « Le plus grand défi ne consiste plus seulement à détecter les problèmes, mais à déterminer lesquels sont réels, lesquels ont une incidence dans leur environnement et lesquels doivent être corrigés en priorité », a souligné Akshat Tyagi, responsable adjoint de pratique chez HFS Research. « Les workflows traditionnels, articulés autour de tableaux de bord et d’un triage manuel, peinent à gérer un tel volume. Un tableau de bord peut afficher le carnet de commandes, mais il ne valide pas les résultats, n’évalue pas l’impact métier et n’aide pas à y remédier. » Selon M. Tyagi, la valeur ajoutée de Continuum « ne réside pas seulement dans une détection accrue, mais dans l’utilisation de l’IA pour hiérarchiser les résultats de risque, suggérer des mesures d’atténuation et favoriser une action plus rapide, tout en laissant aux humains le contrôle des décisions à haut risque ». Il devient de plus en plus important d’agir plus rapidement, car les attaquants ont désormais accès à bon nombre des mêmes capacités d’IA que celles utilisées par les entreprises pour accélérer le développement logiciel et les tests de sécurité, selon Amit Chandak, directeur de l’analyse chez le cabinet de conseil en informatique Kanerika. « Le délai entre la divulgation d’une faille et la mise au point d’un exploit fonctionnel se réduit rapidement, passant de plusieurs mois à quelques heures », a-t-il indiqué. Si Continuum peut réduire le travail répétitif des développeurs et des SRE, il pourrait également créer de nouvelles responsabilités pour les RSSI en matière de gouvernance, de supervision, de tests et de maintien des garde-fous pour les actions automatisées.
« Continuum fait évoluer le rôle du RSSI : il ne s’agit plus de gérer les résultats, mais de régir la manière dont ils sont traités. L’accent est désormais mis sur la définition de règles : ce qui peut être automatisé, ce qui nécessite une validation humaine, et quel niveau de risque est acceptable en production », a expliqué M. Tyagi. « La composition des équipes va également évoluer. Il y aura peut-être moins de tri manuel, mais un besoin accru de personnes capables de vérifier les correctifs générés par l’IA, de définir des garde-fous et de savoir quand ne pas faire confiance au système. » Malgré tout, M. Chandak ne s’attend pas à ce que cette offre entraîne des réductions immédiates d’effectifs, d’autant plus que Continuum n’est disponible que sous forme d’aperçu réservé. Continuum pourrait également changer la façon dont les RSSI évaluent leur travail, a expliqué M. Tyagi : « Le nombre de tickets importe moins. De meilleurs indicateurs sont la rapidité avec laquelle les risques réels sont validés et corrigés, le nombre de faux positifs éliminés, et la capacité de l’automatisation à réduire les risques sans causer de nouveaux problèmes. » Ces mêmes indicateurs pourraient également servir de référence aux RSSI pour déterminer le degré d’autonomie à accorder à des outils tels que Continuum, a déclaré M. Chandak. Les pratiques de la plupart des entreprises en matière de données et de gouvernance ne sont pas encore prêtes pour une correction entièrement autonome, a-t-il ajouté, précisant que « la conception de confiance graduelle d’AWS, dans le cadre de laquelle les entreprises ont la possibilité de choisir le degré d’autonomie, allant d’une intervention humaine à une correction entièrement automatique, est une reconnaissance de ce fait. »
Au-delà du code propriétaire
Continuum pourrait également aider les RSSI dans l’analyse des failles du code tiers, domaine dans lequel les entreprises ont souvent moins de visibilité et de contrôle. « La plupart des alertes de vulnérabilité tierces ne sont que du bruit. Un outil peut signaler une bibliothèque vulnérable, mais la vraie question est de savoir si ce code vulnérable est réellement utilisé en production. Si Continuum peut répondre à cette question, cela aide les équipes à se concentrer sur les quelques problèmes qui comptent », a rapporté M. Tyagi. « Cela s’avère particulièrement utile pour les risques liés à l’open source et à la chaîne d’approvisionnement logicielle, où les entreprises dépendent de paquets et de dépendances transitives cachées qu’elles ne peuvent pas toujours suivre entièrement. Cela s’avère également utile lorsqu’aucun correctif n’est encore disponible. »
Il a toutefois averti que Continuum pourrait ne pas offrir de solution directe pour le code tiers : « En général, vous ne pouvez pas appliquer vous-même de correctif au code tiers, car vous n’en êtes pas propriétaire ; la correction passe donc par le verrouillage de version ou la mise en place de contrôles compensatoires. »