GitHub destaca seis configurações essenciais para a segurança de projetos open source

O GitHub Security Lab não está lançando novas ferramentas, mas sistematizando o que já existe em produção, e o que já foi validado internamente. O 'Protect Your Project' é um assistente de configuração, não um produto de segurança novo: ele orquestra seis recursos pré-existentes, todos gratuitos para repositórios públicos, mas historicamente subutilizados por falta de orientação prática. O SECURITY.md, por exemplo, não é um arquivo mágico: ele só funciona se for mantido com políticas reais de resposta a vulnerabilidades, e 73% dos projetos open source que o têm não atualizam o prazo de divulgação responsável. O secret scanning detectou 28,65 milhões de segredos hardcoded em 2025, mas sua eficácia real depende da ativação da proteção por push (disponível apenas no GitHub Advanced Security) ou do uso de workflows de remediação automatizados, algo que o GitHub conseguiu ao reduzir 20.000+ alertas para inbox zero em nove meses, com equipes dedicadas de engenharia de segurança operacional.

O Dependabot hoje roda como workflow nativo do GitHub Actions, não como serviço legado, e isso muda o modelo de operação: os mantenedores precisam entender triggers, permissões de token e escopo de acesso, não só clicar em 'ativar'. Já o code scanning com CodeQL exige que o repositório tenha um workflow de análise configurado (como o padrão .github/workflows/codeql-analysis.yml) para gerar alertas úteis, e não basta ter o arquivo, é preciso interpretar as queries abertas do GitHub Security Lab, que são atualizadas semanalmente para novas classes de vulnerabilidade. A proteção de branches, por sua vez, é a única dessas seis configurações que impõe restrições *de fato* ao fluxo de código, mas só se aplicada a branches críticos (ex: main, stable) e com verificações obrigatórias ativadas, não apenas com 'require pull request reviews' ligado.

A principal mudança desde a cobertura CEVIU de 1º de julho é operacional, não técnica: o GitHub deixou de apenas listar as seis configurações e passou a oferecer um assistente guiado ('Protect Your Project') que valida, em tempo real, se cada uma delas está corretamente implementada, incluindo verificação de conteúdo do SECURITY.md, presença de workflows de code scanning e status do secret scanning. Antes, o foco era no 'o que ativar'; agora, é no 'o que está funcionando'. Também houve uma mudança de política: a partir de 1º de abril de 2025, o secret scanning e o code scanning migraram para produtos autônomos pagos (US$19 e US$30/mês por committer), mas a versão gratuita para repositórios públicos permanece intacta, o que confirma que essas seis configurações continuam sendo o piso mínimo de segurança acessível, não um degrau comercial.

Essas seis configurações são o equivalente DevOps à instalação de fechadura, alarme e câmera em uma casa: não impedem invasões sofisticadas, mas eliminam 80% dos ataques automatizados e de baixa complexidade que exploram descuidos operacionais. Para equipes de plataforma, isso significa menos tempo gasto em investigação de incidentes falsos positivos e mais tempo em engenharia de resiliência real, como modelagem de ameaças em pipelines, que já foi discutida em nossa cobertura sobre segurança em CI/CD link. Para mantenedores individuais, é a diferença entre ter um CVE reportado publicamente sem aviso prévio e receber um alerta privado com 90 dias para correção. Em um ecossistema onde 97% dos aplicativos usam código aberto e 84% das bases de código têm pelo menos uma vulnerabilidade conhecida, essa camada mínima de defesa não é opcional, é infraestrutura.