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 jusqu'à la fin de l'article pour en savoir plus en détail sur la manière dont le pentesting IA fonctionne avec différents frameworks.
Ce que les auditeurs recherchent
En bref, 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 des tests ad-hoc
- L'indépendance, et que le testeur ne fasse pas partie de l'équipe qui développe ou exploite le système
- Un test réel de l'efficacité, allant au-delà de l'analyse automatisée des vulnérabilités
- Des preuves, telles que les vulnérabilités, leur gravité et les preuves associées
- La remédiation et le re-test des vulnérabilités
Si votre pentest 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 dynamique. 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 ayant un impact sur 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 : Spécificités sectorielles
Secteur financier
PCI DSS
L'exigence : PCI DSS est le cadre le plus prescriptif ici. Il exige une méthodologie de test d'intrusion documentée, des tests d'intrusion internes et externes au moins une fois par an et après des changements significatifs, le re-test de toute correction, et des tests distincts des contrôles qui segmentent l'environnement de données des titulaires de carte (plus souvent pour les fournisseurs de services). Le test doit être effectué par un testeur qualifié, organisationnellement indépendant des systèmes testés.
Les tests autonomes peuvent-ils y répondre ? Non. Le Guide de test d'intrusion du PCI établit une distinction entre un test d'intrusion et une analyse de vulnérabilité : une analyse est automatisée, 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 aider, mais le guide considère le travail manuel comme le test lui-même. Un test d'intrusion autonome ne sera pas accepté comme le pentest PCI.
Les agents d'Aikido exploitent la logique métier, les failles BOLA et les failles en chaîne, il est donc judicieux de les exécuter en tant que tests de sécurité continus en parallèle de l'engagement requis, y compris après des changements significatifs. C'est un avantage en termes de sécurité et une source de preuves de remédiation, pas une approbation PCI. Planifiez le pentest humain qualifié séparément.
Verdict : Ne satisfait pas à l'exigence. Le test d'intrusion doit être effectué par un testeur humain qualifié. Les tests autonomes ne seront pas acceptés comme le pentest PCI.
Référence : PCI DSS v4.0.1 Exigence 11.4 (11.4.1 à 11.4.6) ; Guide de test d'intrusion PCI SSC.
DORA
L'exigence : DORA comporte deux niveaux de tests. Le niveau général est un programme de tests de résilience opérationnelle numérique que toute entité financière doit établir, et le test d'intrusion est l'une des méthodes qu'elle doit utiliser. Le niveau avancé exige des tests d'intrusion basés sur les menaces (TLPT) au moins une fois tous les trois ans pour les entités financières significatives, avec des règles strictes concernant les personnes autorisées à les effectuer.
Les tests autonomes peuvent-ils y répondre ? Oui pour le programme général, non pour le TLPT. Le programme général est flexible en termes de méthodes et ses méthodes listées incluent les tests d'intrusion, ainsi, les tests autonomes continus y sont adaptés et vont au-delà du minimum périodique. Le TLPT est différent. Il est calqué sur le cadre TIBER-EU de la BCE et exige des red-teamers externes qualifiés et un fournisseur externe de threat intelligence, les établissements de crédit significatifs étant tenus d'utiliser exclusivement des testeurs externes. Il s'agit, par conception, d'un engagement de red-team humaine.
Verdict : Oui pour le programme de tests général. Il ne satisfera pas à l'exigence TLPT, qui impose des red-teamers humains externes. Utilisez Aikido pour exécuter et documenter le programme général. Le TLPT est un engagement distinct qui doit être effectué par des humains.
Référence : DORA (Règlement (UE) 2022/2554) Articles 24 et 25 (programme de tests), Articles 26 et 27 (TLPT).
Règle sur la protection des informations de la FTC
L'exigence : La Règle sur la protection des informations de la FTC régit la manière dont les institutions financières protègent les informations de leurs clients. Elle exige des tests réguliers de l'efficacité de vos mesures de protection et propose deux méthodes : la surveillance continue, ou, à défaut, un test d'intrusion annuel accompagné d'évaluations des vulnérabilités au moins tous les six mois. Des tests sont également requis après des modifications majeures des opérations.
Les tests autonomes peuvent-ils y répondre ? Oui. La surveillance continue est explicitement mentionnée comme une alternative directe au test d'intrusion annuel, ce que les tests autonomes continus offrent. Pour une institution qui préfère l'approche périodique, un programme autonome fournit à la fois le test annuel et les évaluations semestrielles. La règle n'impose aucune exigence humaine ou d'accréditation pour le testeur.
Verdict : Oui. La surveillance continue est un substitut explicite au test d'intrusion annuel.
Référence : Règle sur la protection des informations de la FTC, 16 CFR 314.4(d) et 314.4(d)(2).
Réglementation sur la cybersécurité du NYDFS
L'exigence : La réglementation de New York sur la cybersécurité des services financiers s'applique aux banques, aux assureurs et aux autres entités agréées à New York, et elle est citée au-delà de l'État comme une référence pour le secteur financier. Sa section sur les tests d'intrusion exige des tests basés sur votre évaluation des risques, structurés soit comme une surveillance continue, soit comme un test d'intrusion annuel accompagné d'évaluations des vulnérabilités semestrielles.
Les tests autonomes peuvent-ils y répondre ? Oui. Comme pour la règle de la FTC, la réglementation considère la surveillance continue et 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 choisissent la voie périodique, ils produisent également le test annuel et les évaluations semestrielles. La réglementation n'impose aucune exigence d'accréditation pour le testeur.
Verdict : Oui. La surveillance continue satisfait à l'exigence à elle seule.
Référence : Réglementation sur la cybersécurité du NYDFS, 23 NYCRR 500.5 (Deuxième amendement, 2023).
Secteur de la santé
HIPAA
L'exigence : La Règle de sécurité de l'HIPAA ne mentionne pas explicitement les tests d'intrusion. Sa norme d'évaluation exige une évaluation technique et non technique périodique de vos mesures de protection, ce qui est le cadre dans lequel s'inscrivent généralement les tests d'intrusion. Une mise à jour proposée en décembre 2024 la rendrait explicite, exigeant une analyse des 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 finalisée, mais l'orientation est claire.
Les tests autonomes peuvent-ils y répondre ? Oui. Ni la norme d'évaluation actuelle ni la mise à jour proposée n'exigent un testeur humain. Un rapport autonome constitue aujourd'hui une preuve d'évaluation technique périodique, et il satisferait demain à l'obligation proposée de test d'intrusion annuel, les tests continus dépassant une cadence annuelle.
Verdict : Oui, et prêt pour la règle proposée.
Référence : Règle de sécurité de l'HIPAA, 45 CFR 164.308(a)(8) ; 2024 NPRM (RIN 0945-AA22).
HITRUST CSF
L'exigence : HITRUST CSF est un cadre certifiable que les organisations de soins de santé américaines et leurs fournisseurs utilisent pour démontrer la protection des informations de santé protégées (PHI). Les tests d'intrusion s'inscrivent dans ses exigences de conformité technique et d'évaluation de la sécurité. Pour la certification supérieure (r2), le test doit s'inscrire dans une période glissante de 12 mois et être exécuté comme un programme continu plutôt qu'un événement annuel unique, avec un suivi et une nouvelle vérification des résultats.
Les tests autonomes peuvent-ils y répondre ? Oui HITRUST n'exige pas de testeur humain ou accrédité pour le test d'intrusion, et sa préférence pour un programme continu plutôt qu'un événement annuel unique correspond aux tests autonomes continus. Un rapport de test d'intrusion autonome constitue une preuve valide pour l'évaluateur.
Verdict : Oui pour l'exigence de test d'intrusion. La validation par l'évaluateur externe est une étape d'audit distincte.
Référence : Contrôle HITRUST CSF 06.h (Vérification de la conformité technique).
Directives de la FDA sur la cybersécurité avant commercialisation
L'exigence : Les directives de la FDA Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions recommandent une approche de test de sécurité en couches, mais exigent en pratique un rapport de test d'intrusion lors des soumissions avant commercialisation.
Les tests autonomes peuvent-ils y répondre ? Oui. Les directives sont axées sur les résultats : elles exigent des preuves que les tests ont été effectués, par qui, quel était le périmètre, ce qui a été trouvé et, surtout, ce que vous avez fait à ce sujet. En fin de compte, il s'agit de s'assurer que les risques de sécurité sont maîtrisés. Le rapport de test d'intrusion IA d'Aikido répond à ces attentes.
Verdict : Oui, mais documentez le périmètre, les méthodes et l'indépendance dans la soumission.
Référence : Article 524B de la loi FD&C ; directives de la FDA sur la cybersécurité avant commercialisation (2025).
Règlement européen sur les dispositifs médicaux (MDR)
L'exigence : Les exigences générales de sécurité et de performance du MDR attendent que les logiciels de dispositifs médicaux soient développés selon l'état de l'art, avec vérification et validation et des mesures minimales de sécurité informatique tout au long du cycle de vie du produit. Le guide de cybersécurité des dispositifs médicaux de l'UE (MDCG 2019-16) cite les tests d'intrusion comme faisant partie de cette vérification et validation, aux côtés des tests de fonctionnalités de sécurité, du fuzzing et de l'analyse des vulnérabilités.
Les tests autonomes peuvent-ils y répondre ? Oui. Le MDR et son guide sont neutres quant à la méthode, et un test d'intrusion autonome constitue une preuve de vérification et de validation valide. Les tests continus s'adaptent également mieux à l'accent mis sur le cycle de vie qu'un test ponctuel. À l'instar du guide de la FDA, il s'agit de prouver que les risques de sécurité sont maîtrisés.
Verdict : Oui.
Référence : MDR de l'UE (Règlement (UE) 2017/745) Annexe I, GSPR 17.2 et 17.4 ; guide MDCG 2019-16.
IEC 81001-5-1
L'exigence : Il s'agit de la norme de cycle de vie sécurisé des logiciels pour les logiciels de santé, et elle sera harmonisée pour le MDR. Ses activités de test de systèmes logiciels incluent 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 effectués par un département ou une organisation indépendant des développeurs, et elle contient une disposition distincte sur la gestion des conflits d'intérêts entre les testeurs et les développeurs.
Les tests autonomes peuvent-ils y répondre ? Oui, et l'exigence d'indépendance est un point en votre faveur. Ce que la norme exige, c'est une indépendance organisationnelle vis-à-vis des développeurs, et non un testeur humain. En tant que tiers externe, Aikido satisfait à 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.
Verdict : Oui, l'indépendance d'un tiers satisfait à la norme.
Référence : IEC 81001-5-1:2021 clause 5.7.4 (mappée à SVV-4) et 5.7.5.
Automobile
ISO/SAE 21434
L'exigence : La cybersécurité automobile repose sur l'ISO/SAE 21434, la norme d'ingénierie pour la cybersécurité des véhicules, sa méthodologie de risque et l'analyse et l'évaluation des menaces et des risques (« TARA »). La norme désigne les tests d'intrusion comme un moyen de valider que les objectifs de cybersécurité ont été atteints.
Les tests autonomes peuvent-ils y répondre ? Oui, pour les parties qu'il peut atteindre. La norme est basée sur les résultats. Les tests d'intrusion sont une méthode de validation parmi plusieurs (par exemple, fuzzing, SAST, DAST, …), et un rapport de pentest autonome constitue une preuve valide, les tests continus s'adaptant également à l'accent mis sur le cycle de vie. Une mise en garde : les véhicules sont construits sur des composants embarqués, les tests de sécurité physique au niveau matériel ne peuvent pas être effectués par des méthodes autonomes.
Verdict : Oui pour la surface d'attaque connectée et backend. La norme est flexible en termes de méthode et accepte les tests autonomes comme preuve de validation.
Référence : ISO/SAE 21434:2021 validation de la cybersécurité (Clause 11, RQ-11-01).
Gouvernement et secteur public
ENS
L'exigence : L'Esquema Nacional de Seguridad espagnol liste les tests d'intrusion comme une mesure de sécurité explicite. C'est obligatoire pour les systèmes de catégorie élevée et recommandé pour les systèmes de catégorie moyenne, et les résultats récents alimentent l'audit périodique du cadre.
Les tests autonomes peuvent-ils y répondre ? Oui. L'ENS spécifie que vous testez, pas qui les effectue. Les résultats des pentests autonomes satisfont à la mesure, et les tests continus dépassent les fréquences annuelles (élevée) et biennales (moyenne) recommandées.
Verdict : Oui, les pentests autonomes satisfont à l'exigence.
Référence : ENS (Real Decreto 311/2022) Annexe II mesure mp.s.3 ; audit périodique en vertu de l'Article 31.
NIST SP 800-53
L'exigence : Le NIST 800-53 dispose d'un contrôle dédié aux tests d'intrusion. Il exige des tests d'intrusion à une fréquence définie par l'organisation, prévoit un agent ou une équipe d'intrusion indépendant, et ajoute des exercices de red team comme amélioration. Le contrôle stipule explicitement que les tests d'intrusion vont au-delà de l'analyse automatisée des vulnérabilités et sont effectués par des agents et des équipes dotés de compétences démontrables.
Les tests autonomes peuvent-ils y répondre ? En grande partie oui, plus que le PCI. Le contrôle est axé sur l'indépendance et le dépassement de la simple analyse, deux points qu'Aikido respecte : il s'agit d'un tiers indépendant, et il exploite et valide plutôt que de simplement analyser. Le contrôle utilise même le mot « agents ». Le jugement résiduel, à savoir si un agent autonome démontre les « compétences » requises, incombe à l'autorité d'évaluation, il est donc conseillé de confirmer l'acceptation avec votre évaluateur.
Verdict : Oui, avec l'accord de l'évaluateur. L'indépendance et le « dépassement de l'analyse » sont clairement respectés.
Référence : NIST SP 800-53 Rév. 5, contrôle CA-8 (avec CA-8(1) et CA-8(2)).
Décret exécutif américain 14028
L'exigence : Ce décret exécutif américain a conduit au Secure Software Development Framework (SSDF). Le cadre comprend une pratique de test du code exécutable pour trouver les vulnérabilités, c'est là que se situent les tests dynamiques, le fuzzing et les tests d'intrusion. Les fournisseurs des agences fédérales américaines auto-certifient qu'ils suivent le cadre sur un formulaire d'attestation de la CISA.
Les tests autonomes peuvent-ils y répondre ? Oui. Le cadre est neutre sur le plan technologique. Un test d'intrusion autonome est un moyen légitime de satisfaire à la pratique de test de code, et votre rapport constitue la preuve de l'auto-attestation.
Verdict : Oui, les tests humains ou manuels ne sont pas requis.
Référence : EO 14028 Section 4(e) ; NIST SSDF (SP 800-218) pratique PW.8 et PW.8.2 ; CISA Secure Software Development Attestation Form (OMB M-22-18).
FedRAMP
L'exigence : FedRAMP exige un test d'intrusion annuel sur l'ensemble de ses lignes de base, réalisé selon un ensemble obligatoire de vecteurs d'attaque et effectué par un organisme d'évaluation tiers accrédité (un 3PAO) pour les systèmes de niveau Modéré et Élevé.
Les tests autonomes peuvent-ils y répondre ? Non. Le test d'intrusion nécessaire à une autorisation FedRAMP, ainsi que le pentest annuel qui la maintient, doivent être effectués par un 3PAO accrédité. Un test autonome réalisé par un organisme non-3PAO ne sera pas accepté dans un dossier d'autorisation ou une évaluation annuelle. Il peut être exécuté entre ces engagements comme test de sécurité supplémentaire, mais cela ne constitue pas une preuve d'autorisation.
Verdict : Ne répond pas à l'exigence. Les pentests doivent être effectués par un organisme tiers accrédité.
Référence : FedRAMP Penetration Test Guidance ; NIST SP 800-53 contrôle CA-8 ; accréditation 3PAO par A2LA.
FISMA
L'exigence : FISMA hérite ses attentes en matière de tests du NIST 800-53, appliquées via le cadre de gestion des risques (Risk Management Framework) du NIST. La portée et la rigueur sont définies par l'agence et la catégorisation du système.
Les tests autonomes peuvent-ils y répondre ? Généralement oui, selon la même logique que le contrôle NIST 800-53, sous réserve des exigences d'évaluation de l'agence. Pour les systèmes qui recherchent également une autorisation externe avec des règles d'évaluateur accrédité (comme FedRAMP), il convient de se référer aux contraintes de ce programme.
Verdict : Oui, mais à la discrétion de l'agence.
Référence : FISMA via NIST SP 800-53 (CA-8) et NIST SP 800-37 (Risk Management Framework).
Normes internationales
SOC 2
L'exigence : SOC 2 n'exige pas explicitement de pentest, mais les critères des services de confiance (Trust Services Criteria) de l'AICPA (l'organisme de tutelle derrière SOC 2) en suggèrent un : le critère de surveillance mentionne les tests d'intrusion comme méthode d'évaluation acceptable, et le critère de détection de nouvelles vulnérabilités est soutenu par des tests actifs. En pratique, les auditeurs s'attendent à des preuves de pentest, en particulier pour un rapport de Type II, au cours de la période d'audit, avec des preuves de remédiation et de re-test.
Les tests autonomes peuvent-ils y répondre ? Oui. Un test tiers indépendant constitue une preuve plus solide qu'un test interne, et la formulation « évaluations continues ou distinctes » oriente vers des tests continus.
Verdict : Oui. Les tests continus correspondent directement aux « évaluations continues ».
Référence : AICPA Trust Services Criteria CC4.1 et CC7.1
ISO/IEC 27001
L'exigence : Plusieurs contrôles de l'Annexe A de la norme ISO 27001 sont des points clés : un sur 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 par des personnes compétentes et autorisées » ; un sur les tests de sécurité en développement et acceptation ; et un sur le cycle de vie du développement sécurisé.
Les tests autonomes peuvent-ils y répondre ? Oui. La formulation de la norme est presque une description des tests autonomes, et la reproductibilité est intégrée au fonctionnement des agents. Les auditeurs acceptent ici les tests automatisés et continus de tiers comme preuves, et le rapport ainsi que la piste d'audit fournissent la partie « documentée ».
Verdict : Oui. Les tests « reproductibles » sont parfaitement adaptés.
Référence : ISO/IEC 27001:2022 Annexe A ; ISO/IEC 27002:2022 contrôles 8.8, 8.25 et 8.29.
Réglementations européennes
Directive NIS2
L'exigence : NIS2 exige des organisations concernées de gérer les vulnérabilités et de disposer de politiques pour évaluer l'efficacité de leurs mesures de sécurité. Le règlement d'exécution précise cela avec des exigences de gestion des vulnérabilités et des tests de sécurité automatisés ou manuels, des tests d'intrusion et des analyses de vulnérabilité, effectués régulièrement et après des changements significatifs.
Les tests autonomes peuvent-ils y répondre ? Oui, explicitement. Le règlement d'exécution de NIS2 est l'un des rares instruments qui nomme explicitement les tests automatisés et les tests d'intrusion comme méthodes acceptables. Les tests autonomes continus correspondent à la formulation « régulièrement et après des changements significatifs », et le rapport constitue une preuve pour les obligations de gestion des vulnérabilités et d'évaluation de l'efficacité.
Verdict : Oui. Les tests automatisés et les tests d'intrusion sont expressément envisagés.
Référence : Directive NIS2 (UE) 2022/2555 Article 21(2)(e) et (f) ; Règlement d'exécution (UE) 2024/2690 Annexe points 6.10 et 7.1.
RGPD
L'exigence : Le RGPD exige un processus de test, d'évaluation et d'appréciation réguliers de l'efficacité de vos mesures de sécurité techniques et organisationnelles.
Le pentest autonome peut-il y répondre ? Oui. Le RGPD ne prescrit pas de méthode et insiste sur des tests réguliers, de sorte qu'un pentest autonome continu est une démonstration plus solide d'un processus continu qu'un PDF annuel. Le rapport atteste à la fois des tests et de la boucle de remédiation.
Verdict : Oui, il privilégie les tests continus.
Référence : RGPD (Règlement (UE) 2016/679) Article 32(1)(d).
Cyber Resilience Act
L'exigence : Le Cyber Resilience Act exige que les produits comportant des éléments numériques soient mis sur le marché sans vulnérabilités exploitables connues et, dans le cadre de la gestion des vulnérabilités tout au long de la vie du produit, que des tests et des examens efficaces et réguliers de la sécurité du produit soient appliqués.
Le pentest autonome peut-il y répondre ? Oui. Des tests « efficaces et réguliers » sont ce que le pentest autonome continu fournit tout au long du cycle de vie du produit, et le rapport soutient à la fois l'obligation de test et la barre des « aucune vulnérabilité exploitable connue » lors de la publication.
Verdict : Oui, les tests « réguliers » favorisent le pentest autonome.
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é.
