Fase 6: Distribuição e exame de segredos em escala

É possível habilitar a verificação de segredos em repositórios individuais ou em todos os repositórios em uma organização ou empresa. Para saber mais, confira Gerenciando as configurações de segurança e análise do repositório, Gerenciando as configurações de segurança e de análise da sua organização ou Como gerenciar os recursos do GitHub Advanced Security na empresa.

Você pode habilitar rapidamente os recursos de segurança em escala com um security configuration, uma coleção de configurações de habilitação de segurança que você pode aplicar a repositórios em uma organização. Você pode personalizar ainda mais os recursos do GitHub Advanced Security no nível da organização com global settings. Confira "Sobre a habilitação de recursos de segurança em escala".

Este artigo oferece um processo resumido com foco na habilitação do secret scanning para todos os repositórios em uma organização. Os princípios descritos neste artigo ainda poderão ser aplicados mesmo se você adotar uma abordagem mais escalonada para a habilitação do secret scanning em repositórios individuais.

1. Concentrar-se em segredos recém-confirmados

Ao habilitar o secret scanning, concentre-se na correção de quaisquer credenciais recém-confirmadas que tenham sido detectadas pelo exame de segredos. Se você se concentrar na limpeza de credenciais confirmadas, os desenvolvedores poderão continuar a enviar acidentalmente novas credenciais, o que significa que sua contagem total de segredos permanecerá no mesmo nível, e não diminuirá conforme o esperado. Por isso, é essencial impedir o vazamento de novas credenciais antes de se concentrar em revogar quaisquer segredos atuais.

Há algumas abordagens para lidar com credenciais recém-comprometidas, mas um exemplo seria o seguinte:

1. Notificação: use webhooks para garantir que quaisquer novos alertas de segredos sejam vistos pelas equipes certas o mais rápido possível. Um webhook é disparado quando um alerta de segredo é criado, resolvido ou reaberto. É possível analisar a carga útil do webhook e integrá-la a qualquer ferramenta usada por você e sua equipe, como o Slack, o Teams, o Splunk ou o e-mail. Para saber mais, confira Sobre webhooks e Eventos e cargas de webhook.

2. Acompanhamento: crie um processo de correção resumido que funcione para todos os tipos de segredo. Por exemplo, entre em contato com o desenvolvedor que confirmou o segredo e com o respectivo líder técnico no projeto e realce os perigos de confirmar segredos no GitHub, pedindo que eles revoguem e atualizem o segredo detectado.

   Note

   Você pode automatizar esta etapa. Para grandes empresas e organizações com centenas de repositórios, o acompanhamento manual é insustentável. Uma alternativa seria incorporar a automação no processo de webhook definido na primeira etapa. O conteúdo do webhook contém informações de repositório e organização sobre o segredo vazado. Com elas, é possível entrar em contato com os atuais encarregados pela manutenção do repositório e criar um email/mensagem para as pessoas responsáveis ou abrir um problema.

3. Educação: crie um documento de treinamento interno para o desenvolvedor que confirmou o segredo. Nesse documento, explique os riscos provenientes da confirmação de segredos e ofereça informações de práticas recomendadas para o uso seguro de segredos no desenvolvimento. Se um desenvolvedor não aprender com a experiência e continuar a confirmar segredos, crie um processo de escalonamento. No entanto, a educação geralmente funciona bem.

Repita as duas últimas etapas para quaisquer novos segredos vazados. Esse processo incentiva os desenvolvedores a assumir a responsabilidade pelo gerenciamento seguro dos segredos usados em seus códigos e permite medir a redução de segredos recém-confirmados.

2. Habilitar a proteção por push

Depois de habilitar o secret scanning, você também deve habilitar a proteção por push. Com a proteção por push, o secret scanning verifica os envios por push para segredos com suporte e bloqueia pushs para GitHub antes que os segredos sejam expostos a outros usuários. Para obter informações sobre como habilitar a proteção de push, confira Habilitar a proteção de push para seu repositório.

Depois de habilitado, você pode fazer o seguinte:

1. Fornecer diretrizes: configure um link personalizado na mensagem para que os colaboradores vejam se push está bloqueado por secret scanning. O recurso vinculado pode fornecer diretrizes para os colaboradores sobre como resolver o push bloqueado. Para saber mais, confira Habilitar a proteção de push para seu repositório.

2. Notificar: defina um webhook que rastreie especificamente alertas de verificação de segredo criado quando alguém ignora a proteção por push usando a propriedade de alerta "push_protection_bypassed": true. Ou use a API para obter atualizações nas quais os alertas de verificação de segredo foram o resultado de um desvio de proteção por push filtrando a lista de resultados para "push_protection_bypassed": true. Para saber mais, confira Alertas de segurança de auditoria.

3. Monitorar: use a visão geral de segurança para exibir métricas sobre o desempenho da proteção por push em repositórios em toda a organização, para que você possa identificar rapidamente quaisquer repositórios em que talvez precise agir. Para saber mais, confira Exibir métricas para proteção por push para a verificação de segredos.

3. Corrija os segredos confirmados, começando pelos mais críticos

Depois de estabelecer um processo para reduzir a adição de segredos às suas bases de código, você estará pronto para começar a trabalhar corrigindo segredos que foram confirmados antes de introduzir a GitHub Advanced Security.

A definição dos segredos mais críticos dependerá dos processos e das integrações de sua organização. Por exemplo, uma empresa provavelmente não se preocupará com a chegada de um segredo de webhook do Slack se não usar o Slack. Pode ser útil começar com os cinco principais tipos de credenciais mais importantes para sua organização.

Depois de decidir os tipos secretos, faça o seguinte:

1. Defina um processo para corrigir cada tipo de segredo. Geralmente, o procedimento real de cada tipo de segredo será drasticamente diferente. Anote o processo de cada tipo de segredo em um documento ou base de conhecimento interna.

   Note

   Ao criar o processo de revogação de segredos, tente atribuir a responsabilidade de revogar segredos à equipe que mantém o repositório em vez de a uma equipe central. Um dos princípios do GHAS é que os desenvolvedores se apropriem da segurança e tenham a responsabilidade de corrigir problemas de segurança, especialmente se eles os criaram.

2. Depois de criar o processo que as equipes seguirão para revogar credenciais, reúna informações sobre os tipos de segredos e outros metadados associados aos segredos vazados para compreender a quem comunicar o novo processo.

   É possível usar a visão geral de segurança para coletar essas informações. Para obter mais informações sobre como usar a visão geral de segurança, confira Visão geral da filtragem de alertas na segurança.

   Algumas informações úteis para coletar incluem:

   • Organização

   • Repositório

   • Tipo de segredo

   • Valor do segredo

   • Responsáveis pela manutenção do repositório com os quais entrar em contato

   Note

   Use a IU se você tiver poucos segredos desse tipo vazados. Se você tiver centenas de segredos vazados, use a API para coletar informações. Para saber mais, confira Pontos de extremidade da API REST para verificação de segredos.

3. Depois de coletar informações sobre segredos vazados, crie um plano de comunicação direcionado para os usuários que mantêm os repositórios afetados por cada tipo de segredo. É possível usar email, mensagens ou até mesmo criar problemas do GitHub nos repositórios afetados. Se for possível usar as APIs fornecidas por essas ferramentas para enviar as comunicações de maneira automatizada, isso facilitará o escalonamento em vários tipos de segredo.

4. Expanda o programa para incluir mais tipos de segredos e padrões personalizados

Agora é possível expandir os cinco tipos de segredos mais críticos para uma lista mais abrangente, com foco adicional na educação. É possível repetir a etapa anterior, corrigindo os segredos anteriormente confirmados, para os diferentes tipos de segredo visados.

Também é possível incluir mais padrões personalizados coletados nas fases anteriores e convidar as equipes de segurança e desenvolvimento a enviar mais padrões, estabelecendo um processo para enviar novos padrões à medida que novos tipos de segredo são criados. Para saber mais, confira Definir padrões personalizados para a verificação de segredo.

À medida que você continua a criar seus processos de correção para outros tipos de segredo, comece a criar um material de treinamento proativo que possa ser compartilhado com todos os desenvolvedores do GitHub em sua organização. Até aqui, muito do foco tem sido reativo. É uma excelente ideia mudar o foco para ser proativo e incentivar os desenvolvedores a não enviar credenciais por push para o GitHub. Isso pode ser feito de várias maneiras, mas criar um pequeno documento explicando os riscos e os motivos seria um ótimo ponto de partida.