ATALAIAUm bug bounty é uma promessa a desconhecidos: enviem-nos o que encontrarem e nós respondemos depressa, com justiça e de boa-fé. Lançar um antes de conseguir cumprir essa promessa tende a produzir uma enxurrada de relatórios, uma caixa de entrada sobrecarregada e investigadores irritados.
A checklist abaixo é para ser feita numa única reunião com engenharia, segurança e quem gere o seu site público. Se não conseguir assinalar a maior parte, comece por uma política de divulgação e volte daqui a um trimestre.
Passo zero: uma VDP e um security.txt
Uma vulnerability disclosure policy (VDP) é a versão gratuita e sempre ativa de um bounty. Diz às pessoas como reportar, o que considera dentro dos limites, e que não vai avançar com ações legais contra investigação de boa-fé. Publique-a antes de qualquer esquema de recompensas.
Depois publique um ficheiro security.txt, conforme descrito no RFC 9116, para que investigadores e ferramentas encontrem o contacto certo.
# https://example.com/.well-known/security.txt
Contact: mailto:security@example.com
Expires: 2027-06-30T23:59:59Z
Policy: https://example.com/security/disclosure
Acknowledgments: https://example.com/security/thanks
Preferred-Languages: en, pt
Canonical: https://example.com/.well-known/security.txtVerifique que a caixa de correio é monitorizada, que a data Expires está no futuro e que alguém é responsável pela renovação.
Checklist de prontidão
| # | Pergunta | Pronto quando |
|---|---|---|
| 1 | Tem uma VDP pública? | Publicada, com link no security.txt, com uma declaração de safe harbour |
| 2 | Já testaram vocês próprios os assets no âmbito? | Foi feito um pentest ou uma revisão interna recente e os findings foram corrigidos |
| 3 | Existe um inventário de assets? | Consegue listar cada domínio, aplicação e API que poria no scope, com um dono |
| 4 | Quem faz a triage? | Pessoas nomeadas com tempo reservado, mais cobertura para férias |
| 5 | Quem corrige? | Cada asset no âmbito está associado a uma equipa que aceitou SLAs de correção |
| 6 | Consegue reproduzir em segurança? | Um ambiente de staging ou contas de teste que investigadores e quem faz triage possam usar |
| 7 | O jurídico está envolvido? | O texto de safe harbour e as condições de pagamento foram revistos |
| 8 | Consegue pagar? | Existe um responsável pelo orçamento e uma forma de pagamento, mesmo para um programa privado |
Um scope que um estranho consegue aplicar
Um bom scope lê-se como um contrato, não como um desejo. Escreva-o de forma a que um investigador que nunca falou consigo consiga decidir se um achado conta.
- No scope: hostnames exatos, identificadores de aplicações e base paths de API, com o ambiente indicado.
- Fora do scope: serviços de terceiros que não controla, sites de marketing e tudo o que é partilhado com outros tenants.
- Classes excluídas: problemas que decidiu não recompensar, como headers em falta sem impacto, self-XSS ou rate limiting em endpoints não sensíveis.
- Regras de atuação: sem negação de serviço, sem engenharia social a colaboradores, sem aceder a dados de outros utilizadores além do que prova o problema, usar as contas de teste fornecidas.
Comece com um programa privado e um scope estreito. Alargue-o quando a triage estiver calma.
SLAs de triage e recompensas
Publique objetivos de resposta que consegue cumprir na sua pior semana, não na melhor. Uma estrutura típica tem quatro relógios:
- Primeira respostaO investigador recebe de uma pessoa a confirmação de que o relatório foi recebido e está a ser analisado.
- Decisão de triageVálido, duplicado, fora do scope ou precisa de mais informação, com uma severidade associada.
- Decisão de recompensaO escalão de recompensa é confirmado assim que a severidade é acordada.
- Correção e divulgaçãoO problema é corrigido, verificado e, quando acordado, divulgado.
Defina as recompensas como uma tabela de escalões por severidade e nível do ativo, e depois preencha os montantes a partir do seu próprio orçamento. A estrutura importa mais do que os números.
| Severidade | Ativos de nível 1 (produto principal, autenticação, pagamentos) | Ativos de nível 2 (aplicações e APIs de suporte) |
|---|---|---|
| Crítico | Banda A | Banda B |
| Alto | Banda B | Banda C |
| Média | Banda C | Banda D |
| Baixa | Banda D | Agradecimento e reconhecimento |
Escreva como pontua a severidade, por exemplo com CVSS mais uma nota sobre o impacto no negócio, para que dois triagers cheguem à mesma resposta.
Fechar o ciclo da correção
Um bounty que só produz pagamentos é um custo. Um que alimenta a linha é um investimento. Para cada relatório válido:
- Abra um ticket no backlog da equipa dona com o SLA associado, não num tracker só de segurança.
- Verifique a correção contra a prova de conceito original e peça ao investigador que volte a testar, quando fizer sentido.
- Adicione um teste de regressão, uma regra Semgrep ou uma verificação do scanner para que a mesma classe não volte sem ninguém dar por isso.
- Pergunte uma vez por trimestre que estações da linha deviam ter apanhado a classe mais cedo, e corrija a estação.
Verifique o seu esta semana
- Obtenha
/.well-known/security.txtno seu domínio principal. Se estiver em falta ou expirado, essa é a sua primeira tarefa. - Percorra a tabela de oito linhas acima com as pessoas certas na sala e marque cada linha com sim, não ou em parte.
- Se houver mais do que dois nãos, publique uma VDP, agende um pentest e volte ao bounty no próximo trimestre.