Le pentest IA fait des vagues et rivalise avec la puissance des hackers humains de manières inattendues. Mais fréquemment, les entreprises recherchent le pentest pour obtenir et soutenir leurs certifications de conformité. Et la pression de le faire plus souvent est réelle. Selon le rapport 2026 sur l'état de l'IA dans le pentest d'Aikido Security, qui a interrogé 400 CISO et leaders de l'ingénierie senior, 79 % sont préoccupés par les vulnérabilités manquées introduites entre les tests planifiés.
Par le passé, les auditeurs ont rejeté les résultats des outils automatisés. Mais ce n'était pas parce qu'un humain devait s'asseoir et effectuer tous les tests, mais plutôt parce que ces anciens outils ne réalisaient rien qui s'approche de véritables pentests. Un pentest IA exécutant 250 agents orchestrés contre votre application correspond étroitement à la manière dont les pentesters humains effectuent leurs évaluations. Cela signifie explorer l'application, comprendre le fonctionnement des fonctionnalités, trouver des moyens de les contourner et valider que le problème est réellement exploitable avant de l'inclure dans le rapport.
Les véritables pentests IA sont aujourd'hui régulièrement acceptés par les auditeurs. Dans cet article, nous aborderons les idées fausses sur le pentest IA et sa relation avec la conformité, et expliquerons comment et quand vous pouvez utiliser le pentest IA pour répondre à vos exigences de conformité.
{{cta}}
De quoi avez-vous réellement besoin pour un pentest de conformité ?
Lorsqu'un auditeur demande un test d'intrusion, il demande une documentation attestant que votre application a été testée contre un ensemble défini de vecteurs d'attaque et de méthodologies de test, que les résultats ont été validés et enregistrés, et que vous disposez d'un plan de remédiation pour tout élément critique. La question n'est pas de savoir si c'est un humain qui a passé deux semaines devant un terminal ou des agents IA qui y ont passé une journée. Il est également vrai que l'infrastructure évoluait beaucoup plus lentement par le passé, avec des releases trimestrielles, de sorte que l'idée d'effectuer des tests d'intrusion hebdomadaires était plutôt absurde. Ce n'est absolument plus le cas aujourd'hui.
Les frameworks les plus courants qui exigent ou recommandent le pentest sont SOC 2, ISO 27001, HIPAA et PCI DSS. Pour la plupart d'entre eux, aucun n'exige explicitement qu'un humain ait mené le test. Ce qu'ils spécifient, c'est la couverture, la méthodologie et la documentation. PCI DSS est moins direct — ses directives définissent le test d'intrusion comme « une démarche essentiellement manuelle » et stipulent que les outils automatisés seuls ne satisfont pas à l'exigence (nous examinerons plus tard ce que cela signifie pour le pentest IA).
Examinons SOC 2. Le framework n'impose pas du tout le pentest. Ce qu'il exige, c'est que vous démontriez l'efficacité de vos contrôles, notamment en matière d'accès logique (CC6.1), de gestion des changements (CC8.1) et d'atténuation des risques (CC7.1 à CC7.4). Les auditeurs ont opté pour le pentest comme moyen le plus crédible de prouver ces contrôles, car il démontre que quelqu'un a réellement tenté de les contourner. Un rapport de pentest qui associe les résultats à ces critères, documente ce qui a été testé et montre la remédiation de tout élément critique, est ce qui satisfait à l'exigence. Il s'avère que le framework ne dit rien sur qui ou quoi a mené le test.
ISO 27001 suit un schéma similaire, recommandant le pentest dans le cadre de l'évaluation continue des risques.
Historiquement, HIPAA a considéré le pentest comme une bonne pratique plutôt qu'une exigence stricte, mais cela est en train de changer. En décembre 2024, le HHS a proposé des mises à jour de la règle de sécurité HIPAA qui rendraient les tests d'intrusion annuels obligatoires pour toutes les entités couvertes et les partenaires commerciaux, les tests devant être effectués par du personnel qualifié possédant des connaissances appropriées en cybersécurité. Cette règle devrait être finalisée d'ici mi-2026. Si vous êtes dans le secteur de la santé, vérifiez directement auprès de votre équipe de conformité le statut actuel.
Tous les frameworks exigent un rapport structuré comprenant un résumé exécutif, une section méthodologique, des résultats validés avec preuves et étapes de reproduction, des évaluations de gravité et des conseils de remédiation. L'OWASP Web Application Security Testing Guide est la référence que la plupart des testeurs suivent pour la couverture (et c'est une longue liste). Même une équipe humaine travaillant avec un budget d'une semaine ne peut pas, de manière réaliste, tout parcourir en profondeur. Ils doivent trier et prioriser les éléments les plus importants. La fréquence et l'étendue sont des contraintes qui ne limitent plus notre périmètre de test.
L'hypothèse selon laquelle le pentest de conformité signifie un pentest humain n'est pas inscrite dans la plupart des frameworks. Cela a été vrai par défaut car, jusqu'aux LLM, aucune technologie ne pouvait s'en approcher. Pour les équipes des secteurs fortement réglementés avec des exigences de conformité spécifiques, il est utile d'avoir cette conversation directement avec votre auditeur. Pour la plupart, cependant, le rapport ne soulèvera aucun drapeau. Le pentest IA couvre les exigences.
Faites défiler la page jusqu'à la fin de l'article pour en savoir plus sur le fonctionnement détaillé des tests d'intrusion basés sur l'IA avec différents frameworks.
Ce que recherchent les auditeurs
En résumé, les auditeurs ou les normes recherchent en réalité les éléments suivants lors d'un test d'intrusion :
- Une méthodologie documentée et reproductible, et non pas des essais aléatoires
- L'indépendance, et le fait que l'équipe chargée des tests ne soit pas la même que celle qui développe ou exploite le système
- Des tests d'efficacité concrets, allant au-delà de l'analyse automatisée des vulnérabilités
- Les éléments de preuve, tels que les constatations, la gravité et les preuves
- Mesures correctives et nouveaux contrôles des résultats constatés
Si votre test d'intrusion répond à ces critères, qu'il soit réalisé par une IA ou par un humain, il y a de fortes chances que votre auditeur l'accepte.
Où le pentest IA apporte déjà des résultats pour la conformité
Pistes d'audit
La piste d'audit d'un pentest IA est exhaustive et détaillée, souvent meilleure que de nombreux rapports de pentest humains. Chaque requête envoyée, chaque charge utile tentée, chaque action effectuée par chaque agent est enregistrée. Vous pouvez voir exactement ce qui a été testé, comment le test a été mené et ce qui a été trouvé. La plupart des rapports de pentest humains vous fournissent des résultats et une section méthodologique. Ils ne vous donnent pas une trace complète de chaque étape effectuée. Si votre auditeur demande : « Comment savons-nous qu'ils ont testé X ? », le rapport généré par un pentest IA peut effectivement montrer le journal pour cette chose exacte.
Couverture des tests
Le pentest IA couvre un terrain significatif. Pour ceux qui demandent : « Comment savons-nous qu'il a tout essayé ? », la préoccupation s'applique également aux pentesters humains. Un rapport de pentest manuel qui revient avec zéro résultat et aucune piste d'audit de ce qui a été testé est entièrement pris sur la foi. Une sorte de servitude au rituel du test d'intrusion annuel existe. Vous ne pouvez de toute façon pas prouver qu'un humain a tout essayé. Avec un pentest IA, vous pouvez énumérer une couverture de test détaillée via les journaux.
Les agents peuvent traiter l'intégralité du Top 10 OWASP en quelques heures. Ils testent les contrôles d'autorisation sur chaque point d'accès, et pas seulement sur un échantillon représentatif. Ils essaient chaque vecteur d'attaque sur chaque fonctionnalité, et pas seulement ceux qu'un testeur humain a eu le temps d'atteindre avant la fin de l'engagement.
Les IA améliorent de façon exponentielle leur capacité à raisonner et à comprendre le code. Elles découvrent de nouvelles vulnérabilités dépendantes du contexte que les humains ont manquées pendant des années. Les sceptiques supposent que les IA ne peuvent pas gérer les vulnérabilités de la logique métier. Ce n'est plus le cas. En pratique, les agents lisent la base de code, comprennent le comportement attendu et trouvent des moyens créatifs de le contourner. L'expression « Si tout ce que vous avez est un marteau, chaque problème ressemble à un clou » est pertinente ici. Même si un testeur humain est très doué pour trouver des vulnérabilités XSRF et gagne une prime de bug à six chiffres, la vérité est que le test par IA apporte une multitude d'approches à la tâche.
Lors du benchmark comparatif d'Aikido Security sur quatre applications web non triviales, les agents IA ont découvert deux fois plus de vulnérabilités de contrôle d’accès défaillant que les testeurs humains expérimentés. Ils ont également mis au jour une falsification de signature électronique dans une application de paiement que les testeurs manuels n'avaient pas du tout détectée. Les IA avaient certes un avantage considérable car elles avaient accès au code source. Une IA assimile une base de code complète presque instantanément, tandis que les testeurs humains travaillent généralement sans elle pour des raisons logistiques et de NDA. Mais les tests boîte blanche, boîte grise ou boîte noire sont clairement améliorés par le parallélisme qu'apporte le pentest agentique.
Le benchmark a également révélé que les testeurs humains étaient plus performants pour sonder les durcissements de configuration insuffisants et identifier les contrôles d'hygiène de conformité. Depuis lors, le pentest IA n'a cessé de s'améliorer. Le pentest IA d'Aikido, par exemple, détecte régulièrement des vulnérabilités IDOR complexes, qui impliquent de s'authentifier en tant qu'utilisateurs réels et de suivre de longs workflows de bout en bout.
Les intégrations tierces, en particulier les flux OAuth complexes et les implémentations SSO, sont plus difficiles à gérer de manière cohérente pour les agents. Le pentest IA d'Aikido a fourni les efforts nécessaires pour résoudre ces problèmes, mais ne tenez pas pour acquis que tous les produits de pentest IA peuvent le faire.
Rapports
Le format du rapport correspond directement aux besoins des équipes de conformité. SOC 2 et ISO 27001 reçoivent un PDF complet avec des preuves, des conseils de remédiation détaillés et des étapes de reproduction pour les re-tests après l'application des remédiations. Les exigences HIPAA sont couvertes.
Les délais d'exécution pour le pentest IA sont de l'ordre de quelques heures (certainement moins d'une journée), ce qui est très utile lorsque vous êtes dans un calendrier de certification ou que vous répondez à une demande d'audit incluant des actifs dans le périmètre qui n'ont pas été testés auparavant.
Que ne peut pas faire le pentest IA pour la conformité ?
Bien que les pentests IA soient de plus en plus acceptés, la technologie est encore assez nouvelle, et certaines industries et leurs régulateurs sont encore en train de définir leur position sur la question.
PCI DSS est plus normatif que SOC 2 ou ISO 27001 et exige explicitement des tests d'intrusion au moins une fois par an, avec une couverture spécifique des environnements de données de titulaires de carte. Ses directives officielles pour le pentest, mises à jour pour la dernière fois en 2017, décrivent le test d'intrusion comme « essentiellement une tâche manuelle » et stipulent que l'exécution d'outils automatisés seuls ne satisfait pas à l'exigence. L'esprit de l'exigence a toujours été axé sur l'exploitation active, les preuves validées et le jugement appliqué aux résultats. Les pentesters humains peuvent utiliser le pentest IA comme un outil pour gérer une grande partie du travail lourd côté application. Cela dit, PCI DSS exige également des tests de la couche réseau et de segmentation en plus des tests de la couche applicative, que le pentest IA ne couvrira de toute façon pas.
Pour certaines exigences des régulateurs des services financiers ou du secteur gouvernemental, les entreprises devront vérifier directement auprès de leur auditeur afin d'évaluer leur ouverture à considérer la surveillance continue et les tests non seulement comme équivalents aux tests ponctuels, mais comme une preuve significativement supérieure des contrôles de sécurité et de la rigueur du programme.
FedRAMP, qui s'applique aux fournisseurs de services cloud vendant aux agences fédérales américaines, exige que les évaluations soient menées par des organisations d'évaluation tierces accréditées (3PAO). Les RFC récents pour FedRAMP 20x, cependant, indiquent que le programme s'efforce de trouver des moyens de moderniser son approche pour la vérification des solutions SaaS afin de protéger les infrastructures critiques et les applications et services gouvernementaux.
Les tests de sécurité physique et l'ingénierie sociale sont totalement hors périmètre (les tests de phishing sont requis pour FedRAMP). Nous sommes encore loin d'avoir des pentesteurs IA qui se promènent en tournant les poignées de porte pour voir si elles sont verrouillées et en envoyant des e-mails de phishing (probablement pour le mieux).
Il est plus probable que nous voyions des cabinets accrédités tirer parti du pentest IA de manière ciblée comme outils, plutôt que comme des remplacements complets pour leur reconnaissance et leur pentesting. Aujourd'hui, les pentests IA peuvent être utilisés dans un modèle de partenariat où un cabinet accrédité examine et cosigne le travail et les artefacts de test. Cette approche mérite d'être explorée si vous opérez sur l'un ou l'autre de ces marchés.
Les auditeurs ne rejettent-ils pas les outils de pentest IA comme de simples scanners ?
L'objection la plus courante ne concerne même pas le pentest IA. Le problème, ce sont les scanners automatisés qui se font passer pour du pentest IA.
Pendant des années, des organisations moins scrupuleuses ont tenté de faire passer la sortie de scanners de vulnérabilités basiques pour un rapport de pentest. Des outils comme Nessus ou OpenVAS produisent de longues listes de problèmes signalés avec des niveaux de gravité qui semblent crédibles sur le papier, mais rien n'a été validé, exploité ou contextualisé. Ils confondent le concept d'une vulnérabilité possible avec un chemin d'attaque démontrable. Les auditeurs en ont vu suffisamment pour être sceptiques face à tout ce qui ressemble à un scan déguisé en pentest. Vous devez donc vous assurer que votre pentest IA est véritablement du pentest IA, plutôt qu'un scanner ou un DAST maquillé en IA.
Un véritable pentest IA exploite et confirme réellement les vulnérabilités sur une cible réelle avant de les présenter dans un rapport. Vous pouvez faire la différence dans le langage et les détails du rapport. Les découvertes validées sont accompagnées de preuves de preuve de concept et d'étapes de reproduction montrant comment l'exploit a été réellement exécuté, tandis que les découvertes de scanner non validées décrivent simplement un problème potentiel avec un niveau de gravité générique et n'incluent aucune preuve que quoi que ce soit ait été réellement tenté. Si un rapport revient avec des centaines de découvertes et qu'aucune d'entre elles ne montre de preuve d'exploitation, vous avez probablement affaire à un scanner, indépendamment de ce qui est écrit sur l'emballage.
Cela nous ramène à ce que nous disions à propos de PCI DSS. Le langage de 2017 décrivant le pentest comme « essentiellement une tâche manuelle » a été rédigé spécifiquement pour aborder la question des organisations soumettant la sortie de scanner comme rapport de pentest. Les directives traçaient une ligne contre cette pratique, sans anticiper un monde où les agents IA exploitent et valident activement les découvertes comme le font les testeurs humains. Bien que les pentests IA ne couvrent pas toutes les exigences de pentest PCI DSS (comme les tests de la couche réseau et de segmentation), les outils de pentest IA peuvent aider les organisations à effectuer des pentests applicatifs plus efficacement, et nous pourrions voir ces réglementations mettre à jour leur formulation à l'avenir pour aborder cette nuance. L'industrie a tendance à évoluer plus rapidement que les cadres de conformité.
Conformité continue
Au-delà de la simple case à cocher de la conformité, le pentesting ponctuel ou instantané est un modèle défaillant pour tout ce qui déploie du code plus régulièrement qu'une fois par an.
Un pentest annuel vous indique à quoi ressemblait votre application le jour ou la semaine où le test a été exécuté. Mais votre équipe de développement a probablement poussé de nouvelles modifications dès le lendemain. Trois mois plus tard, le rapport de conformité est toujours valide sur le papier, mais votre surface d'attaque a considérablement changé. Les 85 % des CISO et des leaders de l'ingénierie interrogés dans notre enquête qui déclarent que les découvertes sont obsolètes au moins parfois n'ont pas tort concernant leur situation. Le décalage est palpable et à haut risque.
Le pentest continu transforme votre assertion ponctuelle en un enregistrement vivant. Au lieu de dire à un auditeur « nous avons effectué un pentest sur les actifs de production en mars », vous pouvez lui montrer un historique des tests de sécurité qui se trouve juste à côté de votre historique de déploiement. Et pas seulement en production, mais aussi dans les environnements inférieurs. Chaque modification impactant votre surface d'attaque a été testée, de sorte que les problèmes ont été détectés et corrigés avant qu'ils n'atteignent la production.
Les banques et les industries fortement réglementées sont actuellement contraintes de ralentir les cycles de publication, spécifiquement pour faire pentester les fonctionnalités avant leur déploiement. Le pentest IA continu change cela, car les tests s'exécutent en phase avec votre cadence de déploiement, vérifiant uniquement ce qui a changé, de sorte que les publications n'ont pas à attendre les revues de sécurité.
Découvrez à quoi ressemble un pentest IA de qualité audit
Les auditeurs vérifient qu'un test a eu lieu, qu'il a suivi une méthodologie de test définie, que les découvertes des tests ont été documentées avec des preuves, et que les problèmes critiques ont été traités. Un rapport de pentest IA satisfait toutes ces exigences. Les cadres qui définissent ce qui constitue un rapport de test et un artefact de conformité ne spécifient pas qui ou quoi a exécuté le test.
Si vous travaillez à la conformité SOC 2, ISO 27001, HITRUST, ou une certification similaire et que vous voulez voir à quoi ressemble le rapport avant de vous engager, vous pouvez demander un rapport d'exemple ou exécuter un scan de fonctionnalités sur votre application. La plupart des équipes constatent que le format du pentest IA ne surprend pas du tout leurs auditeurs.
Chez Aikido, nous avons constaté de très bons résultats avec nos clients utilisant le pentest IA pour la conformité. Bien que nous nous engagions à effectuer un pentest manuel si votre pentest IA est rejeté par un auditeur, jusqu'à présent, nous n'avons pas vu cela se produire. Contactez-nous dès aujourd'hui pour débloquer un pentesting rapide et conforme dès aujourd'hui.
Annexe : Particularités du secteur
Secteur financier
PCI DSS
Exigence : la norme PCI DSS constitue le cadre le plus contraignant en la matière. Elle impose une méthodologie documentée de tests d’intrusion, la réalisation de tests d’intrusion internes et externes au moins une fois par an et après toute modification importante, la vérification des corrections apportées, ainsi que des tests distincts des contrôles assurant la segmentation de l’environnement des données des titulaires de cartes (plus fréquents pour les prestataires de services). Le test doit être réalisé par un testeur qualifié, indépendant sur le plan organisationnel des systèmes testés.
Les tests autonomes peuvent-ils répondre à cette exigence ? Non. Les directives du PCI relatives aux tests d’intrusion établissent une distinction claire entre un test d’intrusion et un scan de vulnérabilités : un scan est automatisé, tandis qu’un test d’intrusion est un processus manuel d’exploitation qui repose sur les compétences d’un testeur qualifié et indépendant. Les outils automatisés peuvent apporter une aide, mais les directives considèrent que le travail manuel constitue le test lui-même. Un test d’intrusion autonome ne sera pas accepté comme test d’intrusion PCI.
Les outils Aikidoexploitent effectivement la logique métier, les failles BOLA et les failles en chaîne ; il est donc judicieux de les exécuter dans le cadre de tests de sécurité continus aux interventions obligatoires, y compris après des modifications importantes. Il s’agit là d’un avantage en matière de sécurité et d’une source de preuves de correction, et non d’une validation PCI. Prévoyez séparément un test d’intrusion humain qualifié.
Conclusion : ne répond pas aux exigences. Le test d'intrusion doit être réalisé par un testeur humain qualifié. Les tests automatisés ne seront pas acceptés comme test d'intrusion PCI.
Référence : Norme PCI DSS v4.0.1, exigence 11.4 (11.4.1 à 11.4.6) ; Guide du PCI SSC sur les tests d'intrusion.
DORA
Les exigences : la loi DORA prévoit deux niveaux de tests. Le niveau général consiste en un programme de tests de résilience opérationnelle numérique que chaque entité financière doit mettre en place, et les tests d'intrusion font partie des méthodes qu'elle doit utiliser. Le niveau avancé impose aux entités financières importantes de réaliser des tests d'intrusion axés sur les menaces (TLPT) au moins une fois tous les trois ans, avec des règles strictes concernant les personnes autorisées à les mener.
Les tests autonomes peuvent-ils répondre à cette exigence ? Oui pour le programme général, non pour le TLPT. Le programme général offre une grande souplesse en matière de méthodes et inclut notamment les tests d’intrusion ; les tests autonomes continus y sont donc adaptés et vont au-delà du minimum périodique requis. Le TLPT est différent. Il s’inspire du cadre TIBER-EU de la BCE et exige le recours à des « red-teamers » externes qualifiés ainsi qu’à un prestataire externe spécialisé dans le renseignement sur les menaces, les établissements de crédit importants étant tenus de faire appel exclusivement à des testeurs externes. Il s’agit donc, de par sa conception, d’une intervention humaine de type « red team ».
Conclusion : Oui pour le programme de tests général. Il ne répondra pas aux exigences du TLPT, qui impose le recours à des testeurs externes jouant le rôle d’adversaires (red team). Utilisez Aikido exécuter et documenter le programme général. Le TLPT constitue une mission distincte qui doit être réalisée par des personnes physiques.
Référence : DORA (règlement (UE) 2022/2554), articles 24 et 25 (programme d'essais), articles 26 et 27 (TLPT).
Règle de la FTC relative aux mesures de protection
Exigence : la règle « Safeguards Rule » de la FTC régit la manière dont les établissements financiers protègent les informations de leurs clients. Elle impose de tester régulièrement l'efficacité de vos mesures de sécurité et vous propose deux méthodes pour ce faire : surveillance continue ou, à défaut, un test d'intrusion annuel assorti d'évaluations de vulnérabilité au moins tous les six mois. Des tests sont également requis à la suite de changements majeurs apportés aux opérations.
Les tests autonomes peuvent-ils répondre à cette exigence ? Oui. surveillance continue présentée comme une alternative directe au test d’intrusion annuel, ce que permettent justement les tests autonomes continus. Pour un établissement qui préfère une approche périodique, un seul programme autonome permet de réaliser à la fois le test annuel et les évaluations semestrielles. La règle n’impose aucune exigence en matière de personnel ni d’accréditation pour le testeur.
Conclusion : Oui. surveillance continue clairement le test d'intrusion annuel.
Référence : Règle relative aux mesures de protection de la FTC, 16 CFR 314.4(d) et 314.4(d)(2).
Réglementation du NYDFS en matière de cybersécurité
Exigence : la réglementation new-yorkaise en matière de cybersécurité dans le secteur des services financiers s'applique aux banques, aux assureurs et aux autres entités titulaires d'une licence dans l'État de New York ; elle sert de référence au-delà des frontières de l'État en tant que norme de base pour le secteur financier. Sa section consacrée aux tests d'intrusion impose la mise en place de tests articulés autour de votre évaluation des risques, organisés soit sous la forme surveillance continue sous la forme d'un test d'intrusion annuel accompagné d'évaluations de vulnérabilité semestrielles.
Les tests autonomes peuvent-ils répondre à cette exigence ? Oui. À l'instar de la règle de la FTC, le règlement considère surveillance continue le test d'intrusion annuel comme des alternatives. Les tests autonomes continus s'inscrivent dans la voie de la surveillance continue, et pour les entités qui optent pour la voie périodique, ils donnent également lieu au test annuel et aux évaluations semestrielles. Le règlement n'impose aucune exigence d'accréditation des testeurs.
Conclusion : Oui. surveillance continue à elle seule surveillance continue cette exigence.
Référence : Règlement du NYDFS sur la cybersécurité, 23 NYCRR 500.5 (deuxième amendement, 2023).
Secteur de la santé
HIPAA
L'exigence : la règle de sécurité de la loi HIPAA ne mentionne pas explicitement les tests d'intrusion. Sa norme d'évaluation impose une évaluation périodique, tant technique que non technique, de vos mesures de sécurité, ce qui correspond généralement au cadre dans lequel s'inscrivent les tests d'intrusion. Une proposition de mise à jour datant de décembre 2024 rendrait cette exigence explicite, en imposant un scan de vulnérabilités au moins tous les six mois et des tests d'intrusion au moins une fois par an. À la mi-2026, cette mise à jour n'est pas encore définitive, mais l'orientation est claire.
Les tests autonomes peuvent-ils répondre à cette exigence ? Oui. Ni la norme d'évaluation actuelle ni la mise à jour proposée n'imposent le recours à un testeur humain. Un rapport autonome constitue aujourd'hui la preuve d'une évaluation technique périodique, et il permettrait demain de satisfaire à l'obligation proposée de test d'intrusion annuel, les tests continus dépassant une fréquence annuelle.
Conclusion : Oui, et prêt pour le projet de règlement.
Référence : Règle de sécurité HIPAA, 45 CFR 164.308(a)(8) ; projet de règlement de 2024 (RIN 0945-AA22).
HITRUST CSF
Exigence : le HITRUST CSF est un référentiel certifiable utilisé par les organismes de santé américains et leurs fournisseurs pour démontrer la protection des informations de santé protégées (PHI). Les tests d’intrusion font partie intégrante de ses exigences en matière de conformité technique et d’évaluation de la sécurité. Pour obtenir la certification de niveau supérieur (r2), les tests doivent s’inscrire dans une période glissante de 12 mois et s’inscrire dans le cadre d’un programme continu plutôt que d’un événement annuel ponctuel ; les résultats doivent faire l’objet d’un suivi et faire l’objet de nouveaux tests.
Les tests autonomes peuvent-ils répondre à cette exigence ? Oui, HITRUST n'exige pas la présence d'un testeur humain ou agréé pour le test d'intrusion, et sa préférence pour un programme continu plutôt que pour un événement annuel s'inscrit dans la logique des tests autonomes continus. Un rapport de test d'intrusion autonome constitue une preuve valable pour l'évaluateur.
Conclusion : Oui, en ce qui concerne l'exigence relative aux tests d'intrusion. La validation par l'évaluateur externe constitue une étape d'audit distincte.
Référence : contrôle 06.h du cadre de conformité HITRUST (vérification de la conformité technique).
Recommandations de la FDA en matière de cybersécurité avant la mise sur le marché
Exigence : le guide de la FDA intitulé « Cybersécurité des dispositifs médicaux : considérations relatives au système qualité et contenu des dossiers de demande d'autorisation de mise sur le marché » recommande une approche de tests de sécurité à plusieurs niveaux, mais exige en pratique la présentation d'un rapport de test d'intrusion lors du dépôt des dossiers de demande d'autorisation de mise sur le marché.
Les tests autonomes peuvent-ils répondre à ces exigences ? Oui. Les recommandations sont axées sur les résultats : elles exigent des preuves attestant que les tests ont bien été effectués, en précisant qui les a réalisés, quelle était leur portée, ce qui a été détecté et, surtout, quelles mesures ont été prises en conséquence. En fin de compte, l’objectif est de s’assurer que les risques liés à la sécurité sont maîtrisés. Le rapport de test d’intrusion basé sur l’IA Aikidorépond à ces attentes.
Conclusion : Oui, mais précisez dans votre dossier la portée du document, les méthodes utilisées et son caractère indépendant.
Référence : section 524B de la loi FD&C ; lignes directrices de la FDA relatives à la cybersécurité avant la mise sur le marché (2025).
Règlement de l'UE sur les dispositifs médicaux (MDR)
Exigence : les exigences générales de sécurité et de performance du RDM prévoient que les logiciels destinés aux dispositifs médicaux soient développés selon l’état de l’art, et qu’ils fassent l’objet d’une vérification et d’une validation, ainsi que de mesures minimales de sécurité informatique tout au long du cycle de vie du produit. Les lignes directrices de l’UE sur la cybersécurité des dispositifs médicaux (MDCG 2019-16) mentionnent les tests d’intrusion comme faisant partie intégrante de cette vérification et validation, au même titre que les tests des fonctionnalités de sécurité, le fuzzing et l’analyse des vulnérabilités.
Les tests autonomes peuvent-ils répondre à cette exigence ? Oui. Le règlement MDR et ses lignes directrices ne prescrivent aucune méthode particulière, et un test d’intrusion autonome constitue une preuve valable de vérification et de validation. Les tests continus s’inscrivent également mieux dans l’approche axée sur le cycle de vie qu’un test ponctuel. À l’instar des lignes directrices de la FDA, il s’agit en fin de compte de démontrer que les risques pour la sécurité sont maîtrisés.
Conclusion : Oui.
Référence : Règlement (UE) 2017/745 (MDR) de l’UE, annexe I, GSPR 17.2 et 17.4 ; lignes directrices MDCG 2019-16.
IEC 81001-5-1
Exigence : Il s’agit de la norme relative au cycle de vie sécurisé des logiciels de santé, qui sera harmonisée avec le RDM. Les activités de test des systèmes logiciels qu’elle prévoit comprennent les tests des exigences de sécurité, les tests d’atténuation des menaces, les tests de vulnérabilité et les tests d’intrusion. La norme exige que les tests d’intrusion soient réalisés par un service ou un organisme indépendant des développeurs, et elle comporte une disposition distincte concernant la gestion des conflits d’intérêts entre les testeurs et les développeurs.
Les tests autonomes peuvent-ils répondre à cette exigence ? Oui, et cette exigence d'indépendance joue en votre faveur. Ce que la norme exige, c'est une indépendance organisationnelle vis-à-vis des développeurs, et non vis-à-vis d'un testeur humain. En tant que tiers externe, Aikido cette exigence d'indépendance, tandis que la méthodologie autonome et la piste d'audit fournissent l'activité documentée et reproductible attendue par la norme.
Conclusion : Oui, l'indépendance vis-à-vis des tiers répond à cette exigence.
Référence : norme CEI 81001-5-1:2021, clauses 5.7.4 (correspondant à la norme SVV-4) et 5.7.5.
Automobile
ISO/SAE 21434
Exigence : la cybersécurité automobile repose sur la norme ISO/SAE 21434, norme technique relative à la cybersécurité des véhicules, ainsi que sur sa méthodologie de gestion des risques et sur l’analyse des menaces et l’évaluation des risques (« TARA »). Cette norme désigne les tests d’intrusion comme un moyen de vérifier que les objectifs de cybersécurité ont été atteints.
Les tests autonomes peuvent-ils répondre à cette exigence ? Oui, pour les parties auxquelles ils ont accès. La norme est axée sur les résultats. Les tests d’intrusion constituent l’une des nombreuses méthodes de validation (par exemple, le fuzzing, SAST, DAST, etc.), et un rapport de test d’intrusion autonome constitue une preuve valable, les tests continus s’inscrivant également dans la logique du cycle de vie. Une mise en garde toutefois : les véhicules reposant sur des composants embarqués, les tests de sécurité physique au niveau matériel ne peuvent pas être effectués à l’aide de méthodes autonomes.
Conclusion : Oui, en ce qui concerne la surface d'attaque connectée et back-end. La norme offre une grande souplesse en matière de méthodes et accepte les tests autonomes comme preuve de validation.
Référence : norme ISO/SAE 21434:2021 relative à la validation de la cybersécurité (clause 11, RQ-11-01).
Gouvernement et secteur public
ENS
Exigence : le « Esquema Nacional de Seguridad » espagnol mentionne explicitement les tests d'intrusion parmi les mesures de sécurité. Ceux-ci sont obligatoires pour les systèmes de catégorie élevée et recommandés pour ceux de catégorie moyenne ; les résultats récents alimentent l'audit périodique prévu par ce cadre réglementaire.
Les tests autonomes peuvent-ils répondre à cette exigence ? Oui. L'ENS précise que ce sont les tests qui comptent, et non la personne qui les effectue. Les résultats des tests d'intrusion autonomes satisfont à cette exigence, et les tests continus dépassent les fréquences recommandées (annuelle pour le niveau « élevé » et bisannuelle pour le niveau « moyen »).
Conclusion : Oui, les tests d'intrusion autonomes répondent à cette exigence.
Référence : ENS (décret royal 311/2022), annexe II, mesure mp.s.3 ; audit périodique prévu à l'article 31.
NIST SP 800-53
Exigence : la norme NIST 800-53 comporte une mesure de contrôle spécifique aux tests d'intrusion. Elle prévoit la réalisation de tests d'intrusion à une fréquence définie par l'organisation, fait appel à un agent ou à une équipe de test d'intrusion indépendante, et ajoute des exercices de type « red team » à titre de mesure complémentaire. La mesure précise explicitement que les tests d'intrusion vont au-delà de l'analyse automatisée des vulnérabilités et sont menés par des agents et des équipes disposant de compétences avérées.
Les tests autonomes peuvent-ils répondre à cette exigence ? Dans une large mesure, oui, bien plus que le PCI. La mesure de contrôle s’articule autour de l’indépendance et du fait d’aller au-delà de la simple analyse, deux critères auxquels Aikido : il s’agit d’un tiers indépendant, et il exploite et valide les systèmes plutôt que de se contenter de les analyser. La mesure de contrôle utilise même le terme « agents ». Le jugement résiduel, à savoir si un agent autonome fait preuve des « compétences » requises, revient à l’autorité d’évaluation ; veillez donc à confirmer l’acceptation auprès de votre évaluateur.
Conclusion : Oui, avec l'accord de l'évaluateur. Les critères d'indépendance et de « va-au-delà de la simple analyse » sont clairement remplis.
Référence : NIST SP 800-53, rév. 5, mesure CA-8 (avec CA-8(1) et CA-8(2)).
Décret présidentiel américain n° 14028
Exigence : ce décret américain a donné naissance au « Secure Software Development Framework » (SSDF). Ce cadre prévoit une procédure de test du code exécutable visant à détecter les vulnérabilités, qui englobe les tests dynamiques, le fuzzing et les tests d'intrusion. Les fournisseurs des agences fédérales américaines s'engagent par écrit à respecter ce cadre en remplissant un formulaire d'attestation de la CISA.
Les tests autonomes peuvent-ils répondre à cette exigence ? Oui. Le cadre est neutre sur le plan technologique. Un test d'intrusion autonome constitue un moyen légitime de se conformer à la pratique de test du code, et votre rapport sert de preuve à l'appui de votre auto-attestation.
Conclusion : Oui, aucun test manuel n'est nécessaire.
Référence : décret présidentiel n° 14028, section 4(e) ; NIST SSDF (SP 800-218), pratiques PW.8 et PW.8.2 ; formulaire d’attestation de développement logiciel sécurisé de la CISA (OMB M-22-18).
FedRAMP
Exigence : FedRAMP impose la réalisation d'un test d'intrusion annuel conforme à ses critères de référence, portant sur un ensemble obligatoire de vecteurs d'attaque et mené par un organisme d'évaluation tiers accrédité (3PAO) pour les systèmes classés « modérés » et « élevés ».
Un test autonome peut-il répondre à cette exigence ? Non. Le test d'intrusion qui sous-tend une autorisation FedRAMP, ainsi que le test d'intrusion annuel qui permet de la maintenir, doivent être réalisés par un organisme 3PAO accrédité. Un test autonome effectué par un organisme non 3PAO ne sera pas accepté dans le cadre d'un dossier d'autorisation ou d'une évaluation annuelle. Il peut être réalisé entre ces deux interventions à titre de test de sécurité supplémentaire, mais il ne constitue pas une preuve d'autorisation.
Conclusion : ne répond pas à l'exigence. Les tests d'intrusion doivent être réalisés par un organisme tiers agréé.
Référence : Lignes directrices FedRAMP relatives aux tests d'intrusion ; contrôle CA-8 de la norme NIST SP 800-53 ; accréditation 3PAO par l'A2LA.
FISMA
Exigence : la norme FISMA reprend les exigences en matière de tests définies dans la norme NIST 800-53, appliquées dans le cadre du référentiel de gestion des risques du NIST. Le périmètre et le niveau de rigueur sont déterminés par l'agence et la classification du système.
Les tests autonomes peuvent-ils répondre à cette exigence ? En général, oui, selon la même logique que la mesure de contrôle NIST 800-53, sous réserve des exigences d’évaluation de l’agence. Pour les systèmes qui visent également une autorisation externe régie par les règles d’un évaluateur accrédité (comme FedRAMP), il convient de se conformer aux contraintes de ce programme.
Conclusion : Oui, mais à la discrétion de l'agence.
Référence : FISMA via les normes NIST SP 800-53 (CA-8) et NIST SP 800-37 (cadre de gestion des risques).
Normes internationales
SOC 2
Exigence : la norme SOC 2 n’impose pas explicitement la réalisation d’un test d’intrusion, mais les critères « Trust Services » de l’AICPA (l’organisme de référence derrière la norme SOC 2) y font référence : le critère de surveillance mentionne les tests d’intrusion comme une méthode d’évaluation acceptable, et le critère relatif à la détection de nouvelles vulnérabilités s’appuie sur des tests actifs. Dans la pratique, les auditeurs s’attendent à recevoir des preuves issues de tests d’intrusion, en particulier pour un rapport de type II, au cours de la période d’audit, accompagnées de preuves des mesures correctives mises en œuvre et des nouveaux tests effectués.
Les tests autonomes peuvent-ils répondre à cette exigence ? Oui. Un test réalisé par un tiers indépendant constitue une preuve plus solide qu’un test interne, et la mention « évaluations continues ou distinctes » suggère la mise en place de tests continus.
Conclusion : Oui. Les tests continus correspondent directement aux « évaluations continues ».
Référence : Critères de l'AICPA relatifs aux services fiduciaires CC4.1 et CC7.1
ISO/IEC 27001
L'exigence : certaines mesures de contrôle de l'annexe A de la norme ISO 27001 constituent des points clés : l'une concerne la gestion des vulnérabilités techniques, qui exige « des tests d'intrusion ou des évaluations de vulnérabilité planifiés, documentés et reproductibles, réalisés par des personnes compétentes et autorisées » ; une autre porte sur les tests de sécurité au cours des phases de développement et de réception ; et une dernière concerne le cycle de vie du développement sécurisé.
Les tests autonomes peuvent-ils répondre à cette exigence ? Oui. Le libellé de la norme correspond pratiquement à une description des tests autonomes, et la reproductibilité est intégrée au fonctionnement même des agents. Les auditeurs acceptent ici les tests automatisés et continus réalisés par des tiers comme preuve, tandis que le rapport et la piste d'audit constituent la partie « documentée ».
Conclusion : Oui. Les tests « reproductibles » s’intègrent parfaitement dans ce contexte.
Référence : ISO/IEC 27001:2022, annexe A ; ISO/IEC 27002:2022, mesures de contrôle 8.8, 8.25 et 8.29.
Règlements européens
Directive NIS2
Exigence : la directive NIS 2 impose aux organisations concernées de gérer les vulnérabilités et de disposer de politiques permettant d'évaluer l'efficacité de leurs mesures de sécurité. Le règlement d'application précise ces gestion des vulnérabilités en matière de gestion des vulnérabilités et prévoit des tests de sécurité automatisés ou manuels, des tests d'intrusion et des analyses de vulnérabilité, qui doivent être effectués régulièrement et à la suite de modifications importantes.
Les tests autonomes peuvent-ils répondre à cette exigence ? Oui, tout à fait. Le règlement d’application de la directive NIS2 est l’un des rares textes à mentionner explicitement les tests automatisés et les tests d’intrusion comme méthodes acceptables. Les tests autonomes continus répondent à l’exigence de « régularité et après des changements significatifs », et le rapport constitue une preuve valable tant pour l’obligation de gestion des vulnérabilités que pour celle d’évaluation de l’efficacité.
Conclusion : Oui. Les tests automatisés et les tests d'intrusion sont expressément prévus.
Référence : directive NIS2 (UE) 2022/2555, article 21, paragraphe 2, points e) et f) ; règlement d'exécution (UE) 2024/2690, annexe, points 6.10 et 7.1.
RGPD
Exigence : le RGPD impose la mise en place d'un processus permettant de tester, d'analyser et d'évaluer régulièrement l'efficacité de vos mesures de sécurité techniques et organisationnelles.
Les tests autonomes peuvent-ils répondre à cette exigence ? Oui. Le RGPD ne prescrit pas de méthode particulière et met l'accent sur la régularité des tests ; ainsi, des tests autonomes continus constituent une preuve plus solide d'un processus en cours qu'un rapport PDF annuel. Le rapport atteste à la fois de la boucle de test et de celle de correction.
Conclusion : Oui, cela favorise les tests continus.
Référence : RGPD (règlement (UE) 2016/679), article 32, paragraphe 1, point d).
Cyber Resilience Act
Exigence : L'Autorité de régulation des télécommunications (CRA) exige que les produits comportant des éléments numériques soient mis sur le marché sans présenter de vulnérabilités exploitables connues et que, dans le cadre de la gestion des vulnérabilités tout au long du cycle de vie du produit, des tests et des contrôles efficaces et réguliers soient effectués pour évaluer la sécurité du produit.
Les tests autonomes peuvent-ils répondre à cette exigence ? Oui. Les tests « efficaces et réguliers » sont précisément ce pentest autonome continu pentest autonome tout au long du cycle de vie du produit, et le rapport valide à la fois l’obligation de test et le critère « aucune vulnérabilité exploitable connue » au moment de la mise sur le marché.
Conclusion : Oui, les tests « réguliers » favorisent les tests d'intrusion autonomes.
Référence : Cyber Resilience Act règlement (UE) 2024/2847), annexe I (partie I et partie II, point 3) ; article 13.
FAQ
Le pentest IA est-il compatible avec la conformité SOC 2 ?
Oui, dans la plupart des cas. Le SOC 2 ne spécifie pas qui ou quoi effectue un pentest, seulement que le test a eu lieu, que les résultats ont été documentés avec des preuves et que les problèmes critiques ont été traités.
Les auditeurs accepteront-ils un rapport de pentest IA ?
La plupart l'accepteront, à condition que le rapport inclue des résultats validés avec des preuves de concept, une section méthodologique, des niveaux de gravité et des recommandations de remédiation. Le principal risque de rejet est de soumettre une sortie de scanner automatisé déguisée en pentest, et non un véritable pentest IA.
Quelle est la différence entre le pentest IA et l'analyse automatisée ?
Les scanners automatisés recherchent des correspondances avec des signatures de vulnérabilités connues et signalent des problèmes potentiels sans confirmer s'ils sont réellement exploitables. Un véritable pentest IA raisonne sur le fonctionnement de l'application, tente d'exploiter les résultats sur une cible réelle et ne révèle que les vulnérabilités réellement confirmées.
Le SOC 2 exige-t-il un pentester humain ?
Non. Le SOC 2 est basé sur les résultats, ce qui signifie qu'il définit ce que vos contrôles doivent démontrer en fonction de vos politiques de sécurité écrites, plutôt que la manière dont les tests doivent être effectués. Le cadre de référence correspond aux contrôles des Critères Communs comme CC4.1 et CC7.1, et un rapport de pentest IA bien documenté satisfait à ces exigences.
Le pentest IA peut-il remplacer le pentest manuel pour la conformité ?
Pour la plupart des programmes SOC 2, ISO 27001 et HIPAA, oui. Certains environnements réglementés, comme les industries britanniques exigeant la certification CREST ou les agences fédérales américaines exigeant l'autorisation FedRAMP, ont des exigences d'accréditation qui nécessitent actuellement qu'un humain cosigne le travail.
À quelle fréquence dois-je effectuer un pentest pour la conformité ?
La plupart des cadres exigent des tests annuels au minimum, ainsi que des retests après l'introduction de changements significatifs dans votre application ou infrastructure. Le pentest IA peut couvrir cela pour SOC 2 et ISO 27001. PCI DSS est le cadre le plus normatif, exigeant explicitement des tests internes et externes annuellement et après tout changement significatif de l'environnement de données de titulaires de carte. Le pentest IA couvre une grande partie de la portion de la couche applicative de cette exigence, mais doit être utilisé par un pentester humain. Les tests de la couche réseau et de segmentation nécessitent une couverture distincte, généralement assurée par un pentester humain.
Quels cadres de référence exigent explicitement des tests d'intrusion ?
Le PCI DSS l'exige explicitement en vertu de la section 11.4, et FedRAMP l'exige dans le cadre de l'autorisation des fournisseurs de services cloud. Le SOC 2, l'ISO 27001 et HIPAA ne l'imposent pas directement, mais les auditeurs l'attendent systématiquement comme preuve que les contrôles de sécurité fonctionnent.
Que doit inclure un rapport de pentest pour la conformité ?
Au minimum : un résumé exécutif, une section méthodologie et périmètre, des résultats validés avec des preuves de faisabilité (proof-of-concept) et des étapes de reproduction, des niveaux de gravité et un plan de remédiation. Pour le SOC 2 spécifiquement, les résultats doivent correspondre aux Critères des Services de Confiance pertinents.
Le pentest IA est-il accepté pour l'ISO 27001 ?
Oui. L'ISO 27001 recommande le pentest dans le cadre de l'évaluation continue des risques, mais ne spécifie pas comment il doit être mené. Un rapport qui documente ce qui a été testé, comment et ce qui a été trouvé satisfait aux exigences de preuve du cadre de référence.
Quelles sont les limitations du pentest IA en matière de conformité ?
Les tests de sécurité physique et l'ingénierie sociale sont hors du champ d'application de tout pentest axé sur les applications, qu'il soit IA ou non. PCI DSS nécessite un pentester humain pour les tests de réseau et de segmentation au minimum. Les industries avec des exigences d'accréditation spécifiques, telles que CREST au Royaume-Uni ou les exigences 3PAO sous FedRAMP, peuvent nécessiter des étapes supplémentaires avant qu'un pentest IA ne satisfasse pleinement leurs obligations de conformité.
