Um programa de bug bounty paga pesquisadores independentes para encontrar e reportar vulnerabilidades em sistemas reais, em operação contínua. É uma das ferramentas mais eficientes de AppSec ofensivo quando o contexto organizacional está pronto para suportá-la — e uma das mais caras quando não está.
Bug bounty, pentest e VDP: três ferramentas distintas
A confusão entre os três conceitos gera expectativas erradas e programas mal dimensionados. A tabela a seguir apresenta as diferenças estruturais:
| Critério | Pentest | VDP | Bug Bounty |
|---|---|---|---|
| Duração | Pontual (5–20 dias) | Contínua | Contínua |
| Executor | Equipe contratada | Comunidade externa | Comunidade externa |
| Remuneração | Contrato fixo | Nenhuma | Por severidade de achado |
| Escopo | Fechado e auditável | Geralmente aberto | Definido pelo programa |
| Entregável | Relatório formal | Relatório do pesquisador | Relatório do pesquisador |
| Safe harbor | Contrato bilateral | Política pública | Regras do programa |
| Norma de referência | PTES, OWASP WSTG | ISO/IEC 29147:2018 | ISO/IEC 29147 + 30111:2019 |
| Objetivo principal | Auditoria pontual | Canal de divulgação | Descoberta contínua |
Pentest é adequado para validar um sistema antes de um lançamento, satisfazer um requisito regulatório (PCI-DSS, SOC 2, ISO 27001) ou auditar uma superfície de ataque específica com profundidade. VDP é o passo anterior ao bug bounty: estabelece a política e o canal de comunicação sem o custo de remuneração. Bug bounty adiciona o incentivo financeiro e, com ele, a capacidade de atrair pesquisadores especializados de forma escalável.
Os três são complementares. Organizações maduras operam os três em paralelo: pentest para auditar novos produtos e integrações críticas, VDP como canal permanente de recebimento e bug bounty para manter pressão ofensiva contínua sobre a superfície de ataque.
Maturidade mínima antes de abrir um programa
Abrir um bug bounty sem os controles internos adequados resulta em sobrecarga da equipe, triagem ineficiente, pesquisadores desestimulados e — no pior cenário — vulnerabilidades críticas reportadas internamente que nunca chegam a ser corrigidas. A sequência recomendada é:
- Fechar o passivo técnico conhecido — vulnerabilidades identificadas em pentests anteriores e em ferramentas de SAST/DAST devem estar corrigidas antes da abertura. Um programa de bounty sobre código com SQL injection óbvio vira triagem remunerada de problemas já conhecidos.
- Estruturar o processo de resposta — é necessário ter um PSIRT (Product Security Incident Response Team) ou equivalente com SLA definido: 24 horas para acuse de recebimento, 5 dias úteis para triagem, 30/60/90 dias para correção de Critical/High/Medium.
- Publicar a VDP primeiro — o canal de divulgação sem recompensa serve como teste de processo. Se a equipe não consegue responder a VDP dentro do SLA, não está pronta para o volume de um bug bounty.
- Garantir capacidade jurídica — o safe harbor precisa ser revisado por advogado com experiência em direito digital brasileiro antes de qualquer publicação.
Organizações com menos de 5 anos de programa de segurança formal raramente estão prontas para um bug bounty público. Isso não é impeditivo: programas privados com 50 a 100 pesquisadores convidados permitem amadurecer processos com volume controlado.
Estrutura do programa: os seis pilares
1. Escopo
O escopo define exatamente quais ativos podem ser testados e quais ações são permitidas. Deve incluir: lista de domínios e subdomínios (com wildcards explícitos quando pertinente), IPs de ambientes de teste, aplicações móveis por plataforma e versão, e APIs com identificação de endpoints sensíveis. O que está fora do escopo deve ser igualmente explícito: infraestrutura de terceiros (CDN, provedores de pagamento), sistemas de parceiros, dados de produção que não podem ser acessados além do necessário para demonstrar o impacto, e ataques de negação de serviço.
2. Safe harbor legal
No Brasil, a ausência de safe harbor faz qualquer teste técnico enquadrável como crime pela Lei 12.737/2012 e pelo artigo 154-A do Código Penal (acesso não autorizado a dispositivo informático). O safe harbor precisa conter: declaração de que o programa constitui autorização expressa para os testes dentro do escopo, definição de ações permitidas e proibidas, comprometimento da empresa de não ingressar com ação civil ou criminal contra pesquisador que agir de boa-fé dentro do escopo, e o prazo de divulgação coordenada (coordinated disclosure window). A ISO/IEC 29147:2018 fornece a estrutura conceitual; a ISO/IEC 30111:2019 detalha o processo de tratamento após o recebimento.
3. Tabela de recompensas por severidade
A escala CVSS v3.1 é o padrão mais adotado. Programas maduros cruzam CVSS com impacto de negócio para chegar ao valor final. Referências de mercado (médias de plataformas como HackerOne e Bugcrowd em 2024–2025):
- Critical (CVSS 9.0–10.0): US$ 5.000 a US$ 50.000+ — RCE sem autenticação, acesso a dados de todos os clientes
- High (CVSS 7.0–8.9): US$ 1.000 a US$ 10.000 — SSRF interno, IDOR com acesso a dados financeiros, privilege escalation
- Medium (CVSS 4.0–6.9): US$ 200 a US$ 2.000 — XSS armazenado, CSRF em função sensível, vazamento parcial de dados
- Low (CVSS 0.1–3.9): reconhecimento público no hall of fame ou valor simbólico (US$ 50–200)
Bônus por cadeia de exploração demonstrada (encadeamento de dois ou mais achados para elevar o impacto) são comuns em programas maduros e incentivam relatórios de maior qualidade técnica.
4. Triagem e SLA de resposta
A triagem é o gargalo operacional de qualquer programa. O fluxo padrão é: recebimento → acuse automático (imediato) → triagem humana (até 5 dias úteis para Critical/High) → confirmação ou rejeição com justificativa → atribuição de severidade e recompensa → correção → pagamento e disclosure coordenado. Plataformas como HackerOne, Bugcrowd e Intigriti oferecem triagem como serviço (managed bug bounty), delegando a etapa de triagem inicial a equipes especializadas — isso reduz o volume de relatórios inválidos que chegam à equipe interna, mas adiciona custo de 10 a 20% sobre o valor das recompensas pagas.
5. Programa privado versus público
Programas privados convidam pesquisadores por reputação verificada nas plataformas. É o modelo adequado para os primeiros 12 a 24 meses de operação. O volume de relatórios é previsível, a qualidade tende a ser superior e os erros de processo têm impacto limitado. A transição para público deve ocorrer quando a equipe demonstrar: taxa de triagem abaixo de 5 dias úteis de forma consistente, percentual de relatórios inválidos abaixo de 30%, e backlog de correção estabilizado. Programas públicos em HackerOne e Bugcrowd atraem de dezenas a centenas de relatórios por mês dependendo do escopo e das recompensas oferecidas.
6. Relação com o programa de AppSec
Bug bounty é uma camada de segurança ofensiva contínua, não um substituto para práticas de segurança no ciclo de desenvolvimento (SSDLC). Os achados de um programa de bounty devem alimentar o backlog de segurança com o mesmo fluxo que vulnerabilidades identificadas em SAST, DAST e revisão de código. Organizações que operam bug bounty sem SSDLC ativo tendem a encontrar as mesmas classes de vulnerabilidade repetidamente — o programa cura o sintoma sem tratar a causa. A correlação entre achados de bounty e métricas de AppSec (densidade de vulnerabilidades por linha de código, tempo médio de correção, reincidência por classe de CWE) é o indicador mais preciso de maturidade do programa.
Plataformas de mercado
HackerOne é a plataforma de maior volume global, com mais de 3.000 programas ativos e um pool declarado de mais de 1 milhão de pesquisadores cadastrados. Oferece triagem gerenciada, integração com sistemas de ticketing (Jira, ServiceNow) e relatórios de benchmark por setor. Bugcrowd tem foco comparativo em programas privados e managed services, com destaque para o modelo CrowdMatch que aloca pesquisadores por especialidade técnica ao escopo do programa. Intigriti é a principal plataforma europeia, com forte presença em empresas que precisam demonstrar conformidade com regulação europeia (DORA, NIS2) e com pesquisadores especializados em aplicações financeiras e de saúde. As três permitem operar programas em real brasileiro, eliminando a fricção cambial para empresas nacionais.
Riscos e custos reais
O custo de um bug bounty vai além das recompensas pagas. Os custos operacionais incluem: horas de engenharia para triagem e correção, taxa da plataforma (10 a 20% sobre recompensas), custo jurídico de redação e manutenção do safe harbor, e eventual custo de triagem gerenciada. Programas públicos ativos em plataformas como HackerOne recebem de 5 a 20 relatórios por semana, dos quais 60 a 80% são inválidos ou duplicados sem triagem gerenciada. O risco principal não é financeiro: é operacional. Um pesquisador que não recebe resposta dentro do SLA e publica a vulnerabilidade antes do prazo de disclosure causa exposição pública antes da correção — o chamado full disclosure adversarial. A prevenção é exclusivamente processual: resposta dentro do SLA, comunicação transparente sobre cronograma de correção e pagamento ágil.
Conformidade e referências normativas
A ISO/IEC 29147:2018 define o processo de divulgação de vulnerabilidades do ponto de vista do receptor — como a organização deve receber, triar e responder a relatórios externos. A ISO/IEC 30111:2019 detalha o processo de tratamento interno: como investigar, priorizar, corrigir e documentar. O OWASP Application Security Verification Standard (ASVS) fornece os critérios técnicos que embasam a classificação de severidade de achados de aplicação. O CVSS v3.1 (Common Vulnerability Scoring System), mantido pelo FIRST, é o padrão de facto para atribuição de pontuação. Para empresas brasileiras com operação regulada, a Resolução BCB 4.658/2018 (setor financeiro) e a LGPD (Lei 13.709/2018) reforçam a necessidade de processos formais de divulgação e resposta — o que torna a estrutura de VDP e bug bounty parte da governança de conformidade, não apenas de segurança ofensiva.
Perguntas frequentes
- Qual a diferença entre bug bounty, pentest e VDP?
- Pentest é um teste técnico com escopo fechado, equipe contratada, prazo e entrega formal de relatório — ideal para auditar um sistema antes de um lançamento ou certificação. VDP (Vulnerability Disclosure Program) é uma política pública que define como pesquisadores externos podem reportar vulnerabilidades sem recompensa financeira, mas com garantia de não retaliação legal. Bug bounty combina os dois mundos: é um programa contínuo, aberto a pesquisadores externos, com recompensas financeiras proporcionais à severidade da vulnerabilidade encontrada. Os três são complementares e não excludentes.
- Minha empresa precisa de maturidade mínima para abrir um bug bounty?
- Sim. Lançar um bug bounty sem controles básicos equivale a abrir a porta de um edifício em construção ao público. A organização precisa ter: processo de triagem e resposta a vulnerabilidades (PSIRT ou similar), SLA de correção definido por severidade, canal seguro de recebimento de relatórios e capacidade jurídica de formalizar o safe harbor. Empresas que ainda não eliminaram vulnerabilidades conhecidas de seu backlog terão o programa tomado por achados de baixo valor, sobrecarregando a equipe. O caminho recomendado é: VDP primeiro, pentest recorrente para fechar o passivo técnico, bug bounty privado para amadurecer processos, e só então abertura pública.
- O que é safe harbor e por que ele é obrigatório?
- Safe harbor é a cláusula legal — integrante das regras do programa — que garante imunidade civil e criminal ao pesquisador que agir dentro do escopo definido. Sem ela, qualquer teste pode ser enquadrado como acesso não autorizado pela Lei 12.737/2012 (Lei Carolina Dieckmann) e pelo Marco Civil da Internet. O safe harbor precisa especificar: quais sistemas estão no escopo, quais ações são permitidas, vedações explícitas e o canal de comunicação seguro. A ISO/IEC 29147:2018 e a ISO/IEC 30111:2019 fornecem a estrutura normativa para redigir essas políticas.
- Como definir o valor das recompensas?
- A escala mais usada baseia-se no CVSS v3.1: Critical (9.0–10.0) → US$ 5.000–50.000+; High (7.0–8.9) → US$ 1.000–10.000; Medium (4.0–6.9) → US$ 200–2.000; Low (0.1–3.9) → reconhecimento ou valor simbólico. O fator decisivo é o impacto ao negócio: uma IDOR que expõe dados financeiros de todos os clientes pode ter CVSS 6.5 e recompensa máxima, enquanto um XSS em ambiente sandbox pode ter CVSS 7.4 e recompensa mínima. Programas maduros adotam tabelas públicas de escopo × severidade × recompensa, eliminando arbitrariedade na triagem.
- Programa privado ou público — qual escolher primeiro?
- Programas privados são convites diretos a um grupo seleto de pesquisadores (geralmente 50–200) e são o ponto de partida adequado para a maioria das organizações. Eles permitem calibrar a qualidade dos relatórios, testar o processo de triagem e ajustar recompensas antes de uma exposição irrestrita. A transição para público deve ocorrer somente quando a equipe interna demonstrar capacidade de processar o volume esperado de relatórios dentro do SLA — caso contrário, a experiência do pesquisador se degrada e os melhores talentos migram para programas que respondem mais rapidamente.
- Quais são os erros mais comuns ao estruturar um bug bounty?
- Os erros mais frequentes são: escopo genérico demais sem listar URLs e IPs; ausência de safe harbor explícito; SLA de resposta inexistente; triagem feita por um único analista sobrecarregado; recompensas abaixo do mercado para severidades altas; não ter corrigido vulnerabilidades conhecidas antes de abrir o programa; e confundir bug bounty com substituto do pentest. São ferramentas distintas com funções complementares.
Como a Decripte pode ajudar
A Decripte conduz pentests e assessments técnicos de AppSec para organizações de todos os portes — do MEI ao Enterprise com mais de 100.000 colaboradores. Além da execução técnica, a equipe da Decripte estrutura programas de divulgação responsável (VDP) e bug bounty: definição de escopo, redação do safe harbor adaptado à legislação brasileira, dimensionamento da tabela de recompensas por severidade CVSS, seleção e configuração de plataforma (HackerOne, Bugcrowd, Intigriti ou programa próprio), e treinamento da equipe interna de triagem. O resultado é um programa operacional, conforme com ISO 29147 e 30111, e dimensionado para a realidade de cada organização.
Acesse nossos planos ou inicie gratuitamente com o diagnóstico de ameaças — sem custo, sem compromisso.