Neste artigo
Introdução
Não importa quão rigoroso seja seu programa de segurança - você não pode testar tudo, o tempo todo, com todas as perspectivas possíveis. É aqui que Bug Bounty entra: programas que pagam recompensas a pesquisadores externos que encontram e reportam vulnerabilidades antes que atacantes maliciosos as explorem.
Gigantes de tecnologia como Google, Microsoft, Meta e Apple pagam coletivamente dezenas de milhões de dólares por ano em recompensas. O Google pagou mais de $12 milhões em 2023 apenas no programa Android/Chrome. Mas bug bounty não é mais exclusividade de big tech - organizações de todos os tamanhos e setores estão adotando essa abordagem.
Este guia explora como estruturar um programa de bug bounty eficaz, desde a decisão de lançar até a gestão contínua e métricas de sucesso.
O que é Bug Bounty
Conceito
Bug Bounty é uma forma de crowdsourced security onde organizações convidam hackers éticos a testar seus sistemas em troca de recompensas financeiras por vulnerabilidades válidas encontradas. É um modelo de "pay for results" - você só paga quando algo é encontrado.
Por que Bug Bounty Funciona
Vantagens do Modelo
+---------------------------------------------------------------+
| POR QUE BUG BOUNTY FUNCIONA |
+---------------------------------------------------------------+
| |
| DIVERSIDADE DE EXPERTISE |
| - Milhares de pesquisadores com habilidades diferentes |
| - Especialistas em web, mobile, API, infra, cloud |
| - Técnicas e ferramentas diversas |
| - Perspectivas que seu time interno não tem |
| |
| TESTING CONTÍNUO |
| - 24/7/365 - sempre tem alguém testando |
| - Cada deploy, cada feature nova |
| - Não limitado por escopo de projeto |
| |
| ECONOMIA |
| - Pay-for-results - só paga se encontrar |
| - Sem overhead de contratação |
| - Escala sem limite de headcount |
| |
| MOTIVAÇÃO ALINHADA |
| - Pesquisadores querem encontrar - são pagos para isso |
| - Competição natural leva a criatividade |
| - Reputação na comunidade como incentivo adicional |
| |
+---------------------------------------------------------------+
O que Bug Bounty NÃO é
- Não substitui security by design - Você precisa de um baseline de segurança
- Não substitui pentest - Pentest é sistemático, bug bounty é oportunístico
- Não é só para empresas tech - Qualquer organização com presença digital pode se beneficiar
- Não é "deixar hackers atacarem" - É um programa controlado com regras claras
VDP vs Bug Bounty
Comparação VDP vs Bug Bounty
+---------------------------------------------------------------+
| VDP vs BUG BOUNTY |
+---------------------------------------------------------------+
| |
| VDP (Vulnerability Disclosure Program) |
| +-----------------------------------------------------------+|
| | - Canal para receber reports sem pagamento ||
| | - Reconhecimento/Hall of Fame como incentivo ||
| | - Safe harbor legal para pesquisadores ||
| | - Baixo custo (apenas tempo de triagem) ||
| | - Menor volume de reports ||
| | - Recomendado como primeiro passo ||
| | ||
| | Quando usar: ||
| | - Orçamento limitado ||
| | - Maturidade de segurança inicial ||
| | - Testar processos internos primeiro ||
| +-----------------------------------------------------------+|
| |
| BUG BOUNTY |
| +-----------------------------------------------------------+|
| | - Recompensas financeiras por vulnerabilidades ||
| | - Atrai mais pesquisadores e mais esforço ||
| | - Maior volume e qualidade de reports ||
| | - Custo variável baseado em findings ||
| | - Pode ser privado (convidados) ou público ||
| | ||
| | Quando usar: ||
| | - Maturidade para processar volume de reports ||
| | - Orçamento para recompensas ||
| | - Ativos críticos que justificam investimento ||
| +-----------------------------------------------------------+|
| |
| PROGRESSÃO RECOMENDADA: |
| 1. VDP privado > 2. VDP publico > 3. Bug Bounty privado |
| > 4. Bug Bounty publico |
| |
+---------------------------------------------------------------+
Estruturando o Programa
Pré-requisitos Organizacionais
Antes de Lançar um Bug Bounty
- Baseline de segurança - Corrija vulnerabilidades óbvias primeiro
- Processo de remediação - Capacidade de corrigir findings em tempo hábil
- Triagem interna - Recursos para validar e responder a reports
- Buy-in da liderança - Orçamento aprovado e suporte executivo
- Ambiente de teste - Idealmente staging separado de produção
- Documentação - Escopo, regras, política de disclosure claramente definidos
Componentes do Programa
1. Política do Programa
Documento público que define:
- Escopo (o que pode e não pode ser testado)
- Regras de engajamento (comportamento permitido)
- Safe harbor legal (proteção aos pesquisadores)
- Processo de report e comunicação
- SLAs de resposta
- Estrutura de recompensas
2. Infraestrutura
- Canal de recebimento de reports (plataforma ou email)
- Sistema de tracking (integração com ticketing)
- Ambiente para reprodução de vulnerabilidades
- Processo de pagamento
3. Equipe
- Triadores (validar reports, comunicar com pesquisadores)
- Desenvolvedores (corrigir vulnerabilidades)
- Gestão do programa (métricas, orçamento, políticas)
Definindo o Escopo
In Scope (Permitido)
Exemplo de Escopo
# ATIVOS IN SCOPE
## Produção
- www.exemplo.com
- api.exemplo.com
- app.exemplo.com (web app)
- Aplicativo iOS (App Store)
- Aplicativo Android (Play Store)
## Staging (preferível para testes destrutivos)
- staging.exemplo.com
# TIPOS DE VULNERABILIDADE IN SCOPE
## Crítico ($$$)
- Remote Code Execution (RCE)
- SQL Injection com acesso a dados
- Authentication Bypass
- Privilege Escalation
## Alto ($$)
- Stored XSS em áreas autenticadas
- IDOR com acesso a dados sensíveis
- SSRF interno
- Insecure Direct Object Reference
## Médio ($)
- CSRF em ações críticas
- Reflected XSS
- Information Disclosure significativa
- Misconfiguration com impacto
## Baixo
- Information Disclosure menor
- Self-XSS
- Missing security headers
Out of Scope (Proibido)
Exclusões Comuns
# ATIVOS OUT OF SCOPE
- Infraestrutura de parceiros/terceiros
- Domínios de teste não listados
- Ambientes de desenvolvimento interno
- Sistemas corporativos internos (email, VPN)
# TÉCNICAS PROIBIDAS
- DoS/DDoS
- Spam ou phishing contra usuários reais
- Engenharia social contra funcionários
- Acesso físico às instalações
- Teste em contas de outros usuários (sem permissão)
- Divulgação pública antes de correção
# VULNERABILIDADES OUT OF SCOPE
- Relatórios de scanner sem PoC
- Clickjacking em páginas sem ação sensível
- CSRF em logout
- Self-XSS
- Ratelimit issues sem impacto demonstrado
- Missing security headers sem exploit
- Versão de software desatualizada (sem PoC)
- Políticas de senha fracas (apenas report)
- Email spoofing sem SPF/DKIM (já conhecido)
Estrutura de Recompensas
Tabela de Recompensas
Exemplo de Estrutura de Pagamento
+---------------------------------------------------------------+
| TABELA DE RECOMPENSAS |
+---------------------------------------------------------------+
| |
| SEVERIDADE RANGE EXEMPLOS |
| ----------------------------------------------------------- |
| Critical $5,000 - $25,000 RCE, Auth bypass completo, |
| SQLi com dump de DB, |
| Account takeover em massa |
| |
| High $1,000 - $5,000 Stored XSS em área sensível,|
| IDOR com PII, SSRF interno, |
| Privilege escalation |
| |
| Medium $200 - $1,000 Reflected XSS, CSRF em |
| ação importante, Info |
| disclosure moderada |
| |
| Low $50 - $200 Info disclosure menor, |
| Missing security controls |
| com impacto limitado |
| |
| ----------------------------------------------------------- |
| |
| MODIFICADORES: |
| + Qualidade excepcional do report: +25% |
| + Impacto em dados de clientes: +50% |
| + Exploit chain criativo: +25% |
| - Duplicata (segundo a reportar): 0 |
| - Report incompleto: Pendente ate completar |
| |
+---------------------------------------------------------------+
Fatores que Influenciam Valores
- Indústria - Fintech e crypto pagam mais
- Tamanho da empresa - Grandes empresas têm budgets maiores
- Criticidade dos dados - Dados sensíveis = recompensas maiores
- Maturidade do programa - Programas novos podem pagar menos
- Competição - Atrair pesquisadores requer ser competitivo
Plataformas e Modelos
Plataformas Gerenciadas
HackerOne
- Maior plataforma global
- Pool de 1M+ pesquisadores
- Triagem gerenciada opcional
- Enterprise features robustos
Bugcrowd
- Forte em programas gerenciados
- Foco em qualidade sobre quantidade
- Triagem incluída na maioria dos planos
Intigriti
- Forte na Europa (GDPR-friendly)
- Triagem de qualidade
- Bom para empresas europeias
YesWeHack
- Europeia, foco em compliance
- Bom para regulados (finanças, saúde)
Self-Hosted
Algumas organizações gerenciam programas internamente:
- Pros: Controle total, sem taxa de plataforma
- Contras: Menos visibilidade, overhead de gestão, menor pool de pesquisadores
- Ferramentas: security.txt, email dedicado, integração com Jira/ServiceNow
Privado vs Público
Programa Privado vs Público
Privado (Invite-Only):
- Convida pesquisadores selecionados
- Menor volume, maior qualidade
- Bom para início ou ativos sensíveis
- Menos ruído e duplicatas
Público:
- Aberto a qualquer pesquisador
- Maior cobertura e volume
- Mais duplicatas e low-quality reports
- Demonstra maturidade de segurança
Triagem e Validação
Workflow de Triagem
Processo de Validação
+---------------------------------------------------------------+
| WORKFLOW DE TRIAGEM |
+---------------------------------------------------------------+
| |
| 1. REPORT RECEBIDO |
| +-> Acknowledge em < 24h |
| "Obrigado pelo report. Estamos analisando." |
| |
| 2. TRIAGEM INICIAL (24-48h) |
| +-> É in scope? |
| | +-> NÃO -> Close como out of scope |
| +-> É duplicata? |
| | +-> SIM -> Close como duplicate |
| +-> Informações suficientes? |
| | +-> NÃO -> Pedir mais detalhes |
| +-> Passa para validação técnica |
| |
| 3. VALIDAÇÃO TÉCNICA (48-72h) |
| +-> Reproduzir em ambiente de teste |
| +-> Confirmar impacto real |
| +-> Classificar severidade (CVSS ou interno) |
| +-> Determinar recompensa |
| |
| 4. COMUNICAÇÃO |
| +-> Informar pesquisador: validado/não validado, |
| severidade, recompensa aprovada |
| |
| 5. REMEDIAÇÃO |
| +-> Criar ticket para dev team |
| +-> Priorizar baseado em severidade |
| +-> Timeline típica: |
| Critical: 1-7 dias |
| High: 7-30 dias |
| Medium: 30-60 dias |
| Low: 90 dias |
| |
| 6. FECHAMENTO |
| +-> Notificar pesquisador quando corrigido |
| +-> Pagar recompensa |
| +-> Fechar report |
| |
+---------------------------------------------------------------+
SLAs Recomendados
- Acknowledge inicial: < 24 horas
- Triagem inicial: < 3 dias úteis
- Validação completa: < 10 dias úteis
- Decisão de bounty: < 15 dias úteis
- Pagamento após aprovação: < 30 dias
Relacionamento com Pesquisadores
Boas Práticas
- Comunicação rápida e respeitosa - Pesquisadores são parceiros, não adversários
- Transparência - Explique decisões de triagem e severidade
- Reconhecimento - Hall of Fame, swag, agradecimentos públicos
- Feedback - Ajude pesquisadores a melhorar reports
- Consistência - Aplique regras igualmente a todos
O que Evitar
- Ignorar ou demorar excessivamente para responder
- Fechar reports válidos sem explicação
- Downgrade injustificado de severidade
- Ameaças legais contra pesquisadores de boa-fé
- Pedir exclusividade em troca de safe harbor
Construindo Comunidade
Programas bem-sucedidos cultivam relacionamentos:
- Comunicar fixes e agradecer publicamente
- Oferecer bonus por reports excepcionais
- Convidar top researchers para programas exclusivos
- Participar de eventos de segurança
Métricas de Sucesso
KPIs de Bug Bounty
# Métricas de Volume
- Total de reports recebidos
- Reports válidos vs inválidos (signal-to-noise)
- Vulnerabilidades por severidade
- Pesquisadores ativos
# Métricas de Tempo
- Tempo para first response
- Tempo para triagem
- Tempo para fix (por severidade)
- Tempo para pagamento
# Métricas Financeiras
- Total pago em recompensas
- Custo por vulnerabilidade
- Cost per valid report
- ROI vs custo de breach evitado
# Métricas de Qualidade
- Duplicatas rate
- Reopen rate (fix incompleto)
- Researcher satisfaction
- Top vulnerabilities found
# Benchmarks Típicos
- Valid rate: 15-30% (bom programa)
- First response: < 24h
- Triagem: < 5 dias
- Fix critical: < 7 dias
Perguntas Frequentes
Bug Bounty é um programa onde organizações pagam recompensas a pesquisadores de segurança que encontram e reportam vulnerabilidades de forma responsável. É uma forma de crowdsourced security que complementa testes tradicionais, aproveitando a expertise diversa de milhares de hackers éticos globalmente para encontrar falhas antes que atacantes maliciosos as explorem.
VDP (Vulnerability Disclosure Program) é um canal para receber reports de vulnerabilidades sem pagamento de recompensas - apenas reconhecimento e safe harbor legal. Bug Bounty adiciona incentivos financeiros. VDP é recomendado como passo inicial antes de bug bounty, custando menos e estabelecendo processos. Organizações maduras frequentemente mantêm ambos: VDP público + Bug Bounty privado ou focado.
Custos incluem: recompensas (variável, $100-500k+/ano dependendo do escopo e maturidade), plataforma ($20k-100k+/ano para HackerOne, Bugcrowd, etc. ou grátis para self-hosted), triagem ($50k-150k/ano se terceirizada), e tempo interno para validação e correção. Programas iniciantes podem começar com $50-100k/ano em budget total; programas maduros de empresas tech investem $500k-2M+/ano.
Valores variam por severidade: Critical (RCE, auth bypass em produção) $5,000-100,000+; High (SQLi, stored XSS em área sensível) $1,000-15,000; Medium (CSRF, IDOR) $200-3,000; Low (information disclosure menor) $50-500. Fatores que aumentam: impacto em dados sensíveis, qualidade do report, exploitability. Compare com programas similares e ajuste conforme feedback dos pesquisadores.
Não - são complementares. Pentest oferece cobertura sistemática em tempo definido, relatório formal para compliance, e teste de áreas específicas. Bug Bounty oferece testing contínuo, diversidade de perspectivas e técnicas, e descoberta de vulnerabilidades criativas. Modelo ideal: pentest anual para baseline e compliance + bug bounty contínuo para descoberta ongoing.
Conclusão
Bug Bounty representa uma mudança de paradigma na forma como organizações encontram vulnerabilidades: em vez de depender exclusivamente de equipe interna ou pentests pontuais, você tem acesso contínuo a milhares de especialistas motivados a encontrar problemas antes que atacantes o façam.
O sucesso de um programa de bug bounty depende menos do tamanho das recompensas e mais da qualidade da execução: escopo claro, comunicação rápida e respeitosa, remediação eficiente, e tratamento justo dos pesquisadores. Programas que constroem reputação positiva atraem os melhores talentos e geram o maior retorno.
Comece com um VDP para estabelecer processos, evolua para bug bounty privado para controlar volume, e considere publico quando tiver maturidade para lidar com a escala. O investimento se paga na primeira vulnerabilidade critica encontrada antes de ser explorada.
Lance seu Programa de Bug Bounty
Precisa de ajuda para estruturar seu programa de bug bounty, definir políticas ou gerenciar triagem? Entre em contato para uma consultoria especializada.
Solicitar Avaliação