GitHub mostra status de proteção de repositórios nos relatórios de risco de segurança

O GitHub atualizou, em 2 de novembro de 2026, as telas de avaliação de risco de segurança da plataforma para incluir uma informação que antes ficava escondida: se o repositório onde um problema foi encontrado está protegido ou não. A mudança vale para dois recursos específicos, o code security risk assessment e o secret risk assessment, segundo o changelog oficial do GitHub.

Na prática, isso significa que, ao abrir uma avaliação de risco, o time de segurança não vê mais só "existem X vulnerabilidades" ou "há Y segredos expostos": vê também em quais desses casos o repositório já tem alguma camada de proteção ativa e em quais não tem nenhuma. É a diferença entre saber que existe um problema e saber onde esse problema está mais exposto.

Onde essa tela fica e quem acessa

O recurso não é novo em si: o GitHub já oferecia risk assessments para code security e para secret scanning dentro da aba Security das organizações. O que mudou foi o conteúdo exibido por achado.

Admins de organização e security managers continuam sendo os perfis que iniciam uma avaliação, pelo caminho Security > Assessments na organização. Depois de rodada, a diferença aparece na lista de achados: cada um vem marcado como estando em repositório protegido ou desprotegido, o que já permite segmentar a visão sem precisar cruzar manualmente planilhas de branch protection com a lista de vulnerabilidades.

Por que "protegido" importa mais do que "existe"

Quem trabalha com AppSec em organizações grandes conhece o problema: ter visibilidade sobre vulnerabilidades é fácil, o difícil é decidir por onde começar a corrigir. Um achado crítico num repositório que já tem push protection ativado para segredos, revisão obrigatória de pull request e code scanning configurado tende a ser menos urgente do que o mesmo achado num repositório órfão, sem nenhuma política de branch protection.

Até esta mudança, cruzar essas duas informações, a gravidade do achado e o nível de proteção do repositório onde ele mora, exigia trabalho manual: exportar a lista de achados, exportar a lista de repositórios com regras de proteção configuradas, e fazer o join à mão (ou via API). Agora essa correlação já vem pronta dentro da própria tela de avaliação de risco.

Em resumo: a mudança não cria um achado novo nem corrige nada sozinha; ela reorganiza a informação que já existia para que a priorização de remediação saia mais rápido de uma reunião de segurança.

O que conta como "repositório protegido"

O changelog do GitHub não detalha, linha por linha, os critérios exatos que definem um repositório como protegido dentro dessa avaliação. Pela documentação histórica do GitHub Advanced Security (GHAS), a leitura mais provável é que o status reflita a combinação de regras de proteção de branch (revisão obrigatória, checks de status obrigatórios) com a presença de recursos de segurança ativos no repositório, como code scanning e secret scanning com push protection.

Isso é relevante porque muda o jeito de interpretar o sinal: "desprotegido" aqui não quer dizer necessariamente "sem nenhuma segurança", pode significar apenas que falta uma das camadas esperadas. Antes de usar esse status como régua definitiva de prioridade, vale conferir na própria organização quais políticas de proteção estão configuradas como padrão, porque o rótulo só é tão confiável quanto a política que ele mede.

Disponibilidade por plano

A funcionalidade não chega igual para todo mundo. Segundo o GitHub:

• Já está disponível em GitHub Enterprise Cloud e GitHub Team, tanto para code security risk assessment quanto para secret risk assessment;
• Para GitHub Enterprise Server, o recurso chega apenas junto da versão 3.24, e só para o secret risk assessment.

Quem roda GitHub Enterprise Server numa versão anterior à 3.24 não tem acesso a essa visão ainda, nem para código nem para segredos. Isso é relevante para times com infraestrutura on-premises que planejam o calendário de upgrade: a atualização para 3.24 passa a carregar, junto com os bugfixes de praxe, uma mudança de workflow em como a equipe de segurança prioriza achados.

O que essa mudança não resolve

Vale ser direto sobre os limites da novidade, porque é fácil superestimar uma melhoria de visibilidade:

• Ela não detecta nada de novo: é uma camada de contexto sobre achados que o code scanning e o secret scanning já produziam antes;
• Ela não corrige automaticamente repositórios desprotegidos, só ajuda a enxergar quais merecem atenção primeiro;
• Ela pressupõe que a organização já usa os recursos de GHAS (code scanning, secret scanning) de forma ampla; quem tem cobertura parcial desses recursos vai ver o status de proteção só nos repositórios onde já roda alguma varredura.

Para equipes pequenas, com poucos repositórios e sem um programa formal de AppSec, o ganho é marginal: dá para simplesmente olhar repositório por repositório e decidir manualmente. O valor real aparece em organizações com dezenas ou centenas de repositórios, onde a avaliação de risco já era usada como ferramenta de priorização e faltava justamente esse cruzamento entre gravidade e exposição.

Onde conferir os detalhes

O GitHub publicou documentação específica tanto para o code security risk assessment quanto para o secret risk assessment, referenciada no próprio changelog. Vale a leitura antes de rodar a primeira avaliação pós-atualização, principalmente para confirmar os critérios técnicos que definem proteção na versão do produto em uso, já que GitHub Enterprise Cloud, Team e Server podem evoluir esse detalhe em ritmos diferentes.

Fonte: GitHub Changelog