Teste de segurança é a prática de avaliar um sistema — código-fonte, uma aplicação em execução ou a infraestrutura por trás dela — para encontrar as fraquezas que um atacante poderia explorar e para confirmar que seu desenho e sua configuração protegem a disponibilidade, a confidencialidade e a integridade dos dados.
O que faz valer a pena é a distância entre o que um scanner aponta e o que de fato quebra um sistema: no benchmark de ferramentas da Fluid Attacks, um pentester encontrou 743 das 1.201 vulnerabilidades presentes na aplicação avaliada que nenhuma ferramenta automatizada do estudo detectou. Essas 743 concentravam 86,8% da exposição ao risco total daquela aplicação.
Esta página cobre o que são essas avaliações, o que buscam, os tipos e técnicas que existem, as ferramentas envolvidas e como montar um programa que reduza o risco de forma mensurável.
O que são testes de segurança?
O teste de segurança avalia se um sistema se comporta de forma segura sob condições que seus projetistas não previram. Um teste funcional pergunta se um recurso funciona. Uma avaliação de segurança pergunta o que acontece quando alguém o usa mal de propósito: enviando entradas malformadas, pulando uma etapa de um fluxo, reutilizando um token ou encadeando dois comportamentos inofensivos em um resultado perigoso.
O objeto avaliado — o alvo de avaliação, ou ToE — pode ser código-fonte, uma aplicação implantada, uma API, um binário móvel, uma rede ou um ambiente em nuvem. A saída é um conjunto de vulnerabilidades, cada uma com sua severidade, sua localização e evidência suficiente para um desenvolvedor reproduzi-la e corrigi-la.
O teste de segurança não é uma atividade única. Abrange a varredura automatizada, rápida e ampla, e o trabalho manual de hackers éticos, mais lento e mais profundo. A maioria dos programas precisa dos dois, por razões que os números desta página tornam concretos.
Principais objetivos do teste de segurança
Uma boa avaliação cumpre quatro objetivos ao mesmo tempo:
Encontrar fraquezas exploráveis antes que um atacante o faça: nem todo defeito é um risco, e nem todo risco merece a mesma atenção. O ponto é revelar aquelas que um adversário poderia abusar de verdade.
Medir a exposição ao risco, não apenas contar vulnerabilidades: dez problemas de baixa severidade não equivalem a um crítico. A Fluid Attacks usa o CVSSF, uma métrica derivada do CVSS (CVSSF = 4 ^ (CVSS − 4)), de modo que uma vulnerabilidade crítica vale 4.096 unidades enquanto dez menores somam 0,2.
Dar aos times de desenvolvimento algo acionável: um achado sem um caminho reproduzível e sem uma rota de remediação é ruído.
Apoiar a conformidade sem transformá-la no objetivo: padrões como PCI DSS, HIPAA e ISO 27001 exigem teste de segurança, mas passar numa auditoria e ser difícil de atacar são conquistas diferentes.
Por que o teste de segurança é importante?
Porque a exploração de vulnerabilidades já é a via de entrada mais comum. Segundo o Data Breach Investigations Report 2026 da Verizon, "quase um terço (31 %) de todas as violações começa com a exploração de uma vulnerabilidade" — a primeira vez em 19 anos que isso supera as credenciais roubadas como principal ponto de entrada.
O lado do custo está igualmente documentado. A pesquisa anual da IBM sobre o impacto financeiro das violações coloca a violação média na casa dos milhões de dólares, antes de contar sanções regulatórias, perda de clientes e o tempo de engenharia desviado para a resposta a incidentes. Uma vulnerabilidade encontrada durante o desenvolvimento custa uma fração da mesma vulnerabilidade encontrada por um atacante.
Há ainda um efeito cumulativo. Os sistemas mudam o tempo todo, e cada mudança pode introduzir uma fraqueza que não existia no mês passado. Uma única avaliação anual produz uma foto que fica desatualizada em semanas. Realizar testes de segurança continuamente mantém o panorama em dia conforme o código evolui.
Estudo de caso: lições caras sobre o poder do teste de segurança
Em 2023, o time de pesquisa em IA da Microsoft expôs por acidente 38 TB de dados internos — incluindo chaves privadas, senhas e mensagens internas — por meio de um token SAS do Azure com permissões excessivas, publicado junto a um repositório público do GitHub.
A configuração incorreta por trás desse vazamento não foi um zero-day exótico. Foi um erro de permissões que uma revisão da configuração em nuvem teria detectado, e ficou à vista por quase três anos antes de pesquisadores reportarem.
A Marriott International, uma das principais redes hoteleiras, infelizmente foi alvo de duas grandes violações de dados, em 2014 e em 2020, que expuseram as informações pessoais de milhões de hóspedes.
Estudo de caso: violações de dados da Marriott International
Essa é a forma da maioria dos incidentes reais: não um exploit inédito, mas um erro comum que ninguém procurou.
Teste de segurança na Fluid Attacks
O que avaliamos e sob quais regras
A solução de teste de segurança da Fluid Attacks avalia apenas os sistemas que o cliente autorizou explicitamente, dentro de um escopo acordado antes de qualquer trabalho começar. Toda técnica descrita mais adiante nesta página — da análise estática à exploração manual — roda dentro desse acordo, e o que o time encontra no sistema de um cliente permanece confidencial a menos que esse cliente aprove sua publicação.
O trabalho é entregue como uma solução tudo em um com dois planos. O plano Essential roda o lado automatizado: nossos próprios motores de SAST, AI SAST, DAST, SCA, varredura de segredos e CSPM. O plano Advanced acrescenta nossos pentesters, que possuem mais de 60 certificações em segurança ofensiva em web, mobile, nuvem, red teaming e desenvolvimento de exploits, e que executam testes de penetração manuais, revisão de código seguro e engenharia reversa contra o mesmo alvo.
Nosso time de pesquisa trabalha de forma independente da solução. Ele procura vulnerabilidades em software de terceiros que já está em uso em produção, notifica primeiro o fornecedor e publica o resultado como um advisory sob uma política de divulgação que segue as normas ISO/IEC 29147 e ISO/IEC 30111. A Fluid Attacks é CVE Numbering Authority desde 2021 — a primeira da América Latina — e, por isso, atribui os identificadores CVE do que encontra.
A autorização é o que separa o hacking ético de um ataque.
O que nossos próprios números mostram
A razão pela qual insistimos em combinar os dois é que medimos a diferença sobre uma mesma aplicação.
Em nosso benchmark de ferramentas, colocamos 36 ferramentas de terceiros de SAST, DAST e SCA — várias delas no Quadrante Mágico do Gartner — mais nosso próprio scanner e um de nossos pentesters contra o mesmo alvo: 1.201 vulnerabilidades conhecidas em 105 categorias CWE, equivalentes a 461.500 unidades CVSSF, com 73,2 % delas atrás de autenticação.
Avaliador | Verdadeiros positivos | Falsos positivos | Precisão | Abrangência | Abrangência (CVSSF) |
Pentester da Fluid Attacks (manual) | 1.076 | 0 | 100 % | 89,6 % | 98,9 % |
Scanner da Fluid Attacks (automatizado) | 273 | 3 | 99 % | 22,7 % | 8,8 % |
Melhor ferramenta de terceiros do estudo | 260 | 102 | 72 % | 21,6 % | 4,0 % |
Média das outras 34 ferramentas | — | — | — | 1,7 % | — |
Dois achados se destacam. Primeiro, 17 das 36 ferramentas de terceiros não conseguiram identificar nem dez vulnerabilidades das 1.201 presentes. Segundo, 743 vulnerabilidades — 61,9 % do total e 86,8 % da exposição ao risco — foram detectadas exclusivamente pelo pentester.
O padrão se manteve anos depois contra dados novos. Nosso relatório State of Attacks 2026, que cobre as avaliações de 1º de janeiro a 31 de dezembro de 2025, constatou que nossas ferramentas detectaram 55,8 % da exposição ao risco total, enquanto os testes de segurança manuais detectaram, em média, cinco vezes mais exposição ao risco por achado. Os pentesters responderam por 90 % da exposição ao risco vinda de vulnerabilidades de severidade crítica.
De onde vem essa expertise
Benchmarks medem um time sobre uma aplicação. Competições o medem contra todos os outros. No Hack The Box Business CTF de 2025 — o Global Cyber Skills Benchmark, uma competição de quatro dias que abrange hacking web, criptografia, engenharia reversa, nuvem e comprometimento total de redes — nosso time de hacking ficou em #1 na América Latina e #9 no mundo, resolvendo 59 de 66 desafios com 14 jogadores contra os cerca de 30 que cada time do top cinco escalou.
Esse resultado é o fim de uma progressão, não um golpe de sorte. Simon Correa, Head of Research da Fluid Attacks, documentou isso em seu relato de como o time chegou ao top 10:
"Em 2021, a primeira edição da competição, ficamos em #80 no mundo. Em 2024 subimos 45 posições até o #35. E em 2025 saltamos outras 26 posições para terminar em #9 no mundo".
Simon Correa, Head of Research, Fluid Attacks, janeiro de 2026.
As mesmas pessoas executam as avaliações descritas nesta página.
Do achado à correção
Encontrar problemas é apenas metade do trabalho. No conjunto de dados de 2025, a taxa geral de remediação chegou a 62,2 % no fim do ano — 21,2 pontos percentuais acima de 2024 — e os problemas de severidade crítica tiveram a melhor taxa acumulada, com 63,8 %. Os sistemas que usaram nosso CI Gate, que quebra a compilação quando um limite de política é cruzado, alcançaram uma taxa de remediação de 72 % contra 58 % dos que não o usaram, e fecharam os problemas 27 % mais rápido.
As fases descritas adiante nesta página não são teóricas para nós. Cada achado é reportado em nossa plataforma com sua evidência e seu valor CVSSF, mapeado contra nosso próprio catálogo de 384 fraquezas de software, 182 requisitos de segurança e 1.937 guias de remediação. Quando um time acredita ter corrigido algo, solicita um reattack e um de nossos pentesters verifica contra o sistema vivo.
▶️ Vídeo: Michael Rivera, Chief Data & AI Officer da Fluid Attacks, percorre o conjunto completo de dados de 2025 — taxas de remediação, a divisão entre manual e automatizado e o efeito do CI Gate — em nosso webinar do State of Attacks 2026 (36 minutos, em espanhol).
Princípios-chave do teste de segurança
Cinco princípios separam uma avaliação que reduz o risco de uma que produz um documento:
Confidencialidade, integridade e disponibilidade: todo achado deveria ser rastreável até qual dessas três propriedades ele ameaça.
Autenticação e autorização: a maioria dos achados sérios vive atrás de um login. Em nosso benchmark, 73,2 % das vulnerabilidades do alvo exigiam autenticação para serem alcançadas — por isso as varreduras não autenticadas subnotificam de forma sistemática.
Não repúdio: as ações devem ser atribuíveis, e os registros devem sobreviver a um atacante que queira apagá-los.
Menor privilégio: teste se uma conta comprometida de baixo privilégio consegue chegar a dados que não lhe dizem respeito.
Defesa em profundidade: falhar um único controle não deveria encerrar a história.
Tipos de teste de segurança
O tipo é definido pelo que você está testando, não pelo como.
Teste de segurança de aplicações web
Os sistemas web são a superfície mais exposta que a maioria das organizações tem. As avaliações aqui combinam scanners web com trabalho manual contra as categorias do OWASP Top 10: controle de acesso quebrado, injeção, falhas criptográficas e as demais. Falhas de lógica de negócio — um carrinho que aceita quantidades negativas, uma redefinição de senha que revela se uma conta existe — são quase invisíveis para os scanners e rotineiras para um pentester. Veja como você pode proteger suas aplicações web.
Teste de segurança de aplicações móveis
O teste de aplicações móveis inspeciona a aplicação compilada, seu armazenamento local, seu tratamento de certificados e as APIs com as quais conversa. Chaves embutidas no código, bancos de dados locais sem criptografia e certificate pinning desabilitado são os achados recorrentes. Como o binário chega ao dispositivo do próprio atacante, a revisão manual importa aqui mais do que em quase qualquer outro lugar. Veja como você pode proteger suas aplicações móveis.
Teste de segurança de redes
As avaliações de rede mapeiam hosts e serviços expostos, verificam a segmentação e procuram serviços desatualizados e protocolos fracos. A pergunta não é apenas o que é alcançável a partir da internet, mas aonde um atacante consegue chegar depois de pousar num único host interno.
Teste de APIs
As APIs concentram lógica de negócio com muito pouca interface para restringi-la. A autorização quebrada em nível de objeto — trocar um ID numa requisição e obter os dados de outra pessoa — segue sendo o achado sério mais comum. Limitação de taxa, validação de esquemas e tratamento de tokens completam a lista. Veja como você pode proteger suas APIs.
Teste de segurança de infraestrutura em nuvem
As avaliações em nuvem revisam políticas de identidade, permissões de armazenamento, regras de rede e gestão de segredos contra o modelo de responsabilidade compartilhada do provedor. O caso da Microsoft acima é o exemplo canônico do que dá errado aqui.
Outros termos relacionados ao teste de segurança
Esses termos são usados de forma intercambiável. Não são a mesma coisa.
Avaliação de riscos de cibersegurança
Uma avaliação de riscos é um exercício de gestão: identifica ativos, estima a probabilidade e o impacto das ameaças contra eles e define prioridades. Informa onde testar. Não encontra vulnerabilidades.
Auditoria de segurança
Uma auditoria verifica a conformidade contra um padrão ou uma política. Responde "nós cumprimos?" — uma avaliação técnica responde "isso pode ser quebrado?". As duas importam, e passar numa não implica passar na outra.
Avaliação da postura de segurança
Uma avaliação de postura olha para toda a organização: ferramentas, processos, pessoas e as lacunas entre eles. É mais ampla e mais rasa do que uma avaliação técnica de um único sistema.
Varredura de vulnerabilidades
A varredura de vulnerabilidades é a detecção automatizada de problemas conhecidos contra assinaturas e regras. É um componente de uma avaliação de vulnerabilidades e um componente de um teste de segurança completo — não um substituto de nenhum dos dois. A tabela do benchmark acima é a declaração mais clara do que ela cobre e do que não cobre.
Hacking ético
O hacking ético é a simulação autorizada de ataques reais. Um hacker ético trabalha com a mesma mentalidade e boa parte do mesmo instrumental de um adversário, sob um contrato que define o escopo e as regras de engajamento. O pentesting, o red teaming e a engenharia social estão todos dentro dele — e as distinções entre eles nós já abordamos antes neste blog.
Técnicas de teste de segurança
A técnica é definida por como você testa.
SAST: a análise estática lê código-fonte, bytecode ou binários sem executá-los. Detecta padrões inseguros cedo e se integra de forma limpa a um pipeline, ao custo de falsos positivos e de não enxergar o comportamento em tempo de execução. Escolher uma ferramenta SAST é sobretudo uma questão de cobertura de linguagens e de ruído.
DAST: a análise dinâmica ataca a aplicação em execução a partir de fora. Enxerga o que o sistema implantado de fato faz, incluindo problemas de configuração e de integração, mas só alcança o que consegue rastrear.
SCA: a análise de composição de software inventaria dependências de terceiros e sinaliza versões vulneráveis conhecidas. Boas ferramentas de SCA também dizem se o código vulnerável é realmente alcançável a partir da sua aplicação.
CSPM: a gestão da postura de segurança em nuvem verifica continuamente a configuração da nuvem contra linhas de base seguras.
MPT: o teste de penetração manual é um humano atacando o sistema com um objetivo. É de onde saem as falhas de lógica de negócio, os exploits encadeados e as brechas de autorização, e onde se encontra a exposição ao risco que as ferramentas não veem.
SCR: a revisão de código seguro é um humano lendo o código, normalmente guiado pela saída das ferramentas, para julgar o que a ferramenta não conseguiu.
RE: a engenharia reversa de software desmonta artefatos compilados para entender comportamentos que o código-fonte não revela — essencial para aplicações móveis e binários de terceiros.
Ferramentas de teste de segurança
As ferramentas entregam a amplitude. Os scanners da Fluid Attacks cobrem SAST, SCA e DAST, e são recomendados sob o Cloud Application Security Assessment da App Defense Alliance para varredura estática e recomendados pelo CASA para varredura dinâmica. No OWASP Benchmark, nosso motor estático obteve 100 % em verdadeiros positivos e 0 % em falsos positivos.
Se você está avaliando opções de código aberto, o estado de manutenção é o sinal que mais importa — e como fazer benchmark delas corretamente merece um processo próprio. Alguns exemplos, com sua situação no programa OpenSSF Best Practices:
Horusec tem um selo de aprovação nas boas práticas do OpenSSF.
SpotBugs ainda não obteve o selo de aprovação, e um estudo de 2021 mediu quanto do que ela reporta é acionável.
Flawfinder tem um selo de aprovação nas boas práticas do OpenSSF.
Railroader tem um selo de aprovação nas boas práticas do OpenSSF.
O OWASP Zed Attack Proxy é o scanner de vulnerabilidades de aplicações web de código aberto mais usado, e vale checar as listagens de selos equivalentes antes de adotar qualquer uma dessas. Para mobile, o projeto OWASP MASTG as reuniu aqui.
Nada disso substitui o julgamento. O benchmark acima mediu 36 dessas ferramentas contra uma aplicação; 34 delas ficaram numa média de 1,7 % de abrangência.
O impacto dos falsos positivos e dos falsos negativos no teste de segurança
Um falso positivo é um alerta sem nada por trás. Um falso negativo é uma vulnerabilidade real que ninguém reportou. Os dois são caros, de formas diferentes.
Os falsos positivos consomem o recurso mais difícil de recuperar: a confiança dos desenvolvedores. Um time que gasta uma sprint perseguindo achados fantasma passa a ignorar avisos legítimos no futuro. No benchmark, a melhor ferramenta de terceiros produziu 102 falsos positivos contra 260 verdadeiros — uma precisão de 72 % —, enquanto outras seis ferramentas ficaram numa média de cerca de 130 falsos positivos cada. Nosso pentester produziu zero.
Os falsos negativos são piores e mais silenciosos. Ninguém os percebe até que um atacante perceba. É aqui que os 8,8 % de abrangência em CVSSF do melhor motor automatizado viram o número para lembrar: um relatório de varredura limpo não é o mesmo que uma aplicação segura.
Como fazer teste de segurança
Qualquer que seja o escopo, a sequência é a mesma:
Defina o escopo e as regras de engajamento. Quais sistemas, quais ambientes, quais técnicas são permitidas, quem contatar se algo quebrar. Coloque por escrito.
Mapeie a superfície de ataque. Enumere endpoints, serviços, dependências e pontos de entrada. Você não pode testar o que não encontrou.
Rode a análise automatizada. SAST e SCA no pipeline a cada commit, DAST e CSPM contra ambientes implantados de forma programada. Esta é a camada barata e ampla.
Acrescente trabalho manual onde ele rende. Fluxos autenticados, lógica de negócio, limites de autorização, tudo o que envolve dinheiro ou dados pessoais. Esta é a camada que encontra os problemas críticos.
Priorize por risco, não por contagem. Use uma métrica de severidade que reflita o impacto real e corrija primeiro o topo da lista.
Corrija e verifique. Um achado não está fechado até que alguém tenha confirmado a correção contra o sistema vivo.
Repita conforme o sistema muda. Idealmente a cada commit, não uma vez por ano.
Embutir o teste de segurança em uma metodologia DevSecOps é o que o transforma de um projeto em uma prática, e quais técnicas usar em cada etapa é a decisão que determina se funciona.
O Secure Software Development Framework do NIST (SP 800-218, versão 1.1, publicado em fevereiro de 2022) formaliza a mesma ideia: revisar o código legível por humanos e testar o código executável são práticas distintas e ambas obrigatórias — não alternativas.
Conclusões
O teste de segurança é como uma organização descobre o que um atacante descobriria, nos seus próprios termos e no seu próprio calendário. A evidência é consistente sobre o que isso exige. O DBIR 2026 da Verizon coloca a exploração de vulnerabilidades em 31 % das violações, à frente das credenciais roubadas pela primeira vez em 19 anos. Nosso próprio benchmark encontrou 61,9 % das vulnerabilidades de uma aplicação — e 86,8 % da sua exposição ao risco — apenas por meio de trabalho manual. Nossos dados de 2025 apontaram os pentesters como responsáveis por 90 % da exposição ao risco das vulnerabilidades críticas.
A automação não é opcional: nada mais dá cobertura a cada commit. Mas um programa construído só sobre varredura está medindo a parte do problema que é fácil de medir. Combine os dois, rode-os continuamente e verifique as correções.
Perguntas frequentes
Qual é a diferença entre teste de segurança e auditoria de segurança?
O teste de segurança procura vulnerabilidades exploráveis em um sistema. Uma auditoria verifica se a organização cumpre um padrão ou uma política — seus processos, sua documentação e seus controles. Uma organização pode passar numa auditoria e continuar trivialmente explorável.
Com que frequência o teste de segurança deve ser feito?
De forma contínua, integrado ao pipeline de CI/CD, em vez de uma vez por ano antes de uma auditoria. Os sistemas mudam a cada commit, e uma avaliação pontual fica desatualizada em semanas. Em nossos dados de 2025, os times que usaram nosso CI Gate alcançaram uma taxa de remediação de 72 % contra 58 % dos times que não o usaram.
O teste de segurança automatizado é suficiente sozinho?
Não. No benchmark da Fluid Attacks com 36 ferramentas de terceiros contra uma aplicação com 1.201 vulnerabilidades conhecidas, o melhor motor automatizado alcançou 22,7 % de abrangência e cobriu 8,8 % da exposição ao risco, enquanto um pentester alcançou 89,6 % de abrangência e 98,9 % da exposição ao risco. A automação dá amplitude; os testadores humanos encontram os problemas críticos.
A Fluid Attacks usa ferramentas automatizadas, testes manuais ou os dois?
Os dois, sobre o mesmo alvo. Nosso plano Essential roda nossos motores de AI SAST, SAST, SCA, DAST, varredura de segredos e CSPM. Nosso plano Advanced acrescenta pentesters executando testes de penetração manuais, revisão de código seguro e engenharia reversa, e permite aos times solicitar reattacks para verificar se uma correção realmente funcionou.
Qual tipo de teste de segurança encontra mais vulnerabilidades críticas?
Os manuais. Em nosso relatório State of Attacks 2026, que cobre todas as avaliações executadas em 2025, os pentesters responderam por 90 % da exposição ao risco vinda de vulnerabilidades de severidade crítica, e o trabalho manual detectou em média cinco vezes mais exposição ao risco por achado do que nossas ferramentas automatizadas.
Quanto custa um teste de segurança?
Depende do escopo — uma aplicação contra um parque inteiro —, de quais técnicas estão incluídas e de se é um trabalho pontual ou um programa contínuo. Programas contínuos custam mais por ano e encontram muito mais, porque testam o sistema conforme ele muda em vez de uma única vez.
Veja o que seu scanner não enxerga
No nosso benchmark, o melhor scanner encontrou 22,7 % das vulnerabilidades e nossos pentesters, 89,6 %. Teste com os dois. Teste gratuito · Fale conosco.
