O pentest de IA tem causado impacto e rivaliza com o poder de hackers humanos de maneiras que não esperávamos. Mas, frequentemente, as empresas buscam o pentest para alcançar e apoiar suas certificações de conformidade. E a pressão para fazê-lo com mais frequência é real. De acordo com o relatório 2026 State of AI in Pentesting da Aikido Security, que entrevistou 400 CISOs e líderes de engenharia sênior, 79% estão preocupados em perder vulnerabilidades introduzidas entre os testes programados.
No passado, auditores rejeitaram resultados de ferramentas automatizadas. Mas isso não ocorreu porque um humano era necessário para realizar todos os testes, e sim porque essas ferramentas antigas não faziam nada próximo a pentests adequados. Um pentest de IA executando 250 agentes orquestrados contra sua aplicação se assemelha muito à forma como pentesters humanos realizam suas avaliações. Isso significa explorar a aplicação, entender como os recursos funcionam, encontrar maneiras de quebrá-los e validar que o problema é realmente explorável antes de incluí-lo no relatório.
Os pentests de IA verdadeiros estão sendo regularmente aceitos por auditores hoje. Nesta publicação, discutiremos equívocos sobre o pentest de IA e como ele se relaciona com a conformidade, e explicaremos como e quando você pode usar o pentest de IA para atender aos seus requisitos de conformidade.
{{cta}}
O que você realmente precisa para o pentest de conformidade?
Quando um auditor solicita um teste de penetração, ele está pedindo documentação de que sua aplicação foi testada contra um conjunto definido de vetores de ataque e metodologias de teste, que as descobertas foram validadas e registradas, e que você tem um plano de remediação para qualquer coisa crítica. Se foi um humano que ficou em frente a um terminal por duas semanas ou agentes de IA que dedicaram um dia a isso, não é realmente a questão. Também é o caso de que a infraestrutura mudava muito mais lentamente no passado, com lançamentos trimestrais, então a ideia de realizar testes de penetração semanais era um tanto absurda. Esse definitivamente não é o caso agora.
Os frameworks mais comuns que exigem ou recomendam pentesting são SOC 2, ISO 27001, HIPAA e PCI DSS. Para a maioria deles, nenhum exige explicitamente que um humano tenha conduzido o teste. O que eles especificam é cobertura, metodologia e documentação. O PCI DSS é menos direto — sua orientação define o teste de penetração como 'essencialmente um esforço manual' e afirma que ferramentas automatizadas sozinhas não satisfazem o requisito (veremos o que isso significa para o pentest de IA mais tarde).
Vamos analisar o SOC 2. O framework não exige pentesting de forma alguma. O que ele exige é que você demonstre que seus controles são eficazes, particularmente em relação ao acesso lógico (CC6.1), gerenciamento de mudanças (CC8.1) e mitigação de riscos (CC7.1 a CC7.4). Os auditores concordaram que o pentesting é a forma mais credível de evidenciar esses controles, porque mostra que alguém realmente tentou quebrá-los. Um relatório de pentest que mapeia as descobertas para esses critérios, documenta o que foi testado e mostra a remediação de qualquer item crítico, é o que satisfaz o requisito. Acontece que o framework não diz nada sobre quem ou o que conduziu o teste.
A ISO 27001 segue um padrão semelhante, recomendando pentesting como parte da avaliação contínua de riscos.
Historicamente, a HIPAA tratou o pentesting como uma boa prática, e não como um requisito rígido, mas isso está mudando. Em dezembro de 2024, o HHS propôs atualizações à Regra de Segurança da HIPAA que tornariam o teste de penetração anual obrigatório para todas as entidades cobertas e parceiros de negócios, com o teste exigindo ser realizado por pessoal qualificado com conhecimento apropriado em cibersegurança. Essa regra deve ser finalizada até meados de 2026. Se você atua na área da saúde, verifique diretamente com sua equipe de compliance o status atual.
Todos os frameworks exigem um relatório estruturado com um resumo executivo, uma seção de metodologia, descobertas validadas com evidências e etapas de reprodução, classificações de severidade e orientações de remediação. O Guia de Testes de Segurança de Aplicações Web da OWASP é o benchmark que a maioria dos testadores segue para cobertura (e é uma lista longa). Mesmo uma equipe humana trabalhando com um orçamento de uma semana não consegue, realisticamente, abordar tudo em profundidade. Eles precisam triar e priorizar as coisas mais importantes. Frequência e amplitude são restrições que não limitam mais nosso escopo de teste.
A suposição de que pentesting de conformidade significa pentesting humano não está escrita na maioria dos frameworks. Isso tem sido verdade por padrão porque, até os LLMs, nenhuma tecnologia conseguia chegar perto de realmente realizá-los. Para equipes em setores altamente regulamentados com requisitos de conformidade específicos, vale a pena ter essa conversa diretamente com seu auditor. Para a maioria, no entanto, o relatório não levantará nenhuma bandeira. O pentest de IA cobre os requisitos.
Role até o final do artigo para saber mais em detalhes sobre como o pentesting com IA funciona com diferentes frameworks.
O que os auditores procuram
Em resumo, auditores ou normas estão, na verdade, procurando o seguinte em um teste de penetração:
- Uma metodologia documentada e repetível, não uma investigação ad-hoc
- Independência, e que o testador não seja a mesma equipe que constrói ou opera o sistema
- Teste real de eficácia, indo além da varredura automatizada de vulnerabilidades
- Evidências, como achados, severidade e prova
- Remediação e reteste dos achados
Se o seu pentest atender a esses critérios, seja por IA ou humano, há uma boa chance de seu auditor aceitá-lo.
Onde o pentest de IA já entrega para conformidade
Trilhas de auditoria
A trilha de auditoria de um pentest de IA é extensa e detalhada, muitas vezes melhor do que muitos relatórios de pentest humano. Cada requisição enviada, cada payload tentado, cada ação tomada por cada agente é registrada. Você pode ver exatamente o que foi testado, como o teste foi conduzido e o que foi encontrado. A maioria dos relatórios de pentest humano fornece descobertas e uma seção de metodologia. Eles não fornecem um rastreamento completo de cada etapa realizada. Se o seu auditor perguntar: "Como sabemos que eles testaram X?", o relatório gerado a partir de um pentest de IA pode realmente mostrar o log para essa coisa exata.
Cobertura de Teste
O pentest de IA cobre um terreno significativo. Para aqueles que perguntam: "Como sabemos que ele tentou tudo?", a preocupação se aplica igualmente aos pentesters humanos. Um relatório de pentest manual que retorna com zero descobertas e nenhuma trilha de auditoria do que foi testado está sendo aceito inteiramente pela fé. Existe uma espécie de servidão ao ritual do teste de penetração anual. Você não pode provar que um humano tentou tudo, de qualquer forma. Com um pentest de IA, você pode enumerar a cobertura detalhada do teste através dos logs.
Agentes podem trabalhar através do Top 10 OWASP completo em horas. Eles testam verificações de autorização em todos os endpoints, não apenas uma amostra representativa. Eles tentam todos os vetores de ataque em cada recurso, não apenas aqueles que um testador humano teve tempo de alcançar antes do término do engajamento.
As IAs estão melhorando exponencialmente em sua capacidade de raciocinar e entender código. Elas estão encontrando novas vulnerabilidades dependentes de contexto que os humanos perderam por anos. Céticos presumem que as IAs não conseguem lidar com vulnerabilidades de lógica de negócios. Este não é mais o caso. Na prática, os agentes leem a base de código, entendem o comportamento pretendido e encontram maneiras criativas de quebrá-lo. A frase “Se tudo o que você tem é um martelo, todo problema parece um prego” é apropriada aqui. Mesmo que um testador humano seja muito bom em encontrar vulnerabilidades XSRF e ganhe um bug bounty de seis dígitos, a verdade é que o teste de IA traz um saco cheio de martelos para o trabalho.
No benchmark direto da Aikido Security em quatro aplicações web não triviais, agentes de IA encontraram o dobro de vulnerabilidades de controle de acesso quebrado do que testadores humanos seniores. Eles também descobriram uma falsificação de assinatura eletrônica em uma aplicação de pagamento que os testadores manuais não detectaram. As IAs, é verdade, tiveram uma enorme vantagem porque tinham acesso ao código-fonte. Uma IA absorve uma base de código completa quase instantaneamente, enquanto testadores humanos geralmente trabalham sem ela por razões logísticas e de NDA. Mas o teste de caixa branca, caixa cinza ou caixa preta é definitivamente elevado pelo paralelismo que o pentesting agêntico traz para a mesa.
O benchmark também descobriu que os testadores humanos se saíram melhor na sondagem de endurecimento de configuração deficiente e na identificação de verificações de higiene de conformidade. Desde então, o pentest de IA continuou a melhorar. O pentest de IA da Aikido, por exemplo, regularmente detecta vulnerabilidades IDOR complexas, que envolvem autenticar-se como usuários reais e seguir longos fluxos de trabalho de ponta a ponta.
Integrações de terceiros, particularmente fluxos OAuth complexos e implementações de SSO, são mais difíceis para os agentes navegarem consistentemente. O pentest de IA da Aikido dedicou o esforço necessário para resolver esses problemas, mas não considere garantido que todos os produtos de pentest de IA podem fazer isso.
Relatórios
O formato do relatório se alinha diretamente com o que as equipes de compliance precisam. SOC 2 e ISO 27001 recebem um PDF completo com evidências, orientações detalhadas de remediação e etapas de reprodução para retestes após a aplicação das remediações. Os requisitos da HIPAA são cobertos.
Os tempos de resposta para pentest de IA são da ordem de horas (definitivamente menos de um dia), o que é muito útil quando você está em um cronograma de certificação ou respondendo a uma solicitação de auditoria que inclui ativos no escopo que não foram testados anteriormente.
O que o pentest de IA não pode fazer para conformidade?
Embora os pentests de IA estejam sendo cada vez mais aceitos, a tecnologia ainda é bastante nova, e algumas indústrias e seus reguladores ainda estão definindo sua posição sobre o assunto.
O PCI DSS é mais prescritivo que o SOC 2 ou a ISO 27001 e exige explicitamente testes de penetração anuais, com cobertura específica de ambientes de dados de titulares de cartão. Sua orientação oficial para pentesting, atualizada pela última vez em 2017, descreve o teste de penetração como 'essencialmente um esforço manual' e afirma que a execução de ferramentas automatizadas por si só não satisfaz o requisito. O espírito do requisito sempre foi sobre exploração ativa, evidências validadas e julgamento aplicado aos resultados. Pentesters humanos podem usar o pentest de IA como uma ferramenta para lidar com uma grande parte do trabalho pesado no lado da aplicação. Dito isso, o PCI DSS também exige testes de camada de rede e segmentação, juntamente com testes de camada de aplicação, o que o pentest de IA não cobrirá de qualquer forma.
Para alguns reguladores de serviços financeiros ou requisitos do setor governamental, as empresas precisarão verificar diretamente com seu auditor para avaliar sua abertura em ver o monitoramento contínuo e os testes não apenas como equivalentes aos testes pontuais, mas como evidência significativamente superior de controles de segurança e rigor do programa.
O FedRAMP, que se aplica a provedores de serviços Cloud que vendem para agências federais dos EUA, exige que as avaliações sejam conduzidas por organizações de avaliação de terceiros credenciadas (3PAOs). RFCs recentes para o FedRAMP 20x, no entanto, indicam que o programa está trabalhando para encontrar maneiras de modernizar sua abordagem para a verificação de soluções SaaS para proteger infraestruturas críticas e aplicações e serviços governamentais.
Testes de segurança física e engenharia social estão totalmente fora do escopo (testes de phishing são exigidos para o FedRAMP). Estamos longe de ter pentesters de IA andando por aí girando maçanetas para ver se estão trancadas e enviando e-mails de phishing (provavelmente para o melhor).
É mais provável que vejamos empresas credenciadas alavancando o pentest de IA em locais discretos como ferramentas, em vez de substituições completas para sua reconhecimento e pentesting. Hoje, os pentests de IA podem ser usados em um modelo de parceria onde uma empresa credenciada revisa e co-assina o trabalho e os artefatos de teste. Essa abordagem vale a pena explorar se você estiver operando em qualquer um desses mercados.
Os auditores não rejeitam as ferramentas de pentest de IA como scanners?
A objeção mais comum nem é sobre pentest de IA. O problema são os scanners automatizados que se disfarçam de pentest de IA.
Por anos, organizações menos escrupulosas tentaram fazer passar a saída de scanners básicos de vulnerabilidades como um relatório de pentest. Ferramentas como Nessus ou OpenVAS produzem longas listas de problemas sinalizados com classificações de severidade que parecem críveis no papel, mas nada foi validado, explorado ou contextualizado. Elas confundem o conceito de uma possível vulnerabilidade com um caminho de ataque demonstrável. Os auditores já viram o suficiente disso para serem céticos em relação a qualquer coisa que se pareça com uma varredura disfarçada de pentest. Portanto, você precisa garantir que seu pentest de IA seja realmente um pentest de IA, e não um scanner ou DAST com um verniz de IA.
Um pentest de IA real explora e confirma vulnerabilidades contra um alvo real antes de apresentá-las em um relatório. Você pode notar a diferença na linguagem e nos detalhes do relatório. Descobertas validadas vêm com evidências de prova de conceito e passos de reprodução mostrando como o exploit foi realmente executado, enquanto as descobertas de scanner não validadas apenas descrevem um problema potencial com uma classificação de severidade genérica e não incluem prova de que algo foi realmente tentado. Se um relatório retorna com centenas de descobertas e nenhuma delas mostra evidência de exploração, você provavelmente tem um scanner em mãos, independentemente do que diz na embalagem.
Isso remete ao que estávamos dizendo sobre o PCI DSS. A linguagem de 2017 que descreve o pentesting como 'essencialmente um esforço manual' foi escrita especificamente para abordar a questão de organizações que apresentavam a saída de scanners como um relatório de pentest. A orientação estava traçando uma linha contra essa prática, não antecipando um mundo onde agentes de IA exploram e validam ativamente as descobertas da mesma forma que os testadores humanos. Embora os pentests de IA não cubram todos os requisitos de pentesting do PCI DSS (como testes de camada de rede e segmentação), as ferramentas de pentest de IA podem ajudar as organizações a realizar pentesting de aplicações de forma mais eficiente, e podemos ver essas regulamentações atualizarem sua redação no futuro para abordar a nuance. A indústria tende a se mover mais rápido do que os frameworks de compliance.
Conformidade contínua
Além do requisito de conformidade, o pentest pontual ou de 'snapshot' é um modelo falho para qualquer coisa que entregue código mais regularmente do que uma vez por ano.
Um pentest anual informa como sua aplicação estava no dia ou na semana em que o teste foi executado. Mas sua equipe de desenvolvimento provavelmente implementou novas mudanças no dia seguinte. Três meses depois, o relatório de conformidade ainda é válido no papel, mas sua superfície de ataque mudou significativamente. Os 85% dos CISOs e líderes de engenharia em nossa pesquisa que dizem que as descobertas estão desatualizadas pelo menos às vezes não estão errados sobre sua situação. O atraso é palpável e de alto risco.
O pentest contínuo transforma sua asserção pontual em um registro vivo. Em vez de dizer a um auditor "executamos um pentest contra ativos de produção em março", você pode mostrar a ele um histórico de testes de segurança que acompanha seu histórico de implantação. E não apenas em produção, mas também nos ambientes de não-produção. Cada mudança que impacta sua superfície de ataque foi testada, então os problemas foram detectados e corrigidos antes de chegarem à produção.
Bancos e indústrias altamente regulamentadas são atualmente forçadas a desacelerar os ciclos de lançamento, especificamente para ter recursos e funcionalidades testados antes de serem lançados. O pentest de IA contínuo muda isso, porque os testes são executados em sincronia com sua cadência de implantação, verificando apenas o que mudou, para que os lançamentos não precisem esperar por revisões de segurança.
Veja como é um pentest de IA de nível de auditoria
Os auditores verificam se um teste foi realizado, se seguiu uma metodologia de teste definida, se as descobertas do teste foram documentadas com evidências e se as questões críticas foram abordadas. Um relatório de pentest de IA satisfaz todos esses requisitos. As estruturas que definem o que conta como um relatório de teste e artefato de conformidade não especificam quem ou o que executou o teste.
Se você está trabalhando para a conformidade SOC 2, ISO 27001, HITRUST ou uma certificação similar e quer ver como é o relatório antes de se comprometer, você pode solicitar um relatório de amostra ou executar uma varredura de recursos em sua aplicação. A maioria das equipes descobre que o formato do pentest de IA não é uma surpresa para seus auditores.
Na Aikido, vimos resultados muito bons com nossos clientes usando pentest de IA com conformidade. Embora prometamos fazer um pentest manual se seu pentest de IA for rejeitado por um auditor, até agora, não vimos isso acontecer. Fale conosco hoje para desbloquear pentest rápido e compatível hoje.
Apêndice: Especificidades do Setor
Indústria Financeira
PCI DSS
O requisito: O PCI DSS é a estrutura mais prescritiva aqui. Ele exige uma metodologia de teste de penetração documentada, testes de penetração internos e externos pelo menos uma vez por ano e após mudanças significativas, reteste de tudo o que for corrigido e testes separados dos controles que segmentam o ambiente de dados do titular do cartão (com mais frequência para provedores de serviços). O teste deve ser executado por um testador qualificado que seja organizacionalmente independente dos sistemas sob teste.
O teste autônomo pode satisfazê-lo? Não. A própria Orientação para Teste de Penetração do PCI traça uma linha entre um teste de penetração e uma varredura de vulnerabilidades: uma varredura é automatizada, enquanto um teste de penetração é um processo manual de exploração que depende da habilidade de um testador qualificado e independente. Ferramentas automatizadas podem auxiliar, mas a orientação trata o trabalho manual como o próprio teste. Um teste de penetração autônomo não será aceito como o teste de penetração do PCI.
Os agentes do Aikido exploram a lógica de negócios, BOLA e falhas encadeadas, então vale a pena executá-los como testes de segurança contínuos juntamente com o engajamento exigido, inclusive após mudanças significativas. Isso é um benefício de segurança e uma fonte de evidência de remediação, não uma aprovação PCI. Planeje o pentest humano qualificado separadamente.
Veredito: Não atende ao requisito. O teste de penetração deve ser realizado por um testador humano qualificado. Testes autônomos não serão aceitos como o pentest PCI.
Referência: Requisito 11.4 do PCI DSS v4.0.1 (11.4.1 a 11.4.6); Orientação de Teste de Penetração do PCI SSC.
DORA
O requisito: DORA possui dois níveis de testes. O nível geral é um programa de testes de resiliência operacional digital que toda entidade financeira deve estabelecer, e o teste de penetração é um dos métodos que deve ser utilizado. O nível avançado exige Testes de Penetração Orientados por Ameaças (TLPT) pelo menos uma vez a cada três anos para entidades financeiras significativas, com regras rigorosas sobre quem pode executá-los.
Testes autônomos podem satisfazê-lo? Sim para o programa geral, não para o TLPT. O programa geral é flexível em termos de métodos e seus métodos listados incluem testes de penetração, então testes autônomos contínuos se encaixam e vão além do mínimo periódico. O TLPT é diferente. Ele é modelado no framework TIBER-EU do BCE e exige red-teamers externos e qualificados e um provedor externo de threat intelligence, com instituições de crédito significativas sendo obrigadas a usar exclusivamente testadores externos. Ou seja, por design, é um engajamento de red-team humano.
Veredito: Sim para o programa de testes geral. Não atenderá ao requisito do TLPT, que exige red-teamers humanos externos. Use o Aikido para executar e evidenciar o programa geral. O TLPT é um engajamento separado que deve ser realizado por humanos.
Referência: DORA (Regulamento (UE) 2022/2554) Artigos 24 e 25 (programa de testes), Artigos 26 e 27 (TLPT).
Regra de Salvaguardas da FTC
O requisito: A Regra de Salvaguardas da FTC rege como as instituições financeiras protegem as informações dos clientes. Ela exige testes regulares de quão bem suas salvaguardas funcionam, e oferece duas maneiras de fazê-lo: monitoramento contínuo, ou, em sua ausência, um teste de penetração anual mais avaliações de vulnerabilidade pelo menos a cada seis meses. Testes também são exigidos após grandes mudanças nas operações.
Testes autônomos podem satisfazê-lo? Sim. O monitoramento contínuo está previsto como uma alternativa direta ao teste de penetração anual, que é o que os testes autônomos contínuos fornecem. Para uma instituição que prefere a rota periódica, um programa autônomo fornece tanto o teste anual quanto as avaliações semestrais. A regra não estabelece requisitos humanos ou de acreditação para o testador.
Veredito: Sim. O monitoramento contínuo é um substituto explícito para o pentest anual.
Referência: Regra de Salvaguardas da FTC, 16 CFR 314.4(d) e 314.4(d)(2).
Regulamentação de Cibersegurança NYDFS
O requisito: A regulamentação de cibersegurança para serviços financeiros de Nova York se aplica a bancos, seguradoras e outras entidades licenciadas em Nova York, e é referenciada além do estado como uma linha de base para o setor financeiro. Sua seção de testes de penetração exige testes construídos em torno de sua avaliação de risco, estruturados como monitoramento contínuo ou um teste de penetração anual juntamente com avaliações de vulnerabilidade semestrais.
Testes autônomos podem satisfazê-lo? Sim. Assim como na regra da FTC, a regulamentação trata o monitoramento contínuo e o teste de penetração anual como alternativas. Testes autônomos contínuos se alinham com o caminho do monitoramento contínuo, e para entidades que escolhem a rota periódica, ele também produz o teste anual e as avaliações semestrais. A regulamentação não estabelece requisitos de acreditação para o testador.
Veredito: Sim. O monitoramento contínuo satisfaz o requisito por si só.
Referência: Regulamentação de Cibersegurança NYDFS, 23 NYCRR 500.5 (Segunda Emenda, 2023).
Indústria da Saúde
HIPAA
O requisito: A Regra de Segurança da HIPAA não nomeia explicitamente o teste de penetração. Seu padrão de avaliação exige uma avaliação técnica e não técnica periódica de suas salvaguardas, que é o que os pentests geralmente abrangem. Uma atualização proposta de dezembro de 2024 tornaria explícito, exigindo varredura de vulnerabilidades pelo menos a cada seis meses e testes de penetração pelo menos uma vez por ano. Em meados de 2026, essa atualização não é final, mas a direção é clara.
Testes autônomos podem satisfazê-lo? Sim. Nem o padrão de avaliação atual nem a atualização proposta exigem um testador humano. Um relatório autônomo é evidência de uma avaliação técnica periódica hoje, e satisfaria a obrigação proposta de pentest anual amanhã, com testes contínuos excedendo uma cadência de uma vez por ano.
Veredito: Sim, e pronto para a regra proposta.
Referência: Regra de Segurança da HIPAA, 45 CFR 164.308(a)(8); NPRM de 2024 (RIN 0945-AA22).
HITRUST CSF
O requisito: O HITRUST CSF é um framework certificável que organizações de saúde dos EUA e seus fornecedores usam para demonstrar a proteção de Informações de Saúde Protegidas (PHI). O teste de penetração se enquadra em seus requisitos de conformidade técnica e avaliação de segurança. Para a certificação superior (r2), o teste deve ocorrer dentro de uma janela contínua de 12 meses e ser executado como um programa contínuo, em vez de um único evento anual, com os achados rastreados e retestados.
Testes autônomos podem satisfazê-lo? Sim O HITRUST não exige um testador humano ou credenciado para o teste de penetração, e sua preferência por um programa contínuo em vez de um evento anual se alinha com testes autônomos contínuos. Um relatório de teste de penetração autônomo é uma evidência válida para o avaliador.
Veredito: Sim para o requisito de teste de penetração. A validação do Avaliador Externo é uma etapa de auditoria separada.
Referência: controle HITRUST CSF 06.h (Verificação de Conformidade Técnica).
Orientação de cibersegurança pré-mercado da FDA
O requisito: A orientação da FDA Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions recomenda uma abordagem de teste de segurança em camadas, mas na prática exige um relatório de teste de penetração durante as submissões pré-mercado.
O teste autônomo pode satisfazê-lo? Sim. A orientação é orientada para resultados: ela quer evidências de que o teste foi realizado, por quem, qual o escopo, o que foi encontrado e, o mais importante, o que foi feito a respeito. Em última análise, trata-se de garantir que os riscos de segurança estejam sob controle. O relatório de pentest de IA da Aikido atende a essas expectativas.
Veredito: Sim, mas documente o escopo, os métodos e a independência na submissão.
Referência: Seção 524B do FD&C Act; orientação de cibersegurança pré-mercado da FDA (2025).
Regulamento de Dispositivos Médicos da UE (MDR)
O requisito: Os requisitos gerais de segurança e desempenho do MDR esperam que o software de dispositivos médicos seja desenvolvido de acordo com o estado da arte, com verificação e validação e medidas mínimas de segurança de TI ao longo da vida útil do produto. A orientação de cibersegurança para dispositivos médicos da UE (MDCG 2019-16) nomeia o teste de penetração como parte dessa verificação e validação, juntamente com testes de recursos de segurança, fuzzing e varredura de vulnerabilidades.
O teste autônomo pode satisfazê-lo? Sim. O MDR e sua orientação são neutros em relação ao método, e um teste de penetração autônomo é uma evidência válida de verificação e validação. O teste contínuo também se encaixa melhor na ênfase do ciclo de vida do que um teste único. Semelhante à orientação da FDA, trata-se de provar que os riscos de segurança estão sob controle.
Veredito: Sim.
Referência: MDR da UE (Regulamento (UE) 2017/745) Anexo I, GSPR 17.2 e 17.4; orientação MDCG 2019-16.
IEC 81001-5-1
O requisito: Este é o padrão de ciclo de vida de software seguro para software de saúde e será harmonizado para o MDR. Suas atividades de teste de sistema de software incluem teste de requisitos de segurança, teste de mitigação de ameaças, teste de vulnerabilidade e teste de penetração. O padrão exige que o teste de penetração seja realizado por um departamento ou organização independente dos desenvolvedores, e possui uma disposição separada sobre a gestão de conflitos de interesse entre testadores e desenvolvedores.
O teste autônomo pode satisfazê-lo? Sim, e o requisito de independência é um ponto a seu favor. O que o padrão exige é independência organizacional dos desenvolvedores, não um testador humano. Como um terceiro externo, Aikido satisfaz esse requisito de independência, enquanto a metodologia autônoma e o registro de auditoria fornecem a atividade documentada e repetível que o padrão espera.
Veredito: Sim, a independência de terceiros satisfaz o padrão.
Referência: IEC 81001-5-1:2021 cláusula 5.7.4 (mapeada para SVV-4) e 5.7.5.
Automotivo
ISO/SAE 21434
O requisito: A cibersegurança automotiva baseia-se na ISO/SAE 21434, o padrão de engenharia para cibersegurança veicular, sua metodologia de risco e Análise de Ameaças e Avaliação de Riscos (“TARA”). O padrão nomeia o teste de penetração como uma forma de validar que os objetivos de cibersegurança foram atingidos.
O teste autônomo pode satisfazê-lo? Sim, para as partes que ele pode alcançar. O padrão é baseado em resultados. O teste de penetração é um método de validação entre vários (por exemplo, fuzzing, SAST, DAST, …), e um relatório de pentest autônomo é uma evidência válida, com o teste contínuo se encaixando também na ênfase do ciclo de vida. Uma ressalva: veículos são construídos com componentes embarcados, testes de segurança física em nível de hardware não podem ser realizados por métodos autônomos.
Veredito: Sim para a superfície de ataque conectada e de backend. O padrão é flexível em relação ao método e aceita testes autônomos como evidência de validação.
Referência: validação de cibersegurança ISO/SAE 21434:2021 (Cláusula 11, RQ-11-01).
Setor governamental e público
ENS
O requisito: O Esquema Nacional de Seguridad da Espanha lista o teste de penetração como uma medida de segurança explícita. É obrigatório para sistemas de alta categoria e recomendado para sistemas de média categoria, e os resultados recentes alimentam a auditoria periódica da estrutura.
O teste autônomo pode satisfazê-lo? Sim. O ENS especifica que você testa, não quem o insere. Os resultados de pentest autônomo satisfazem a medida, e o teste contínuo supera as frequências anuais (alta) e bienais (média) recomendadas.
Veredito: Sim, pentests autônomos cumprem o requisito.
Referência: ENS (Real Decreto 311/2022) Anexo II medida mp.s.3; auditoria periódica sob o Artigo 31.
NIST SP 800-53
O requisito: O NIST 800-53 possui um controle dedicado para testes de penetração. Ele exige testes de penetração em uma frequência definida pela organização, prevê um agente ou equipe de penetração independente e adiciona exercícios de red-team como um aprimoramento. O controle afirma explicitamente que o teste de penetração vai além da varredura automatizada de vulnerabilidades e é realizado por agentes e equipes com habilidades demonstráveis.
O teste autônomo pode satisfazê-lo? Em grande parte sim, mais do que o PCI. O controle é estruturado em torno da independência e de ir além da varredura, ambos os quais o Aikido atende: é uma terceira parte independente, e explora e valida em vez de apenas escanear. O controle até usa a palavra “agentes”. O julgamento residual, se um agente autônomo demonstra as “habilidades” exigidas, cabe à autoridade avaliadora, portanto, confirme a aceitação com seu avaliador.
Veredito: Sim, com a concordância do avaliador. Independência e “além da varredura” são claramente atendidos.
Referência: NIST SP 800-53 Rev. 5, controle CA-8 (com CA-8(1) e CA-8(2)).
EO 14028 dos EUA
O requisito: Esta ordem executiva dos EUA impulsionou o Secure Software Development Framework (SSDF). O framework possui uma prática para testar código executável para encontrar vulnerabilidades, onde se encaixam os testes dinâmicos, fuzzing e testes de penetração. Fornecedores de agências federais dos EUA autoatestam seguir o framework em um formulário de atestado da CISA.
O teste autônomo pode satisfazê-lo? Sim. O framework é neutro em relação à tecnologia. Um teste de penetração autônomo é uma maneira legítima de atender à prática de teste de código, e seu relatório é a evidência por trás da autoatestação.
Veredito: Sim, testes humanos ou manuais não são exigidos.
Referência: EO 14028 Seção 4(e); prática PW.8 e PW.8.2 do NIST SSDF (SP 800-218); Formulário de Atestação de Desenvolvimento de Software Seguro da CISA (OMB M-22-18).
FedRAMP
O requisito: O FedRAMP exige um teste de penetração anual em suas baselines, executado com um conjunto obrigatório de vetores de ataque e realizado por uma organização de avaliação de terceiros credenciada (uma 3PAO) para sistemas Moderados e Altos.
O teste autônomo pode satisfazê-lo? Não. O teste de penetração por trás de uma autorização FedRAMP, e o pentest anual que a mantém, deve ser realizado por uma 3PAO credenciada. Um teste autônomo por uma não-3PAO não será aceito em um pacote de autorização ou em uma avaliação anual. Ele pode ser executado entre esses engajamentos como um teste de segurança adicional, mas isso não é evidência de autorização.
Veredito: Não atende ao requisito. Os pentests devem ser realizados por uma organização terceirizada credenciada.
Referência: FedRAMP Penetration Test Guidance; controle CA-8 do NIST SP 800-53; acreditação 3PAO pela A2LA.
FISMA
O requisito: A FISMA herda suas expectativas de teste do NIST 800-53, aplicadas através do Risk Management Framework do NIST. O escopo e o rigor são definidos pela agência e pela categorização do sistema.
O teste autônomo pode satisfazê-lo? Geralmente sim, a mesma lógica do controle NIST 800-53, sujeito aos requisitos de avaliação da agência. Para sistemas que também buscam uma autorização externa com regras de avaliador credenciado (como o FedRAMP), deve-se seguir as restrições desse programa.
Veredito: Sim, mas a critério da agência.
Referência: FISMA via NIST SP 800-53 (CA-8) e NIST SP 800-37 (Risk Management Framework).
Padrões internacionais
SOC 2
O requisito: O SOC 2 não exige explicitamente um pentest, mas os Critérios de Serviços de Confiança do AICPA (o órgão regulador por trás do SOC 2) apontam para um: o critério de monitoramento menciona o teste de penetração como um método de avaliação aceitável, e o critério de detecção de novas vulnerabilidades é suportado por testes ativos. Na prática, os auditores esperam evidências de pentest, especialmente para um relatório Tipo II, dentro do período de auditoria, com evidências de remediação e reteste.
O teste autônomo pode satisfazê-lo? Sim. Um teste independente de terceiros é uma evidência mais forte do que um teste interno, e a linguagem “avaliações contínuas ou separadas” aponta para testes contínuos.
Veredito: Sim. O teste contínuo se alinha diretamente com “avaliações contínuas”.
Referência: Critérios de Serviços de Confiança AICPA CC4.1 e CC7.1
ISO/IEC 27001
O requisito: Alguns dos controles do Anexo A da ISO 27001 são os pontos-chave: um sobre gerenciamento de vulnerabilidades técnicas, que exige “testes de penetração ou avaliações de vulnerabilidade planejados, documentados e repetíveis por pessoas competentes e autorizadas”; um sobre testes de segurança em desenvolvimento e aceitação; e um sobre o ciclo de vida de desenvolvimento seguro.
O teste autônomo pode satisfazê-lo? Sim. A linguagem na norma é quase uma descrição de teste autônomo, e a reprodutibilidade é inerente à forma como os agentes operam. Os auditores aceitam testes automatizados e contínuos de terceiros como evidência aqui, e o relatório e o registro de auditoria fornecem a parte “documentada”.
Veredito: Sim. Testes 'repetíveis' são um encaixe natural.
Referência: ISO/IEC 27001:2022 Anexo A; controles ISO/IEC 27002:2022 8.8, 8.25 e 8.29.
Regulamentações Europeias
Diretiva NIS2
O requisito: A NIS2 exige que as organizações abrangidas lidem com vulnerabilidades e tenham políticas para avaliar a eficácia de suas medidas de segurança. O regulamento de implementação detalha isso com requisitos de gerenciamento de vulnerabilidades e testes de segurança automatizados ou manuais, testes de penetração e varreduras de vulnerabilidades, realizados regularmente e após mudanças significativas.
O teste autônomo pode satisfazê-lo? Sim, explicitamente. O regulamento de implementação da NIS2 é um dos poucos instrumentos que nomeia testes automatizados e testes de penetração como métodos aceitáveis. O teste autônomo contínuo corresponde à linguagem de 'base regular e após mudanças significativas', e o relatório é uma evidência tanto para as obrigações de gerenciamento de vulnerabilidades quanto para as de avaliação de eficácia.
Veredito: Sim. Testes automatizados e de penetração são expressamente contemplados.
Referência: Diretiva NIS2 (UE) 2022/2555 Artigo 21(2)(e) e (f); Regulamento de Implementação (UE) 2024/2690 Anexo pontos 6.10 e 7.1.
GDPR
O requisito: O GDPR exige um processo para testar, avaliar e analisar regularmente a eficácia de suas medidas de segurança técnicas e organizacionais.
O teste autônomo pode satisfazê-lo? Sim. O GDPR não prescreve um método e enfatiza testes regulares, então o teste autônomo contínuo é uma demonstração mais forte de um processo contínuo do que um PDF anual. O relatório evidencia tanto o teste quanto o ciclo de remediação.
Veredito: Sim, favorece o teste contínuo.
Referência: GDPR (Regulamento (UE) 2016/679) Artigo 32(1)(d).
Lei de Ciber-Resiliência
O requisito: A Lei de Ciber-Resiliência exige que produtos com elementos digitais sejam colocados no mercado sem vulnerabilidades exploráveis conhecidas e, como parte do gerenciamento de vulnerabilidades ao longo da vida útil do produto, que apliquem testes e revisões eficazes e regulares da segurança do produto.
O teste autônomo pode satisfazê-lo? Sim. Testes 'eficazes e regulares' é o que o pentest autônomo contínuo oferece ao longo do ciclo de vida do produto, e o relatório apoia tanto a obrigação de teste quanto a barra de 'nenhuma vulnerabilidade explorável conhecida' no lançamento.
Veredito: Sim, testes 'regulares' favorecem o pentest autônomo.
Referência: Lei de Ciber-Resiliência (Regulamento (UE) 2024/2847) Anexo I (Parte I e Parte II ponto 3); Artigo 13.
FAQ
O pentest de IA funciona para a conformidade SOC 2?
Sim, na maioria dos casos. O SOC 2 não especifica quem ou o que conduz um pentest, apenas que o teste foi realizado, as descobertas foram documentadas com evidências e as questões críticas foram abordadas.
Os auditores aceitarão um relatório de pentest de IA?
A maioria aceitará, desde que o relatório inclua descobertas validadas com evidências de prova de conceito, uma seção de metodologia, classificações de severidade e orientação de remediação. O principal risco de rejeição é enviar a saída de um scanner automatizado disfarçada de pentest, e não um pentest de IA genuíno.
Qual a diferença entre pentest de IA e varredura automatizada?
Scanners automatizados fazem correspondência de padrões contra assinaturas de vulnerabilidades conhecidas e sinalizam problemas potenciais sem confirmar se são realmente exploráveis. Um pentest de IA genuíno raciocina sobre como a aplicação funciona, tenta explorar descobertas contra um alvo real e só apresenta vulnerabilidades que foram realmente confirmadas.
O SOC 2 exige um pentester humano?
Não. O SOC 2 é baseado em resultados, o que significa que ele define o que seus controles devem demonstrar com base em suas políticas de segurança escritas, em vez de como o teste deve ser conduzido. A estrutura se alinha aos controles Common Criteria como CC4.1 e CC7.1, e um relatório de pentest de IA bem documentado satisfaz esses requisitos.
O pentest de IA pode substituir o pentest manual para conformidade?
Para a maioria dos programas SOC 2, ISO 27001 e HIPAA, sim. Certos ambientes regulamentados, como indústrias do Reino Unido que exigem certificação CREST ou agências federais dos EUA que exigem autorização FedRAMP, têm requisitos de acreditação que atualmente exigem um humano para co-assinar o trabalho.
Com que frequência preciso executar um pentest para conformidade?
A maioria dos frameworks espera testes anuais no mínimo, além de retestes após a introdução de mudanças significativas em sua aplicação ou infraestrutura. O pentest de IA pode cobrir isso para SOC 2 e ISO 27001. O PCI DSS é um framework mais prescritivo, exigindo explicitamente testes internos e externos anualmente e após qualquer mudança significativa no ambiente de dados do titular do cartão. O pentest de IA cobre grande parte da porção de camada de aplicação desse requisito, mas precisa ser usado por um pentester humano. Testes de camada de rede e segmentação exigem cobertura separada, tipicamente de um pentester humano.
Quais frameworks exigem explicitamente pentest?
O PCI DSS o exige explicitamente na seção 11.4, e o FedRAMP o exige como parte da autorização de provedor de serviços Cloud. SOC 2, ISO 27001 e HIPAA não o tornam obrigatório de imediato, mas os auditores rotineiramente o esperam como evidência de que os controles de segurança estão funcionando.
O que um relatório de pentest precisa incluir para conformidade?
No mínimo: um sumário executivo, uma seção de metodologia e escopo, descobertas validadas com evidências de prova de conceito e passos de reprodução, classificações de severidade e um plano de remediação. Para o SOC 2 especificamente, as descobertas devem ser mapeadas para os Critérios de Serviços de Confiança relevantes.
O pentest de IA é aceito para ISO 27001?
Sim. A ISO 27001 recomenda o pentest como parte da avaliação de risco contínua, mas não especifica como ele deve ser conduzido. Um relatório que documenta o que foi testado, como e o que foi encontrado satisfaz os requisitos de evidência do framework.
Quais são as limitações do pentest de IA com a conformidade?
Testes de segurança física e engenharia social estão fora do escopo de qualquer pentest focado em aplicações, seja de IA ou não. O PCI DSS precisa de um pentester humano para testes de rede e segmentação, no mínimo. Indústrias com requisitos de acreditação específicos, como CREST no Reino Unido ou requisitos 3PAO sob o FedRAMP, podem precisar de etapas adicionais antes que um pentest de IA satisfaça completamente suas obrigações de compliance.
