AWS et son agent de sécurité, derrière le score de 89 %

TThéa

Alors, AWS a rendu Continuum généralement disponible. D’après The New Stack, le service recherche et valide des vulnérabilités dans les dépôts, les vérifie au regard de l’environnement AWS, puis propose des correctifs sous forme de demandes de modification que les équipes peuvent examiner. L’outil ne se limite donc pas à signaler un problème : il propose aussi un changement concret dans le code. Mais il faut distinguer cette capacité annoncée de la preuve qu’elle fonctionne dans tous les contextes. Les résultats mis en avant par AWS viennent d’un test précis, avec des règles précises, et ne résument pas à eux seuls le travail d’un service de sécurité dans une entreprise.

TThéa

CyberGym-E2E met l’agent face à des dépôts issus de 139 projets open source. Pour chaque tâche, il a 90 minutes pour repérer une faille, la reproduire, puis modifier le code pour empêcher le plantage sans faire échouer les tests existants. Le benchmark ne fournit pas à l’agent de description de la vulnérabilité, de preuve de concept, de journal de plantage ou de correctif existant. Le périmètre est cependant étroit : les tâches portent sur des problèmes de sûreté mémoire dans des programmes écrits en C ou en C++. Ce sont des vulnérabilités importantes, mais cela exclut d’autres langages et d’autres familles de failles. Bon, le test mesure donc une compétence réelle, dans une situation cadrée ; il ne permet pas de conclure que l’agent saura traiter toute vulnérabilité rencontrée par une équipe.

TThéa

Continuum a réussi 819 tâches sur 920, soit 89 %. Dans le cadre précis du benchmark, cela signifie qu’il a trouvé et reproduit une vulnérabilité, empêché le plantage et préservé la réussite des tests existants. Le score rassemble plusieurs étapes, et les résultats intermédiaires montrent où l’agent perd des points. Il a trouvé et reproduit un bug dans 92,5 % des tâches, arrêté le plantage dans 89,6 %, puis maintenu les tests existants en réussite dans 89,0 %. Le chiffre final ne signifie donc pas simplement que 89 % des vulnérabilités visées ont été corrigées. Il résume plutôt l’achèvement d’une chaîne de travail, depuis la découverte d’un défaut jusqu’à un correctif qui passe les vérifications prévues.

TThéa

La dernière vérification porte sur une vulnérabilité historique choisie pour le benchmark. Continuum ne savait pas laquelle était ciblée ; il devait simplement trouver et réparer une vraie faille dans le dépôt. Dans 37,8 % des tâches, son correctif a également éliminé cette vulnérabilité historique. C’est nettement moins que le taux global de 89 %, mais cela ne veut pas dire que les autres correctifs étaient inutiles : un même projet peut contenir plusieurs failles, et l’agent peut en traiter une autre que celle retenue pour la mesure. Sur ce critère précis, le précédent meilleur résultat public était de 26,2 %. La comparaison donne donc un repère encourageant, tout en montrant que le résultat dépend beaucoup de la question posée au benchmark : réparer une faille réelle, ou réparer précisément celle que les évaluateurs ont sélectionnée.

TThéa

Le test se limite aux bugs de sûreté mémoire en C et en C++. Il ne couvre donc pas d’autres langages ni d’autres types de vulnérabilités. La deuxième limite concerne le choix du résultat mis en avant. Le taux de 89 % mesure la réussite des tâches selon les critères du benchmark, tandis que la vulnérabilité historique ciblée a été corrigée dans 37,8 % des cas. Les deux chiffres répondent à des questions différentes, et il faut donc les présenter ensemble. Enfin, on ne sait pas encore comment Continuum se débrouille lorsqu’une équipe lui désigne une vulnérabilité précise et lui demande de la corriger. C’est une différence importante avec le benchmark, où l’agent ne connaît pas l’identité de la faille ciblée. Les performances dans cette situation précise restent inconnues.

TThéa

Il faut retenir deux choses à la fois. D’un côté, AWS présente un agent capable de repérer des vulnérabilités, de proposer un correctif et d’obtenir un bon résultat sur un test exigeant, avec 819 tâches réussies sur 920. De l’autre, ce résultat décrit un cadre limité et une définition particulière de la réussite : trouver et corriger une faille réelle, sans faire échouer les tests. Quand on demande si l’agent a corrigé la faille historique choisie par les évaluateurs, le taux est de 37,8 %, même si cette faille n’avait pas été indiquée à l’outil. Pour une équipe, le benchmark constitue donc un indice de capacité, pas une garantie que chaque vulnérabilité sera corrigée. L’évaluation décisive devra aussi porter sur des cas où les développeurs désignent eux-mêmes le problème à traiter.