Les logiciels évoluent en permanence, mais pas la validation de la sécurité. Cela crée un tel fossé que, dans les secteurs réglementés comme la banque, les cycles de publication ralentissent souvent, non pas parce que l'ingénierie ne peut pas aller plus vite, mais parce que la validation ne peut pas suivre.
Dans l'ensemble, l'industrie s'accorde à dire que les tests instantanés ne suffisent pas ; notre enquête auprès de 200 CISO et 200 leaders de l'ingénierie a révélé que 79 % craignent que des problèmes ne soient pas détectés entre les tests d'intrusion planifiés, tandis que 85 % affirment que les résultats sont obsolètes au moins parfois. Mais personne (du moins jusqu'à présent) ne s'accorde sur la manière dont le pentest continu le remplace en pratique.
Que signifie le pentest continu ?
Dans un récent fil de discussion Reddit, quelqu'un a posé une question apparemment simple :
« Quelqu'un fait-il réellement du pentest continu au lieu d'audits annuels ? »
Personne ne s'accordait sur ce que signifiait réellement le « pentest continu ». Dans un seul fil de discussion, le pentest continu a été interprété tantôt comme un « scan automatisé glorifié », tantôt comme des tests manuels complets effectués plus régulièrement. D'autres définitions incluaient des engagements réglementaires interminables, ou des tests par version axés sur les changements. Il y avait aussi un certain nombre de commentateurs mécontents qui avaient clairement été échaudés par des entreprises ayant commercialisé un véritable produit continu, pour finalement offrir quelque chose de complètement différent.
Avant d'entrer dans le vif du sujet, convenons de la définition que nous utiliserons pour le pentesting dans cet article. Exécuter des scans de vulnérabilité à chaque version n'est pas du pentesting. Un véritable test offensif exige de raisonner sur le comportement de l'application, d'explorer les workflows authentifiés, d'enchaîner les chemins d'attaque et de valider l'exploitabilité par le biais d'attaques réelles. Le pentest continu n'a de sens que si le test lui-même est pertinent.
Là où le pentesting humain atteint ses limites de scalabilité
Le bon réflexe est que le pentest continu devrait suivre les changements. Quand quelque chose change, validez-le. C'est souvent appelé « delta testing ».
Mais l'objection à cela, comme le souligne le fil de discussion ci-dessus, est que tout changement ne justifie pas un test, et qu'il peut être difficile de décider quels changements sont importants, comment fixer les prix en conséquence, comment utiliser au mieux les personnes pour qu'elles soient disponibles « à la demande » et comment s'assurer que l'on ne teste pas seulement du bruit.
Les pentesters ou les équipes rouges ont une créativité et un jugement que les outils de pentesting n'ont peut-être pas, mais ils sont confrontés à une situation difficile, qui ne cesse de s'aggraver. Le facteur limitant n'est pas leur qualité, c'est qu'ils ne sont pas capables d'appliquer cette réflexion à grande échelle, et à la vitesse à laquelle la surface d'attaque évolue.
Ils sont limités par le temps, ils doivent reconstruire le contexte autour du système chaque fois qu'ils le testent, et ce, sans prendre en compte la planification, la coordination et le reporting requis pour chaque pentest.
C'est là le point crucial ; un tel modèle basé uniquement sur la coordination humaine ne peut pas s'adapter à la vitesse de déploiement actuelle. C'est là que le pentest IA continu peut les aider.
Mais même avec l'IA, il y a des nuances. Continu ne signifie pas tout tester tout le temps – ce serait un énorme gaspillage de ressources. Ce n'est pas parce que vous pouvez le faire que vous devez le faire. Le pentest IA continu peut déterminer si un changement affecte de manière significative la surface d'attaque ou la posture de sécurité, et ne lancer des tests que lorsque c'est le cas.
L'arbitrage contraint entre couverture et profondeur
L'un des plus grands dilemmes pour les testeurs expérimentés est de décider de l'équilibre entre l'étendue et la profondeur. S'ils essaient de couvrir rapidement une grande surface d'attaque, ils se concentrent sur les classes de vulnérabilités courantes et les schémas d'attaque connus. Ils peuvent détecter un certain nombre de problèmes, mais ils auront moins de temps pour approfondir d'autres interactions, où des problèmes de plus grande gravité pourraient se cacher. À l'inverse, s'ils approfondissent plutôt, en se concentrant sur des chemins d'attaque complexes et des enchaînements de comportements à travers l'application, ils couvrent inévitablement moins le système dans son ensemble.
Les systèmes modernes aggravent ce problème car ils sont plus vastes, plus interconnectés et mis à jour plus fréquemment.
C'est pourquoi les vulnérabilités plus profondes telles que les failles logiques, les contrôles d'accès défaillants ou les chaînes d'exploitation en plusieurs étapes sont notoirement difficiles à détecter de manière cohérente. Dans nos recherches, plus de la moitié des leaders de la sécurité et de l'ingénierie affirment que les failles logiques plus profondes et les vulnérabilités en plusieurs étapes sont souvent manquées lors des engagements de pentesting traditionnels.
Ce n'est pas une critique des compétences des pentesters ; c'est le reflet des contraintes dans lesquelles ils opèrent.
Mais cela renforce également la même conclusion : la validation continue ne consiste pas seulement à tester plus souvent. Il s'agit d'obtenir la bonne couverture tout en le faisant.
Le pentest continu peut prendre en charge la dérive de la surface d'attaque afin que les équipes offensives expérimentées puissent se concentrer sur les joyaux de la couronne.
Le pentest continu a un problème d'architecture
De nombreux outils se concentrent sur le pentest automatisé et la génération d'attaques. Le véritable défi pour le pentest continu est de construire un système capable d'exécuter des tests offensifs en continu contre une application en constante évolution.
Avant tout, l'architecture doit permettre un contexte système suffisant. Cela implique une visibilité sur l'architecture applicative, les API, le code source et la configuration de l'infrastructure, afin que des chemins d'attaque réalistes puissent être explorés. Si un outil ne voit que les points d'accès exposés, il manquera les chemins d'attaque qui passent par la communication interne des services.
Deuxièmement, le système doit comprendre quand les tests doivent être exécutés. Cela signifie détecter les changements qui affectent réellement la surface d'attaque et déclencher les tests en conséquence. Sans cela, le pentest continu soit s'exécute constamment et gaspille des ressources, soit revient à des analyses planifiées qui manquent les changements introduisant des risques.
Troisièmement, les applications modernes impliquent des milliers d'interactions entre les rôles, les points d'accès et les services. Ces chemins doivent être explorés en parallèle plutôt qu'un par un. Un système qui teste séquentiellement ne finira jamais de valider une application moderne avant le prochain déploiement, de sorte que des composants importants resteront non testés.
Quatrièmement, les découvertes doivent être validées par une exploitation réelle pour s'assurer que les résultats reflètent des vulnérabilités réellement atteignables et reproductibles ; les équipes ont déjà trop de faux positifs à gérer, elles n'en ont pas besoin de plus.
Cinquièmement, le système doit boucler la boucle. La découverte continue n'a de sens que si les vulnérabilités peuvent être corrigées et vérifiées tout aussi rapidement. Cela signifie générer des recommandations de correction, valider les correctifs une fois appliqués et retester le système pour s'assurer que le problème est réellement résolu.
Et enfin, le système doit appliquer des limites d'exécution strictes, garantissant que les tests restent dans le périmètre et ne peuvent pas impacter des systèmes non liés (voir notre article sur la façon dont nous nous assurons que nos agents de pentest IA ne sortent pas du périmètre).
Sans aucun des points ci-dessus, le pentest continu devient à peine plus qu'une analyse automatisée.
Le modèle évolue
L'industrie ne doute pas que le pentesting doive évoluer. Mais le nouveau modèle est un peu flou. L'hésitation est compréhensible. Le pentesting traditionnel fonctionne toujours, il n'a simplement pas été conçu pour des logiciels qui changent constamment.
Nous savons qu'exécuter des scanners plus fréquemment ne résout pas le problème. Planifier plus de pentests non plus. La validation doit évoluer aussi souvent que le logiciel.
Mais il doit tester les bonnes choses lorsqu'elles changent, maintenir la profondeur attendue d'un véritable travail offensif, et s'assurer que la surface d'attaque ne dérive pas discrètement entre les évaluations.
Lorsque cela se produit, les équipes rouges peuvent se concentrer sur le travail qui requiert leur expertise : les chemins d'attaque complexes, les faiblesses systémiques et les joyaux de la couronne.
Le pentest continu ne remplace pas les équipes offensives, il leur offre une couverture qu'elles n'ont jamais eue.
Vous voulez voir à quoi ressemble le pentest continu en pratique ?
Aikido Infinite teste chaque changement significatif de votre application, explore les chemins d'attaque réels, valide l'exploitabilité et vérifie les correctifs avant que le code n'atteigne la production.
Commencez le pentesting en 5 minutes ou réservez une démonstration pour voir comment le pentest continu fonctionne réellement.
