Sobre a proteção por push
A proteção de push é um recurso da secret scanning projetado para impedir que informações confidenciais, como segredos ou tokens, sejam enviadas para o repositório em primeiro lugar. Ao contrário da secret scanning, que detecta segredos após seu commit, a proteção de push verifica proativamente seu código em busca de segredos durante o processo de push e bloqueia o push se algum for detectado.
A proteção de push ajuda a evitar os riscos associados a segredos expostos, como acesso não autorizado a recursos ou serviços. Com esse recurso, os desenvolvedores obtêm feedback imediato e podem resolver possíveis problemas antes que eles se tornem uma preocupação de segurança.
Para obter informações sobre os segredos e provedores de serviços compatíveis com a proteção de push, consulte "Padrões de varredura de segredos com suporte".
Como a proteção de push funciona
A proteção contra push funciona:
- Da linha de comando. Confira "Trabalhando com a proteção de push via linha de comando".
- Na interface do usuário do GitHub. Consulte "Trabalhar com proteção de push na interface do usuário do GitHub."
- Da API REST. Confira "Trabalhando com a proteção contra push via API REST."
Uma vez habilitada, se a proteção de push detectar um possível segredo durante uma tentativa de push, ela bloqueará o push e fornecerá uma mensagem detalhada explicando o motivo do bloqueio. Você precisará revisar o código em questão, remover todas as informações confidenciais e tentar o push novamente.
Por padrão, qualquer pessoa com acesso de gravação ao repositório pode optar por ignorar a proteção de push especificando um dos motivos de bypass descritos na tabela. Se um colaborador ignorar um bloco de proteção por push para um segredo, GitHub:
- criará um alerta na guia Segurança do repositório.
- adiciona o evento bypass ao log de auditoria.
- envia um alerta por email para proprietários da organização ou da conta pessoal, gerentes de segurança e administradores de repositório que estiverem inspecionando o repositório, com um link para o segredo e o motivo pelo qual ele foi permitido.
Esta tabela mostra o comportamento dos alertas referente a cada maneira como o usuário pode ignorar um bloco de proteção por push.
Motivo do bypass | Comportamento do alerta |
---|---|
É usado em testes | O GitHub cria um alerta fechado, que é resolvido como "usado em testes" |
Isso é um falso positivo | O GitHub cria um alerta fechado, que é resolvido como "falso positivo" |
Farei a correção mais tarde | O GitHub cria um alerta aberto |
Se desejar maior controle sobre quais contribuidores podem ignorar a proteção de push e quais envios por push contendo segredos devem ser permitidos, você poderá habilitar o bypass delegado para proteção de push. O bypass delegado permite configurar um grupo designado de revisores para supervisionar e gerenciar solicitações a fim de ignorar a proteção de push de contribuidores que enviam por push para o repositório. Para obter mais informações, confira "Sobre o bypass delegado para proteção de push".
Você também pode ignorar a proteção contra push usando a API REST. Para obter mais informações, confira "Pontos de extremidade da API REST para verificação de segredos".
Sobre os benefícios da proteção de push
-
Segurança preventiva: a proteção de push atua como um mecanismo de defesa de linha de frente, verificando o código em busca de segredos no momento do push. Essa abordagem preventiva ajuda a detectar possíveis problemas antes que eles sejam inseridos em seu repositório.
-
Feedback imediato: os desenvolvedores recebem feedback instantâneo se um possível segredo for detectado durante uma tentativa de push. Essa notificação imediata permite uma correção rápida, reduzindo a probabilidade de exposição de informações confidenciais.
-
**Risco reduzido de vazamentos de **dados: ao bloquear commits que contêm informações confidenciais, a proteção contra push reduz significativamente o risco de vazamentos acidentais de dados. Isso ajuda a proteger contra acesso não autorizado à sua infraestrutura, serviços e dados.
-
Gerenciamento eficiente de segredos: em vez de lidar retrospectivamente com segredos expostos, os desenvolvedores podem resolver problemas na origem. Isso torna o gerenciamento de segredos mais eficiente e menos demorado.
-
Integração com pipelines de CI/CD: a proteção contra push pode ser integrada aos pipelines de CI/CD (integração contínua/implantação contínua), garantindo que cada push seja verificado em busca de segredos antes de ser implantado. Isso adiciona uma camada extra de segurança às suas práticas de DevOps.
-
Capacidade de detectar padrões personalizados: as organizações podem definir padrões personalizados para detectar segredos exclusivos de seus próprios ambientes. Essa personalização garante que a proteção de push possa identificar e bloquear com eficácia até mesmo segredos não padrão.
-
Bypass delegado para flexibilidade: para casos em que ocorrem falsos positivos ou quando determinados padrões são necessários, o recurso de bypass delegado permite que usuários designados aprovem pushes específicos. Isso fornece flexibilidade sem comprometer a segurança geral.
Personalizando a proteção de push
Depois que a proteção de push estiver habilitada, você poderá personalizá-la ainda mais:
Integrar com pipelines de CI/CD
Integre a proteção de push aos pipelines de CI/CD (Integração Contínua/Implantação Contínua) para garantir que ela execute verificações durante processos automatizados. Isso normalmente envolve adicionar etapas no arquivo de configuração do pipeline para chamar as APIs do GitHub ou usar GitHub Actions.
Definir padrões personalizados
Defina padrões personalizados que a proteção de push pode usar para identificar segredos e bloquear pushes que contenham esses segredos. Para obter mais informações, confira "Definir padrões personalizados para a verificação de segredo".
Configurar o bypass delegado
Defina colaboradores que podem ignorar a proteção de push e adicione um processo de aprovação para outros colaboradores. Para obter mais informações, confira "Sobre o bypass delegado para proteção de push".