O GitHub — casa de mais de 180 milhões de desenvolvedores e 600 milhões de repositórios — anunciou uma guinada firme em seu programa de Bug Bounty. A partir de agora, relatórios sem Proof of Concept (PoC) funcional ou que apenas descrevam cenários teóricos perderão prioridade e, em muitos casos, nem chegarão a ser avaliados. A mudança mira em dois problemas que se tornaram frequentes na indústria: o excesso de notificações de baixa qualidade e o aumento de envios “sem impacto real” estimulados por ferramentas automatizadas e, mais recentemente, por inteligência artificial.
Por que isso importa para você?
Se você é desenvolvedor que hospeda código na plataforma, a triagem mais rígida tende a significar correções de vulnerabilidade mais rápidas e menos spam no processo. Para quem caça bugs profissionalmente ou de forma independente, o recado é claro: qualidade vence quantidade — e quem investir tempo em reproduzir e demonstrar falhas concretas deve ver prêmios mais altos e respostas ágeis.
Três novos pilares para uma submissão considerada “completa”
1. Prova de conceito que mostre o impacto: não basta dizer “pode levar a RCE”; é preciso exibir a execução remota de código acontecendo ou, ao menos, evidências inquestionáveis do desvio da política de segurança.
2. Conhecimento do escopo e da lista de ineligíveis: relatórios sobre DKIM, SPF, cabeçalhos de segurança ausentes ou enumeração de usuários, por exemplo, serão encerrados como Not Applicable.
3. Validação manual da descoberta: achados vindos de scanners, SAST ou IA precisam ser revisados pelo próprio pesquisador. Falso positivo virou sinônimo de ruído e afeta a reputação do participante no HackerOne.
IA não é vilã, mas não substitui a revisão humana
Ferramentas como ChatGPT, Copilot e scanners baseados em aprendizado de máquina já são parte do arsenal de segurança — inclusive dentro do próprio GitHub. O que muda é a exigência de responsabilidade compartilhada: a validação final continua sendo do pesquisador. Enviar o “output cru” de um modelo de linguagem sem testar virou rota certa para rejeição.
Segurança por responsabilidade compartilhada: até onde vai o dever do GitHub?
Muitas submissões criticam cenários em que o usuário baixa ou executa código malicioso de propósito. O GitHub reforça que:
Imagem: Internet
- Clonar um repositório é, por definição, um ato de confiança.
- Hooks de Git, filtros ou scripts contidos no projeto rodam porque o usuário decidiu executá-los.
- Análises de IA sobre conteúdo não confiável caem na mesma premissa — o input foi escolhido pelo próprio usuário.
Esses casos, segundo a empresa, fazem parte da “responsabilidade do usuário” e não configuram violação direta das barreiras de segurança da plataforma. Pesquisadores que encontrarem meios de burlar controles sem precisar dessa confiança prévia continuam elegíveis a recompensas robustas.
Swag, não dinheiro, para ajustes menores
Relatórios que apontarem oportunidades de hardening ou falhas documentais — mas que não representem risco explorável — passarão a ser reconhecidos com brindes (camisetas, adesivos, etc.) e não com recompensas em dinheiro. A iniciativa visa concentrar o orçamento do programa nos achados de maior severidade, seguindo a mesma linha já adotada pela Microsoft e pelo Google em 2024.
Dicas rápidas para quem quer ganhar (bem) no programa
• Mire em falhas lógicas ou em bypasses de permissões, não em scans de cabeçalhos.
• Automatize a descoberta, mas manualize a validação.
• Mantenha o relatório enxuto: resumo, passos para reproduzir, PoC e impacto — nada de romancear.
Com a nova diretriz, o GitHub sinaliza que prefere menos relatórios, porém mais profundos, seguindo a filosofia de que “uma falha de alto impacto vale mais do que dez teóricas”. Para os usuários finais, isso deve resultar em uma plataforma ainda mais segura; para os pesquisadores sérios, a promessa é de pagamentos mais justos e fila de análise menos congestionada.
Com informações de GitHub Blog
