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.
Deslize até ao final do artigo para saber mais, em pormenor, sobre como funciona o teste de penetração com IA em diferentes estruturas.
O que os auditores procuram
Em suma, os auditores ou as normas procuram, na verdade, o seguinte num teste de penetração:
- Uma metodologia documentada e repetível, e não uma abordagem ad hoc
- Independência, e o facto de a equipa de testes não ser a mesma que desenvolve ou gere o sistema
- Testes reais de eficácia, que vão além da análise automatizada de vulnerabilidades
- Evidências, tais como resultados, gravidade e provas
- Correção e nova análise dos resultados
Se o seu teste de penetração cumprir estes critérios, quer seja realizado por IA ou por pessoas, há boas hipóteses de o seu auditor o aceitar.
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 afirmação pontual em um registro vivo. Em vez de dizer a um auditor "executamos um pentest em 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 inferiores. Cada mudança que impacta sua superfície de ataque foi testada, então os problemas foram detectados e corrigidos antes que chegassem à 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: Características específicas do setor
Setor Financeiro
PCI DSS
O requisito: a norma PCI DSS é o quadro regulamentar mais prescritivo neste contexto. Exige uma metodologia documentada de testes de penetração, a realização de testes de penetração internos e externos pelo menos uma vez por ano e após alterações significativas, a repetição dos testes em tudo o que for corrigido e a realização de testes separados dos controlos que segmentam o ambiente de dados dos titulares de cartões (com maior frequência no caso dos prestadores de serviços). O teste tem de ser realizado por um técnico qualificado que seja organizacionalmente independente dos sistemas em teste.
Será que os testes autónomos podem satisfazer este requisito? Não. As próprias Orientações sobre Testes de Penetração da PCI estabelecem uma distinção entre um teste de penetração e uma análise de vulnerabilidades: uma análise é automatizada, enquanto um teste de penetração é um processo manual de exploração que depende da competência de um testador qualificado e independente. As ferramentas automatizadas podem ajudar, mas as orientações consideram que o trabalho manual constitui o próprio teste. Um teste de penetração autónomo não será aceite como o teste de penetração exigido pela PCI.
Os agentes Aikidoexploram a lógica de negócio, o BOLA e falhas em cadeia, pelo que vale a pena executá-los como testes de segurança contínuos das atividades obrigatórias, incluindo após alterações significativas. Trata-se de um benefício de segurança e de uma fonte de provas de correção, não de uma certificação PCI. Planeie o teste de penetração humano qualificado separadamente.
Conclusão: Não cumpre o requisito. O teste de penetração deve ser realizado por um técnico qualificado. Os testes autónomos não serão aceites como teste de penetração PCI.
Referência: Requisito 11.4 (11.4.1 a 11.4.6) da norma PCI DSS v4.0.1; Orientações do PCI SSC sobre testes de penetração.
DORA
O requisito: a DORA prevê dois níveis de testes. O nível geral consiste num programa de testes de resiliência operacional digital que todas as entidades financeiras devem implementar, sendo que os testes de penetração constituem um dos métodos que devem utilizar. O nível avançado exige a realização de Testes de Penetração Orientados para Ameaças (TLPT) pelo menos uma vez a cada três anos para as entidades financeiras de maior dimensão, com regras rigorosas quanto a quem os pode realizar.
Será que os testes autónomos satisfazem este requisito? Sim, no caso do programa geral; não, no caso do TLPT. O programa geral é flexível em termos de métodos e os métodos nele enumerados incluem testes de penetração, pelo que os testes autónomos contínuos se enquadram nele e vão além do mínimo periódico exigido. O TLPT é diferente. Baseia-se no quadro TIBER-EU do BCE e exige a participação de membros externos e qualificados de uma «equipa vermelha», bem como de um prestador externo de informações sobre ameaças, sendo que as instituições de crédito de grande dimensão são obrigadas a recorrer exclusivamente a testadores externos. Trata-se, por definição, de um envolvimento humano da «equipa vermelha».
Conclusão: Sim, no que diz respeito ao programa de testes geral. Este não cumprirá o requisito do TLPT, que exige a participação de especialistas externos em simulação de ataques (red-teamers). Utilize Aikido executar e documentar o programa geral. O TLPT é um processo distinto que deve ser realizado por pessoas.
Referência: DORA (Regulamento (UE) n.º 2022/2554), artigos 24.º e 25.º (programa de ensaios), artigos 26.º e 27.º (TLPT).
Regra de Salvaguardas da FTC
O requisito: A Regra de Medidas de Proteção da FTC regula a forma como as instituições financeiras protegem as informações dos clientes. Exige a realização de testes regulares para avaliar a eficácia das suas medidas de proteção e oferece duas formas de o fazer: monitoramento contínuo ou, na sua ausência, um teste de penetração anual, além de avaliações de vulnerabilidade pelo menos a cada seis meses. Também é necessário realizar testes após alterações significativas nas operações.
Os testes autónomos podem satisfazer esse requisito? Sim. monitoramento contínuo apresentado como uma alternativa direta ao teste de penetração anual, que é precisamente o que os testes autónomos contínuos proporcionam. Para uma instituição que prefira a abordagem periódica, um único programa autónomo permite realizar tanto o teste anual como as avaliações semestrais. A norma não estabelece qualquer requisito relativo ao pessoal ou à acreditação do responsável pelos testes.
Conclusão: Sim. monitoramento contínuo um substituto explícito do teste de penetração anual.
Referência: Regra de Salvaguardas da FTC, 16 CFR 314.4(d) e 314.4(d)(2).
Regulamento do NYDFS em matéria de cibersegurança
O requisito: A regulamentação de cibersegurança dos serviços financeiros de Nova Iorque aplica-se a bancos, seguradoras e outras entidades licenciadas em Nova Iorque, sendo considerada fora do estado como uma referência para o setor financeiro. A secção relativa aos testes de penetração exige que os testes sejam concebidos com base na avaliação de riscos da sua entidade, estruturados quer como monitoramento contínuo um teste de penetração anual, a par de avaliações de vulnerabilidade semestrais.
Os testes autónomos podem satisfazer este requisito? Sim. Tal como acontece com a norma da FTC, o regulamento considera monitoramento contínuo o teste de penetração anual como alternativas. Os testes autónomos contínuos correspondem à via do monitoramento contínuo e, para as entidades que optam pela via periódica, também resultam no teste anual e nas avaliações semestrais. O regulamento não estabelece qualquer requisito de acreditação dos testadores.
Conclusão: Sim. monitoramento contínuo , por si só, monitoramento contínuo o requisito.
Referência: Regulamento de Cibersegurança do NYDFS, 23 NYCRR 500.5 (Segunda Alteração, 2023).
Setor da Saúde
HIPAA
O requisito: a Regra de Segurança da HIPAA não menciona explicitamente os testes de penetração. O seu critério de avaliação exige uma avaliação periódica, tanto técnica como não técnica, das suas medidas de segurança, sendo este o âmbito em que os testes de penetração normalmente se enquadram. Uma atualização proposta para dezembro de 2024 tornaria isso explícito, exigindo a realização de análises de vulnerabilidades pelo menos de seis em seis meses e de testes de penetração pelo menos uma vez por ano. Em meados de 2026, essa atualização ainda não estava finalizada, mas a orientação é clara.
Os testes autónomos podem satisfazer esse requisito? Sim. Nem a norma de avaliação atual nem a atualização proposta exigem a intervenção de um testador humano. Um relatório autónomo constitui, atualmente, prova de uma avaliação técnica periódica e satisfaria, no futuro, a obrigação proposta de realizar testes de penetração anuais, com testes contínuos que excedem uma frequência anual.
Conclusão: Sim, e estamos prontos 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 quadro de certificação utilizado pelas organizações de cuidados de saúde dos EUA e pelos seus fornecedores para demonstrar a proteção das Informações de Saúde Protegidas (PHI). Os testes de penetração fazem parte dos seus requisitos de conformidade técnica e de avaliação de segurança. Para a certificação de nível superior (r2), os testes devem ser realizados num período contínuo de 12 meses e decorrer como um programa contínuo, em vez de um evento anual único, com os resultados a serem acompanhados e submetidos a novos testes.
Os testes autónomos podem satisfazer este requisito? Sim, a HITRUST não exige a intervenção de um testador humano ou acreditado para o teste de penetração, e a sua preferência por um programa contínuo em vez de um evento anual está em consonância com os testes autónomos contínuos. Um relatório de teste de penetração autónomo constitui prova válida para o avaliador.
Conclusão: Sim, no que diz respeito ao requisito de testes de penetração. A validação pelo Avaliador Externo constitui uma etapa de auditoria distinta.
Referência: Controlo 06.h do HITRUST CSF (Verificação da Conformidade Técnica).
Orientações da FDA sobre cibersegurança antes da comercialização
O requisito: O documento de orientação da FDA intitulado «Cibersegurança em dispositivos médicos: considerações relativas ao sistema de qualidade e conteúdo dos pedidos de autorização de comercialização» recomenda uma abordagem de testes de segurança em camadas, mas, na prática, exige a apresentação de um relatório de teste de penetração durante os pedidos de autorização de comercialização.
Os testes autónomos podem satisfazer esses requisitos? Sim. As orientações são orientadas para os resultados: pretendem provas de que os testes foram realizados, por quem, qual foi o âmbito, o que foi detetado e, mais importante ainda, o que foi feito a esse respeito. Em última análise, trata-se de garantir que os riscos de segurança estão sob controlo. O relatório de testes de penetração com IA Aikidocumpre essas expectativas.
Conclusão: Sim, mas indique o âmbito do documento, os métodos utilizados e a independência na proposta.
Referência: Secção 524B da Lei FD&C; orientações da FDA sobre cibersegurança antes da comercialização (2025).
Regulamento da UE relativo aos dispositivos médicos (MDR)
O requisito: Os requisitos gerais de segurança e desempenho do MDR exigem que o software dos dispositivos médicos seja desenvolvido de acordo com o estado da arte, com verificação e validação, bem como medidas mínimas de segurança informática ao longo de todo o ciclo de vida do produto. As orientações da UE sobre cibersegurança dos dispositivos médicos (MDCG 2019-16) referem os testes de penetração como parte dessa verificação e validação, a par dos testes às funcionalidades de segurança, do fuzzing e da deteção de vulnerabilidades.
Será que os testes autónomos satisfazem este requisito? Sim. O MDR e as suas orientações são neutros em termos de método, e um teste de penetração autónomo constitui uma prova válida de verificação e validação. Os testes contínuos também se adequam melhor à ênfase no ciclo de vida do que um teste pontual. À semelhança das orientações da FDA, o que importa é provar que os riscos de segurança estão sob controlo.
Conclusão: Sim.
Referência: MDR da UE (Regulamento (UE) n.º 2017/745), Anexo I, GSPR 17.2 e 17.4; orientação MDCG 2019-16.
IEC 81001-5-1
O requisito: Trata-se da norma relativa ao ciclo de vida seguro do software para software na área da saúde, que será harmonizada com o MDR. As suas atividades de teste de sistemas de software incluem testes de requisitos de segurança, testes de mitigação de ameaças, testes de vulnerabilidades e testes de penetração. A norma exige que os testes de penetração sejam realizados por um departamento ou organização independente dos programadores e inclui uma disposição específica sobre a gestão de conflitos de interesses entre os testadores e os programadores.
Os testes autónomos podem satisfazer esse requisito? Sim, e o requisito de independência é um ponto a seu favor. O que a norma exige é independência organizacional em relação aos programadores, não em relação a um testador humano. Enquanto entidade externa, Aikido esse requisito de independência, ao mesmo tempo que a metodologia autónoma e a pista de auditoria proporcionam a atividade documentada e repetível que a norma espera.
Conclusão: Sim, a independência de terceiros cumpre o requisito.
Referência: IEC 81001-5-1:2021, cláusulas 5.7.4 (correspondente à SVV-4) e 5.7.5.
Automóvel
ISO/SAE 21434
O requisito: A cibersegurança automóvel baseia-se na norma ISO/SAE 21434, a norma de engenharia relativa à cibersegurança dos veículos, na sua metodologia de risco e na Análise de Ameaças e Avaliação de Riscos («TARA»). A norma refere os testes de penetração como uma forma de validar que os objetivos de cibersegurança foram cumpridos.
Os testes autónomos podem satisfazer esse requisito? Sim, nas partes a que conseguem aceder. A norma baseia-se nos resultados. Os testes de penetração são um dos vários métodos de validação (por exemplo, fuzzing, SAST, DAST, …), e um relatório de teste de penetração autónomo constitui uma prova válida, sendo que os testes contínuos também se enquadram na ênfase dada ao ciclo de vida. Uma ressalva: os veículos são construídos com componentes incorporados, pelo que os testes de segurança física ao nível do hardware não podem ser realizados através de métodos autónomos.
Conclusão: Sim, no que diz respeito à superfície de ataque das ligações e do backend. A norma é flexível em termos de métodos e aceita testes autónomos como prova de validação.
Referência: Validação da cibersegurança segundo a norma ISO/SAE 21434:2021 (Cláusula 11, RQ-11-01).
Governo e setor público
ENS
O requisito: O Esquema Nacional de Segurança de Espanha inclui os testes de penetração como uma medida de segurança explícita. São obrigatórios para os sistemas de categoria elevada e recomendados para os sistemas de categoria média, e os resultados recentes servem de base para a auditoria periódica do quadro regulamentar.
Os testes autónomos podem satisfazer este requisito? Sim. A norma ENS especifica que o que importa é o teste, e não quem o realiza. Os resultados dos testes de penetração autónomos satisfazem este requisito, e os testes contínuos superam as frequências recomendadas: anual (alta) e bienal (média).
Conclusão: Sim, os testes de penetração autónomos cumprem o requisito.
Referência: ENS (Decreto-Real n.º 311/2022), Anexo II, medida mp.s.3; auditoria periódica nos termos do artigo 31.º.
NIST SP 800-53
O requisito: A norma NIST 800-53 inclui um controlo específico relativo aos testes de penetração. Este exige a realização de testes de penetração com a frequência definida pela organização, prevê a contratação de um agente ou equipa independente para a realização desses testes e acrescenta exercícios de «red team» como medida de reforço. O controlo especifica explicitamente que os testes de penetração vão além da análise automatizada de vulnerabilidades e são realizados por agentes e equipas com competências comprovadas.
Será que os testes autónomos satisfazem este requisito? Em grande medida, sim, mais do que o PCI. O controlo centra-se na independência e em ir além da simples análise, requisitos que Aikido : é uma entidade terceira independente e explora e valida, em vez de se limitar a analisar. O controlo chega mesmo a utilizar a palavra «agentes». A avaliação final, ou seja, se um agente autónomo demonstra as «competências» exigidas, cabe à autoridade avaliadora; por isso, confirme a aceitação junto do seu avaliador.
Veredicto: Sim, com o consentimento do avaliador. Os critérios de independência e de «ir além da simples análise superficial» estão claramente preenchidos.
Referência: NIST SP 800-53 Rev. 5, controlo CA-8 (com CA-8(1) e CA-8(2)).
Decreto Presidencial n.º 14028 dos EUA
O requisito: Este decreto presidencial dos EUA deu origem ao Quadro de Desenvolvimento Seguro de Software (SSDF). O quadro inclui uma prática de teste de código executável para detetar vulnerabilidades, que abrange os testes dinâmicos, o fuzzing e os testes de penetração. Os fornecedores das agências federais dos EUA declaram, por meio de um formulário de atestado da CISA, que cumprem o quadro.
Os testes autónomos podem satisfazer esse requisito? Sim. O quadro é tecnologicamente neutro. Um teste de penetração autónomo é uma forma legítima de cumprir a prática de teste de código, e o seu relatório constitui a prova subjacente à auto-declaração.
Conclusão: Sim, não é necessário realizar testes manuais ou realizados por pessoas.
Referência: EO 14028, secção 4(e); práticas PW.8 e PW.8.2 do SSDF do NIST (SP 800-218); Formulário de Certificação de Desenvolvimento Seguro de Software da CISA (OMB M-22-18).
FedRAMP
O requisito: O FedRAMP exige a realização de um teste de penetração anual em todas as suas linhas de base, executado com base num conjunto obrigatório de vetores de ataque e realizado por uma organização de avaliação independente acreditada (uma 3PAO) para sistemas com classificação «Moderada» e «Elevada».
Os testes autónomos podem satisfazer esse requisito? Não. O teste de penetração subjacente a uma autorização FedRAMP, bem como o teste de penetração anual que a mantém, devem ser realizados por uma 3PAO acreditada. Um teste autónomo realizado por uma entidade que não seja uma 3PAO não será aceite num dossiê de autorização nem numa avaliação anual. Pode ser realizado entre esses processos como um teste de segurança adicional, mas não constitui prova para efeitos de autorização.
Conclusão: Não cumpre o requisito. Os testes de penetração devem ser realizados por uma organização externa acreditada.
Referência: Orientações do FedRAMP relativas aos testes de penetração; controlo CA-8 da norma NIST SP 800-53; acreditação 3PAO pela A2LA.
FISMA
O requisito: a FISMA baseia as suas expectativas em matéria de testes na norma NIST 800-53, aplicada através do Quadro de Gestão de Risco do NIST. O âmbito e o rigor são definidos pela agência e pela categorização do sistema.
Os testes autónomos podem satisfazer esse requisito? Em geral, sim, seguindo a mesma lógica do controlo NIST 800-53, sujeito aos requisitos de avaliação da agência. No caso de sistemas que também procurem obter uma autorização externa ao abrigo de regras relativas a avaliadores acreditados (como o FedRAMP), devem respeitar-se as restrições desse programa.
Conclusão: Sim, mas fica ao critério da agência.
Referência: FISMA através da norma NIST SP 800-53 (CA-8) e da norma NIST SP 800-37 (Quadro de Gestão de Risco).
Normas internacionais
SOC 2
O requisito: a norma SOC 2 não exige explicitamente um teste de penetração, mas os Critérios de Serviços de Confiança da AICPA (o organismo regulador responsável pela norma SOC 2) apontam para tal: o critério de monitorização menciona os testes de penetração como um método de avaliação aceitável, e o critério relativo à deteção de novas vulnerabilidades é apoiado por testes ativos. Na prática, os auditores esperam receber provas de testes de penetração, especialmente no caso de um relatório de Tipo II, dentro do período de auditoria, juntamente com provas das medidas corretivas e dos novos testes.
Os testes autónomos podem satisfazer esse requisito? Sim. Um teste realizado por uma entidade terceira independente constitui uma prova mais sólida do que um teste interno, e a formulação «avaliações contínuas ou separadas» aponta para a realização de testes contínuos.
Conclusão: Sim. Os testes contínuos correspondem diretamente às «avaliações contínuas».
Referência: Critérios de Serviços Fiduciários da AICPA CC4.1 e CC7.1
ISO/IEC 27001
O requisito: Alguns dos controlos do Anexo A da norma ISO 27001 constituem os pontos-chave: um relativo à gestão de vulnerabilidades técnicas, que exige «testes de penetração ou avaliações de vulnerabilidade planeados, documentados e repetíveis, realizados por pessoas competentes e autorizadas»; outro relativo aos testes de segurança nas fases de desenvolvimento e aceitação; e outro relativo ao ciclo de vida do desenvolvimento seguro.
Os testes autónomos podem satisfazer este requisito? Sim. A formulação da norma é praticamente uma descrição dos testes autónomos, e a reprodutibilidade está incorporada na forma como os agentes funcionam. Os auditores aceitam os testes automatizados e contínuos realizados por terceiros como prova neste contexto, e o relatório e a pista de auditoria fornecem a parte «documentada».
Conclusão: Sim. Os testes «repetíveis» encaixam-se na perfeição.
Referência: ISO/IEC 27001:2022, Anexo A; ISO/IEC 27002:2022, controlos 8.8, 8.25 e 8.29.
Regulamentos europeus
Diretiva NIS2
O requisito: A NIS2 exige que as organizações abrangidas pela norma tratem as vulnerabilidades e disponham de políticas para avaliar a eficácia das suas medidas de segurança. O regulamento de execução especifica isto através de gerenciamento de vulnerabilidades e gerenciamento de vulnerabilidades testes de segurança automatizados ou manuais, testes de penetração e análises de vulnerabilidades, realizados regularmente e após alterações significativas.
Os testes autónomos podem satisfazer este requisito? Sim, explicitamente. O regulamento de execução da NIS2 é um dos poucos instrumentos que menciona os testes automatizados e os testes de penetração como métodos aceitáveis. Os testes autónomos contínuos correspondem à formulação «de forma regular e após alterações significativas», e o relatório constitui prova tanto para as obrigações de gestão de vulnerabilidades como para as de avaliação da eficácia.
Conclusão: Sim. Os testes automatizados e de penetração estão expressamente previstos.
Referência: Diretiva NIS2 (UE) 2022/2555, artigo 21.º, n.º 2, alíneas e) e f); Regulamento de Execução (UE) 2024/2690, anexo, pontos 6.10 e 7.1.
GDPR
O requisito: O RGPD exige um processo para testar, analisar e avaliar regularmente a eficácia das suas medidas de segurança técnicas e organizacionais.
Os testes autónomos podem satisfazer esse requisito? Sim. O RGPD não impõe um método específico e dá ênfase à realização de testes regulares; por isso, os testes autónomos contínuos constituem uma demonstração mais sólida de um processo em curso do que um relatório anual em formato PDF. O relatório comprova tanto a realização dos testes como o ciclo de correção.
Conclusão: Sim, favorece os testes contínuos.
Referência: RGPD (Regulamento (UE) 2016/679), artigo 32.º, n.º 1, alínea d).
Lei de Ciber-Resiliência
O requisito: A CRA exige que os produtos com elementos digitais sejam colocados no mercado sem vulnerabilidades exploráveis conhecidas e que, no âmbito da gestão das vulnerabilidades ao longo do ciclo de vida do produto, sejam realizados testes e análises eficazes e regulares da segurança do produto.
Será que os testes autónomos podem satisfazer esses requisitos? Sim. Os testes «eficazes e regulares» são precisamente o que pentest autônomo contínuos e pentest autônomo ao longo de todo o ciclo de vida do produto, e o relatório corrobora tanto a obrigação de realizar testes como o requisito de «ausência de vulnerabilidades exploráveis conhecidas» no momento do lançamento.
Conclusão: Sim, os testes «regulares» favorecem os testes de penetração autónomos.
Referência: Lei de Ciber-Resiliência Regulamento (UE) n.º 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.
