No Vuln — empresa brasileira de pentest e auditoria de segurança ofensiva
Voltar ao blog

Black Box vs Grey Box vs White Box: qual pentest contratar em 2026?

Diferença entre Black Box, Grey Box e White Box em pentest. Quando contratar cada modalidade, cobertura típica, preço relativo e como decidir em 2026.

Guia·24 de maio de 2026·13 min de leitura
Diego Melo — autor
Diego Melo

Pesquisador de segurança e fundador da No Vuln

Black Box vs Grey Box vs White Box: qual pentest contratar em 2026?

Black Box, Grey Box e White Box são as três modalidades de pentest baseadas em quanto acesso e conhecimento o pesquisador recebe sobre o sistema antes de começar o trabalho. Black Box parte do zero (como atacante externo real); Grey Box recebe credenciais e documentação básica; White Box recebe acesso completo (código, banco, infraestrutura).

A escolha entre as três impacta diretamente cobertura, profundidade técnica, tempo de execução e preço. Este guia explica cada modalidade em profundidade, compara dimensão por dimensão, e mostra exatamente quando contratar cada uma — com recomendações específicas por porte de empresa e setor (SaaS B2B, fintech, e-commerce, healthtech).

Resumo executivo — comparação rápida

DimensãoBlack BoxGrey BoxWhite Box
Conhecimento prévioZeroCredenciais + docs básicasCódigo, DB, infra
SimulaAtacante externoInsider malicioso ou clienteAuditor + atacante
Cobertura típica30–50%60–75%85–95%
Tempo em recon40–60% do projeto5–10%Quase zero
Custo relativoR$ R$R$ R$R$ R$ R$
Uso típico no mercado~25%~60%~15%

Black Box — Caixa Preta

O que é

Em Black Box, o pesquisador não recebe absolutamente nada. Começa do zero, como atacante externo real começaria: com apenas o nome do domínio, IP ou URL público. Sem credenciais, sem documentação, sem acesso à infra, sem código.

Como funciona na prática

  • Pesquisador faz recon completo: descoberta de subdomínios, mapeamento de endpoints públicos, análise de bundles JavaScript expostos, fingerprinting de tecnologias, OSINT
  • Tenta criar conta como usuário comum (se a aplicação permite registro público)
  • Ataca apenas o que está exposto publicamente
  • Procura misconfigurations expostas (buckets S3 públicos, CORS permissivo, headers ausentes, endpoints v1/v2/staging esquecidos)

O que Black Box encontra bem

  • Vulnerabilidades acessíveis externamente
  • Misconfigurations de infraestrutura expostas
  • Falhas em autenticação, registro e recuperação de senha
  • Ataques pré-autenticação (SSRF em endpoints públicos, NoSQL injection em login)
  • Vazamento de informação em respostas (stack traces, debug headers)

O que Black Box NÃO encontra bem

  • Bugs internos da aplicação (post-login profundo)
  • Lógica de negócio de áreas privadas
  • Falhas em fluxos administrativos
  • Bugs em APIs internas não descobertas no recon
  • BOLA cross-tenant (precisa de 2+ contas em tenants diferentes)
  • Race conditions internas

Quando contratar Black Box

  • Simulação fiel de atacante externo— quando cliente quer ver exatamente “como atacante nos vê de fora”
  • Primeiro pentest em novo fornecedor — confiança ainda não existe, e black box deixa transparente o que o fornecedor é capaz de descobrir sozinho
  • Validação de superfície de ataque — verificar o que está exposto inadvertidamente
  • Compliance com requisito específico— alguns frameworks regulatórios exigem teste “sem assistência”

Grey Box — Caixa Cinza ⭐ Modalidade mais comum

O que é

Em Grey Box, o pesquisador recebe credenciais válidas de diferentes papéis (por exemplo: 1 admin, 1 usuário comum, 1 viewer) e documentação básica do sistema — normalmente Swagger/Postman da API, lista de URLs principais e diagramas de alto nível. Sem acesso ao código-fonte.

Como funciona na prática

  • Pesquisador entra logado em múltiplas contas em paralelo
  • Mapeia fluxos pós-autenticação rapidamente (sem perder tempo em recon)
  • Testa cross-tenant — cliente A acessando dados do cliente B — só possível com 2+ contas
  • Testa escalação de privilégio — viewer virando admin
  • Cobre OWASP API Top 10 completo
  • Avalia business logic abuse em fluxos legítimos (manipulação de preço, race em cupom, bypass de antifraude)

O que Grey Box encontra muito bem

  • BOLA cross-tenant (vazamento entre clientes) — bug #1 do OWASP API Top 10 e o mais devastador em SaaS B2B
  • BFLA (acesso a endpoint admin como user comum)
  • BOPLA / mass assignment (alterar campos privados via PATCH)
  • Business logic abuse (manipulação de preço, race em cupom, double refund)
  • OAuth ATO em fluxos pós-login (state confusion, scope escalation — veja OAuth Account Takeover em SaaS B2B)
  • Race conditions em endpoints financeiros (veja Race condition em PIX)

O que Grey Box NÃO encontra tão bem

  • Bugs em camadas profundas de código (race conditions internas em queries)
  • Misconfigurations de infra interna (IAM permissivo, network policies)
  • Secrets hardcoded em código ou histórico do Git
  • Vulns em dependências (CVEs específicos em libraries)
  • Falhas de design arquitetural

Quando contratar Grey Box

  • Default para a maioria dos pentests de SaaS B2B e fintech moderna — melhor relação custo-benefício
  • Renovação anual de pentest — modalidade padrão pra cobertura regular
  • Pentest sprint-aligned (PTaaS) — em modelos recorrentes, grey box é o padrão
  • Preparação para SOC 2 / ISO 27001 — atende auditor sem inflar custo
  • Quando o tempo é limitado — pula recon, vai direto onde dá retorno

White Box — Caixa Branca

O que é

Em White Box, o pesquisador recebe acesso TOTAL ao sistema: tudo do Grey Box mais código-fonte completo (repositório Git), acesso ao banco de dados (esquema + dados), acesso à infraestrutura (AWS console, Kubernetes, logs), documentação arquitetural completa e disponibilidade de conversa com o time de engenharia (threat modeling colaborativo).

Como funciona na prática

  • Pesquisador combina análise de código (estática) com exploração ativa (dinâmica)
  • Mapeia fluxos críticos pelo código antes de atacar
  • Identifica vulns “invisíveis” externamente (race conditions em queries internas, dead code que vira backdoor, secrets em commits antigos)
  • Faz review de arquitetura e identifica problemas de design (não só de implementação)
  • Pode rodar ferramentas estáticas (SAST) e validar manualmente os achados
  • Analisa misconfigurations cloud em profundidade (IAM, S3 policies, network ACLs)

O que White Box encontra excepcionalmente bem

  • Race conditions complexas
  • Deserialization vulnerabilities
  • SQL injection em queries internas
  • Secrets vazados em código ou histórico Git (chaves API, credenciais hardcoded, tokens OAuth)
  • Vulns em dependências (CVEs específicos)
  • Falhas de design (não só de implementação)
  • Backdoors acidentais deixados por dev
  • Misconfigurations cloud profundas (IAM permissivo, bucket policy)
  • Verificação de propriedades criptográficas (key management, rotação)

O que White Box NÃO faz sentido

  • Recon (já tem todas as informações)
  • Simular “atacante externo cego” (perde o ponto — para isso use Black Box)

Quando contratar White Box

  • Pré-launch de feature crítica — produto financeiro, fluxo de pagamento, integração regulada
  • Preparação para SOC 2 Type II ou ISO 27001 — auditor pede whitebox para validação de controles técnicos
  • Diagnóstico inicial profundo em empresa que nunca fez pentest sério
  • Due diligence técnicaem M&A
  • Threat modeling pré-arquitetural de sistema crítico antes do go-live
  • Setores regulados (fintech Bacen, healthtech LGPD Art. 11) — auditoria de profundidade

Comparativo detalhado — dimensão por dimensão

DimensãoBlack BoxGrey BoxWhite Box
Conhecimento prévioZeroCredenciais + docsTudo (código, DB, infra)
SimulaAtacante externoInsider ou clienteAuditor interno + atacante
Cobertura típica30–50%60–75%85–95%
Tempo em reconMuito (40–60%)Pouco (5–10%)Quase zero
Tempo em exploraçãoMédioAltoMuito alto
Custo relativo$$$$$$$
Encontra bugs externos✅✅✅✅✅
BOLA cross-tenant✅✅✅✅✅✅
Race conditions internas⚠️✅✅✅
Secrets em código/Git✅✅✅
Problemas de design⚠️✅✅✅
Misconfig cloud profunda⚠️⚠️✅✅✅
Bom para LGPD⚠️✅✅✅
Bom para SOC 2 Type II⚠️✅✅✅
Bom para Bacen 4.893✅✅✅✅✅

Como o mercado realmente usa em 2026

Distribuição típica de modalidades em pentests brasileiros em 2026:

  • ~60% Grey Box — melhor ROI para cliente médio (SaaS B2B, fintech early-stage, e-commerce, marketplace)
  • ~25% Black Box — quando cliente quer simulação fiel ou é primeiro pentest e ainda não confia no fornecedor
  • ~15% White Box — quando há regulação pesada (Bacen Resolução 4.893, PCI-DSS 4.0, SOC 2 Type II) ou cliente já é maduro em segurança

Decision tree — qual escolher pelo seu cenário

Para SaaS B2B (R$ 50k–R$ 500k MRR)

Grey Box é default. Cobertura completa de multi-tenant, OAuth, BOLA e business logic sem inflar custo. Veja Pentest para SaaS.

Para fintech early-stage

Grey Box para anual + módulo de White Box nos fluxos financeiros críticos (PIX, conciliação, antifraude). Conforme matura, evoluir para White Box completo. Veja Pentest para Fintech.

Para banco digital / fintech enterprise

White Box obrigatório em qualquer engagement formal. Bacen Res. 4.893 e BCB 85 esperam essa profundidade. Veja Pentest para Meios de Pagamento.

Para e-commerce / marketplace

Grey Box default. Black Box útil para validar exposição externa de feature nova. Veja Pentest para E-commerce e Pentest para Marketplace.

Para healthtech / clínica digital

Grey Box + módulo White Box nos fluxos de prontuário e prescrição (LGPD Art. 11 — dado sensível). Veja Pentest para Healthtech.

Para preparação SOC 2 Type II ou ISO 27001

White Box obrigatório. Auditor pede evidência de teste com cobertura máxima.

Para startup early-stage (pré-MRR / MVP)

Black Box como primeiro pentest. Valida superfície externa com orçamento limitado. Conforme crescer, evoluir para Grey Box anual.

Modelo híbrido — o que toda fintech séria está fazendo

Na prática, fintech madura em 2026 não escolhe um único modelo. Combina:

  • 1 White Box anual — deep dive completo, cobertura máxima, alimenta dossiê regulatório
  • 2–4 Grey Box trimestrais — cobertura ágil de features novas
  • Pentest sprint-aligned (PTaaS) com Grey Box — recorrente mensal, cada feature passa por validação adversarial antes de ir para produção
  • Black Box pontual quando uma feature de exposição externa lança (novo SDK público, nova integração com terceiros)

O que considerar ao decidir

1. Maturidade de segurança atual

Sem nenhum pentest prévio = começar com Grey Box ou White Box para ter baseline real. Black Box em organização imatura subestima exposição.

2. Regulação aplicável

Setores regulados (Bacen, PCI-DSS, SOC 2, ISO 27001) esperam progressivamente mais profundidade. White Box destrava certificações.

3. Frequência de release

Time de produto que faz deploy semanal precisa de Grey Box recorrente sprint-aligned. Pentest pontual anual fica obsoleto em semanas.

4. Orçamento disponível

Black Box mais barato, White Box mais caro (mesmo total de horas). Grey Box geralmente é o ponto ótimo de custo-benefício.

5. Disponibilidade interna

White Box exige acesso ao código e infra — se time é restritivo com isso, Grey Box pode ser único caminho viável.

Perguntas frequentes

Black Box é sempre mais barato?

Por hora, sim. Mas total de horas pode ser maior porque gasta tempo significativo em recon. Em projeto pequeno (até 50 endpoints), Grey Box geralmente custa similar ao Black Box com cobertura 2x maior.

White Box vale o investimento extra?

Em SaaS imaturo ou pré-launch crítico — sim. Bugs que só aparecem em código (race conditions internas, secrets hardcoded, vulns em dependências) podem custar milhões em breach posterior. Em SaaS já maduro com pentests Grey Box recorrentes, o delta de cobertura justifica menos.

Grey Box atende compliance SOC 2 e ISO 27001?

Sim, com observação. Auditor aceita Grey Box em ciclo regular se houver White Box anual complementar. Grey Box puro sem White Box pode ser questionado em SOC 2 Type II rigoroso.

Posso começar com Black Box e evoluir?

Sim — é prática comum em fornecedores novos. Primeiro pentest Black Box estabelece confiança. Segundo pentest evolui para Grey Box. Terceiro para White Box quando há relação estabelecida.

Black Box é mais “realista” que Grey Box?

Para simular atacante externo SEM credenciais, sim. Mas a maioria dos ataques reais bem sucedidos parte de credenciais comprometidas (phishing, vazamento, insider). Grey Box simula essa realidade pós-comprometimento de credencial — mais relevante na prática.

Quanto tempo cada modalidade leva?

Em projeto comparável: Black Box ~3 semanas (muito tempo em recon), Grey Box ~2 semanas (foco em exploração), White Box ~3–4 semanas (cobertura maior por hora, mas escopo cresce naturalmente).

Conclusão — como escolher hoje

Em 99% dos casos, Grey Box é a resposta correta para SaaS B2B, fintech early-stage, e-commerce, marketplace e healthtech brasileiros. Combina cobertura ampla (60–75%), custo moderado e velocidade de execução.

Use Black Box quando precisa simular exposição externa pura ou está em primeiro engagement com fornecedor novo. Use White Box quando precisa de profundidade máxima — preparação compliance pesada, pré-launch crítico, due diligence técnica, ou setor regulado.

E acima de tudo: combine modalidades ao longo do tempo. Empresa séria em 2026 não fica em um único modelo. Grey Box anual + White Box semestral para áreas críticas + Black Box pontual quando lança feature de exposição externa = postura de segurança madura.

Para conversar sobre qual modalidade faz mais sentido para o seu cenário, veja a oferta da No Vuln ou o guia de preço por porte. Para comparar com outras empresas brasileiras de pentest, veja comparativo das 10 empresas.

Compartilhar

WhatsAppLinkedInX

Próximo passo

Quer aplicar isso ao seu sistema?

A No Vuln faz pentest profundo com a mesma metodologia descrita neste artigo. Solicite uma proposta — NDA bilateral em 24h, escopo definido em call técnica.