O Pentesting como Serviço (PTaaS) é um modelo de entrega para os testes de penetração. Em vez de um trabalho pontual que termina em um relatório estático, os pentesters avaliam o sistema de forma recorrente e publicam cada achado em uma plataforma onde os desenvolvedores e a equipe de segurança do cliente o acompanham, discutem e fecham. O PTaaS combina esse trabalho manual com a varredura automatizada e mantém o escopo dos testes aberto às mudanças do sistema.
O modelo importa pelo que a intervenção humana acrescenta. Nas avaliações de sistemas de clientes da Fluid Attacks entre 1º de janeiro e 31 de dezembro de 2025, as ferramentas automatizadas reportaram 55,8 % da exposição ao risco e os pentesters, os 44,2 % restantes, mas nas vulnerabilidades de severidade crítica 87 % vieram da revisão manual.
Esta página cobre o que o Penetration Testing as a Service - PTaaS inclui e o que não inclui, como se compara com um pentest tradicional e com um programa de recompensas, o que um achado de PTaaS precisa conter para servir de algo, e as perguntas que revelam se os testes “contínuos” de um fornecedor são contínuos na prática.
O que é Pentesting as a Service (PTaaS)?
O PTaaS é um serviço no qual pentesters éticos encontram vulnerabilidades em um sistema, tentam explorá-las e reportam os resultados de forma contínua, por uma plataforma e não por um documento. O quadro de comparação da Fluid Attacks o define nesses mesmos termos: a solução ou o serviço inclui testes de penetração contínuos, com avaliadores que encontram vulnerabilidades, tentam explorá-las e reportam o que acham.
O modelo tem três componentes:
Testes humanos recorrentes: a equipe de avaliação trabalha sobre o sistema ao longo do tempo, não em uma única janela. As novas versões e os ativos descobertos depois entram no escopo.
Uma plataforma: achados, evidências, status, orientações de remediação e a conversa entre avaliadores e desenvolvedores ficam em um só lugar, disponíveis enquanto a avaliação ainda está em curso.
Automação por baixo: os scanners cobrem falhas conhecidas, superfícies amplas e velocidade; a equipe humana cuida de todo o resto.
Convém ser preciso sobre o que o PTaaS não é. Não é um scanner de vulnerabilidades com um painel: se nenhum humano testa o sistema, o serviço é varredura de vulnerabilidades, não importa como a interface pareça. Também não é um pentest tradicional subido a um portal web: passar o entregável de um PDF para um navegador muda o formato, não a frequência. E não é um programa de recompensas por falhas, porque o escopo, os avaliadores e as regras são acordados de antemão.
A técnica dentro do modelo é o pentesting manual. O PTaaS não muda como um pentester trabalha. Muda a frequência desse trabalho, a rapidez com que o resultado chega ao desenvolvedor e quem verifica a correção.
Por que o modelo de entrega muda o resultado
Um modelo de entrega decide quando uma vulnerabilidade é encontrada, quanto tempo ela fica aberta e quem confirma que ela sumiu. Essas três coisas, e não a técnica de teste, são o que separa o PTaaS de um trabalho anual.
A janela entre testes é onde mora o risco
Um software que entra em produção toda semana e é testado uma vez por ano passa a maior parte da vida sem avaliação. Cada entrega entre duas avaliações é código que ninguém olhou do ponto de vista de um atacante. A análise da Fluid Attacks sobre testes contínuos frente aos pontuais coloca o mesmo argumento: um teste pontual descreve a postura de segurança do dia em que foi feito. O PTaaS fecha essa janela ao testar à medida que o sistema muda.
Os achados chegam enquanto o código ainda está fresco
Em um trabalho por projeto, cada vulnerabilidade — a da primeira semana e a da sexta — chega ao mesmo tempo, no mesmo documento. Com PTaaS, cada achado é publicado quando o avaliador o confirma, então quem escreveu o código ainda é quem o corrige.
A plataforma é onde a remediação acontece
Um relatório descreve vulnerabilidades. Uma plataforma de PTaaS as transforma em gestão de vulnerabilidades: prioridade, atribuição, status, evidência, a troca com quem encontrou o problema e o registro de cada reteste. A métrica que importa não é a rapidez com que o fornecedor detecta uma falha, mas quanto tempo essa falha continua explorável.
A automação sozinha não chega lá. Segundo a documentação da Fluid Attacks, a varredura automatizada encontra apenas entre 10 % e 30 % da exposição ao risco total de um sistema; o resto precisa de testes manuais, muitas vezes porque reproduzir o problema exige um ambiente, autenticação ou dados de teste. Uma oferta de PTaaS sem essa camada humana vende a plataforma, não os testes.
Resultados de 2025 da Fluid Attacks: as ferramentas reportaram mais vulnerabilidades, os pentesters reportaram a maioria das críticas.
PTaaS na Fluid Attacks
A Fluid Attacks entrega o Pentesting as a Service no plano Advanced de sua solução integral. O que segue é o que o serviço faz, com suas regras e seus limites.
O que testamos e sob quais regras
O PTaaS cobre todas as superfícies de ataque que o DAST automatizado cobre — registros DNS, cabeçalhos, conteúdo HTML, conexões SSL, endpoints HTTP não autenticados, webhooks e WebSockets — e soma as superfícies que exigem um humano: endpoints HTTP autenticados, APIs GraphQL, gRPC, REST e SOAP, e APIs descritas com especificações OpenAPI, Postman ou Swagger. Os avaliadores se autenticam nas aplicações e seguem essas especificações, com acesso ao código-fonte, uma abordagem que a Fluid Attacks chama de pentesting assistido por código. Um limite documentado: nem o DAST nem o PTaaS suportam as DOM APIs.
Os testes rodam sob regras explícitas, também em produção. A Fluid Attacks controla a intensidade e o ritmo de cada teste e não usa técnicas de força bruta ou de alta carga sem autorização. Todo teste que possa afetar a disponibilidade roda primeiro em um ambiente diferente do de produção, e o cliente é avisado e consultado sobre um horário adequado. Os testes sempre partem de endereços IP da própria Fluid Attacks, para que um alerta falso em um WAF ou em um SOC possa ser rastreado. Se um avaliador tem qualquer dúvida durante um teste, ele para.
Como isso funciona na prática
O que é instrumentado | Como é testado | O que o cliente recebe |
|---|---|---|
Código-fonte dos branches registrados | Avaliadores com acesso ao código, mais SAST, SCA e varredura de segredos | O commit onde a vulnerabilidade mora |
Ambientes web e de API | PTaaS sobre endpoints autenticados e especificações de API, mais DAST | O ambiente avaliado e a marca de tempo da revisão |
Binários móveis | Testes manuais mais MAST | A versão do binário carregado |
Infraestrutura em nuvem | CSPM e revisão manual | O estado ao vivo lido pela API |
Cada vulnerabilidade reportada | Exploração por um pentester | Até seis imagens ou vídeos como evidência, atualizados a cada reataque |
Cada correção | Um reataque solicitado pela plataforma | Confirmação ou reabertura, com o histórico completo |
Qual sistema é testado em seguida não é decidido por um calendário. Modelos estatísticos ordenam os sistemas por risco — número e tamanho das mudanças recentes, quais arquivos mudaram mais, quantos autores os tocaram, o histórico de vulnerabilidades do sistema — e cinco equipes de ataque independentes trabalham a partir dessa ordem: Systems, Criticals, Escapers, Deterministic e Reattack. Mais de uma pode testar o mesmo sistema ao mesmo tempo.
Os achados chegam aos desenvolvedores onde eles já trabalham, por integrações com IDEs, sistemas de rastreamento de bugs e o pipeline de CI/CD. Dentro do pipeline de CI/CD, o CI Gate aplica as políticas da organização e bloqueia uma entrega que as descumpra.
Com o que o serviço se compromete
O acordo de nível de serviço da Fluid Attacks declara três números contra os quais ela pode ser medida:
Disponibilidade: a plataforma e a API ficam acessíveis pelo menos 99,95 % do tempo.
Resposta: uma primeira resposta com mediana menor que 8 horas úteis para 90 % das solicitações de reataque, comentários, eventos e incidentes.
Precisão: uma pontuação F2 de pelo menos 90 % nos relatórios de exposição ao risco e uma F0.5 de pelo menos 90 % nos relatórios de vulnerabilidades.
As três são medidas a cada trimestre sobre todos os grupos da organização, inclusive os excluídos. O indicador de precisão é o incomum: a F2 pesa mais os falsos negativos — as vulnerabilidades que o fornecedor não viu — do que os falsos positivos, o contrário do que escolheria um fornecedor cujo objetivo fosse parecer bem.
O que “contínuo” não significa
Contínuo não significa que um pentester revise cada commit, e nenhum fornecedor deveria deixar um comprador acreditar nisso. A Fluid Attacks diz de forma explícita que não promete cobertura: um método pode testar todos os arquivos e ainda assim deixar passar uma vulnerabilidade crítica. As técnicas automatizadas varrem 100 % dos arquivos aplicáveis nas linguagens suportadas quando as integrações de CLI estão ativas, mas os testes manuais partem de uma priorização estatística do risco, e o compromisso é com um resultado — o SLA de precisão de 90 % — e não com um percentual de arquivos revisados.
Essa distinção vale a pena levar a qualquer avaliação de PTaaS. Disponibilidade contínua da plataforma, avaliações manuais recorrentes, varredura automatizada programada e testes humanos contínuos são quatro coisas diferentes, e um fornecedor que usa uma só palavra para as quatro descreve um folheto, não um serviço.
O reataque decide todo o resto
Uma correção que nunca foi atacada de novo é uma suposição. Na plataforma da Fluid Attacks, uma vulnerabilidade reportada por um pentester não fecha porque um desenvolvedor mudou o código: para os achados de PTaaS, Secure Code Review, Reverse Engineering e AI SAST, o cliente solicita um reataque e um pentester tenta a exploração outra vez. Se o problema continua lá, o achado continua aberto. Os reataques são ilimitados no plano Advanced, e a vulnerabilidade mantém o histórico completo de reataques solicitados e verificados, inclusive os rejeitados.
Mais a fundo: a análise da Fluid Attacks sobre o pentesting contínuo explica como o escopo dos testes se adapta quando surgem novos ativos.
PTaaS, pentesting tradicional e recompensas por falhas não são alternativas
O PTaaS, um trabalho tradicional e um programa de recompensas respondem a perguntas diferentes, e a comparação de que o comprador precisa é sobre escopo, cadência e controle.
PTaaS | Pentesting tradicional | Recompensas por falhas | |
|---|---|---|---|
Cadência | Recorrente, segue as mudanças do sistema | Um trabalho, normalmente anual ou semestral | Aberta, depende do interesse dos pesquisadores |
Quem testa | Uma equipe conhecida, sob contrato | Uma equipe designada para aquele trabalho | Qualquer pessoa registrada no programa |
Como os achados chegam | Publicados à medida que são confirmados | Em um relatório final | Como relatos, quando acontecem |
Escopo | Acordado e ajustável | Acordado e fixo | Definido pelo programa, muitas vezes estreito |
Reteste | Solicitado pela plataforma, feito por um pentester | Um trabalho à parte, normalmente faturável | Não garantido |
Pagamento | Assinatura | Por trabalho | Por achado aceito |
Para que serve melhor | Software que muda continuamente | Uma avaliação pontual com uma data específica | Cobertura ampla e oportunista sobre um programa |
Um programa de recompensas premia quem encontra algo primeiro, o que produz achados reais mas nenhuma garantia de que alguém olhou as partes da aplicação que mais preocupam. Um pentest tradicional revisa um escopo acordado em uma data acordada. O PTaaS repete essa revisão, com a mesma equipe mantendo o contexto entre ciclos.
Nenhum dos três, PTaaS incluído, substitui a varredura automatizada, e a varredura automatizada não substitui nenhum deles. No benchmark da Fluid Attacks de 36 ferramentas de AppSec de terceiros contra uma aplicação semeada com 1.201 vulnerabilidades, um pentester reportou 1.076 delas — um recall de 89,6 % com precisão de 100 % — enquanto o scanner de melhor desempenho daquele teste, o da própria Fluid Attacks, chegou a um recall de 22,7 %.
O que um achado de PTaaS precisa conter
Um achado de PTaaS serve quando um desenvolvedor consegue reproduzi-lo, entender seu impacto e verificar a correção sem voltar a perguntar ao fornecedor. Menos que isso é um alerta.
A fraqueza, classificada: não texto livre, mas uma entrada de um catálogo documentado com sua descrição, impacto, ator de ameaça e orientação de remediação. A Fluid Attacks associa cada achado a uma entrada de seu catálogo público de fraquezas, como as falhas de lógica de negócio, o exemplo mais claro do que as ferramentas não veem e um avaliador vê.
A localização: o commit para o código-fonte, a versão do binário para mobile, o ambiente avaliado e a marca de tempo para web, APIs e nuvem. Um achado de PTaaS sem isso não é acionável.
Prova de exploração: a evidência que o pentester anexa para mostrar que o problema é real, como imagens ou vídeos, até seis arquivos por achado, atualizados a cada reataque e guardados junto ao achado de PTaaS.
Severidade em contexto: uma pontuação com a qual a equipe possa priorizar, informada pela explorabilidade e ajustada quando o sistema não tem as condições que tornariam explorável uma falha conhecida.
Orientação de remediação: passos sobre os quais o desenvolvedor possa agir, mais acesso ao avaliador. O plano Advanced da Fluid Attacks inclui sessões de Talk to a Pentester.
Status e histórico: estado atual, data do relato e cada reataque solicitado e verificado.
O relatório de PTaaS também deveria produzir um resumo executivo e uma exportação técnica.
Cada achado de PTaaS se associa a uma entrada de catálogo como esta, com impacto, ameaça e correção.
Como avaliar um fornecedor de PTaaS
O marketing de PTaaS usa quase sempre os mesmos adjetivos. Estas dez perguntas separam os fornecedores, porque cada uma tem uma resposta verificável.
Critério | A pergunta que é preciso fazer |
|---|---|
Testes humanos | Há avaliadores humanos testando o sistema e qual percentual dos achados vem deles? |
Consistência da equipe | Os avaliadores são empregados com contrato direto e continuam na minha conta entre ciclos? |
Experiência | Quantas certificações de segurança ofensiva a equipe tem e vocês conseguem nomeá-las? |
Cadência | O que dispara uma nova avaliação manual: um calendário, uma entrega, um modelo de risco? |
Superfície de ataque | Vocês testam endpoints autenticados e especificações de API, e o que não suportam? |
Evidência | Cada achado inclui uma prova de exploração que eu possa reproduzir? |
Exploração encadeada | Seus avaliadores combinam vulnerabilidades para mostrar o impacto real ou as reportam uma a uma? |
Reteste | Quem verifica uma correção, quantos retestes estão incluídos e em quanto tempo começam? |
Compromisso de precisão | Existe um número de precisão contratual, como ele é medido e pesa os falsos negativos? |
Segurança operacional | Quem controla o canal entre o avaliador e o meu sistema, e sob qual acordo? |
Dois desses critérios de PTaaS merecem ênfase. A exploração encadeada transforma uma lista de problemas de severidade média em um caminho demonstrado até o impacto, e é onde a automação ainda fica para trás: uma revisão de pesquisa publicada feita pela Fluid Attacks sobre agentes de pentesting baseados em LLM achou que 83,3 % das amostras de exploração encadeada pararam antes de completar uma cadeia de várias vulnerabilidades, e cerca de 56,7 % das amostras de exploração de CVE identificaram o CVE certo mas não conseguiram construir um payload funcional.
A experiência é o outro. A exploração avançada é trabalho de pesquisa, não de ferramenta. Como disse Andrés Roldán, VP of Hacking da Fluid Attacks, em sua resenha da certificação OffSec Exploitation Expert, “new research is needed to develop an exploit for a modern Windows OS build”. Os pentesters da Fluid Attacks têm certificações internacionais em múltiplas técnicas de testes de segurança, e a CREST acreditou a empresa para testes de penetração.
O catálogo SP 800-53 Rev. 5 do NIST (2020) lista os testes de penetração como um controle próprio, CA-8, com melhorias para uma equipe de testes independente e exercícios de red team. O PCI Security Standards Council torna os testes de penetração obrigatórios no requisito 11.4 do PCI DSS, e o 11.4.1 exige que a entidade defina, documente e implemente a metodologia e que guarde os resultados por pelo menos 12 meses. Vale dizer com clareza: o PTaaS pode produzir a evidência que esses marcos pedem, e o mesmo vale para os programas de GDPR e HIPAA, mas contratar PTaaS não torna uma organização conforme.
Conclusões
O PTaaS é um modelo de entrega, não uma técnica de teste, e é aí que está seu valor. Ele coloca avaliadores humanos sobre o sistema de forma repetida em vez de uma vez por ano, publica cada achado quando ele é confirmado em vez de em um documento trimestral, e verifica as correções com um reteste em vez de com uma suposição. As partes de uma oferta de PTaaS que vale a pena revisar são as operacionais: quem testa, com que frequência, com qual evidência, sob qual compromisso de precisão e quem confirma a correção.
Os dados sustentam colocar humanos no ciclo do PTaaS. A varredura automatizada cobre apenas entre 10 % e 30 % do que existe, e nos resultados de 2025 da Fluid Attacks 87 % das vulnerabilidades de severidade crítica vieram da revisão manual. Um serviço de PTaaS que não consegue explicar seu componente humano é um scanner com uma interface melhor.
Perguntas frequentes
O PTaaS é realmente pentesting contínuo?
Depende do fornecedor, e a palavra esconde quatro coisas diferentes. Disponibilidade contínua da plataforma, avaliações manuais recorrentes, varredura automatizada programada e testes humanos contínuos não são a mesma coisa. Pergunte o que dispara uma nova avaliação manual, se as novas versões e os ativos descobertos depois entram no escopo, e como os achados chegam até você entre ciclos.
Qual é a diferença entre PTaaS e um programa de recompensas por falhas?
O PTaaS é um serviço contratado com escopo acordado e equipe conhecida; um programa de recompensas é um convite aberto pago por achado aceito. Um programa de recompensas dá cobertura oportunista sem garantia de que alguém revisou o que mais preocupa você. O modelo de serviço dá uma revisão metódica e repetida de um escopo que você define, com retestes incluídos.
O PTaaS inclui pentesting manual ou apenas varredura automatizada?
Os testes manuais são o que o torna PTaaS. Se nenhum humano testa o sistema, o serviço é varredura de vulnerabilidades entregue por uma plataforma. A varredura automatizada encontra apenas entre 10 % e 30 % da exposição ao risco total de um sistema, segundo a documentação da Fluid Attacks, porque o resto precisa de um ambiente, autenticação, dados de teste ou do entendimento do que a aplicação deveria fazer.
O PTaaS satisfaz os requisitos de pentesting do PCI DSS?
Ele pode fornecer os testes e a evidência, mas sozinho não torna você conforme. O requisito 11.4 do PCI DSS torna os testes de penetração obrigatórios, e o 11.4.1 exige que a entidade defina, documente e implemente a metodologia e guarde os resultados por pelo menos 12 meses. Um fornecedor de PTaaS deveria mostrar como sua metodologia, seu escopo e seus relatórios correspondem a essas condições.
A Fluid Attacks garante a precisão de seus achados de PTaaS?
Sim, contratualmente. O acordo de nível de serviço do plano Advanced traz um compromisso de precisão de 90 %, medido com uma pontuação F2 de pelo menos 90 % nos relatórios de exposição ao risco e uma F0.5 de pelo menos 90 % nos relatórios de vulnerabilidades, junto com 99,95 % de disponibilidade da plataforma e uma primeira resposta mediana menor que 8 horas úteis para 90 % das solicitações de reataque. Os três indicadores são medidos a cada trimestre.
Teste seu software no ritmo em que você o entrega
Nossos pentesters de PTaaS e nossos scanners avaliam seus sistemas à medida que eles mudam, e cada correção que você entrega recebe um reataque até que a vulnerabilidade realmente desapareça. Teste gratuito · Fale conosco.
Comece agora com o PTaaS da Fluid Attacks
