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

É possível habilitar o exame de segredos para repositórios individuais ou para todos os repositórios em uma organização. Para saber mais, confira "Como gerenciar as configurações de segurança e de análise do repositório" ou "Como gerenciar as configurações de segurança e de análise da organização".

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 "Conteúdo e eventos do 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.

   Nota: é possível 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 o 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. Corrija os segredos confirmados, começando pelos mais críticos

Depois de estabelecer um processo para monitorar, notificar e corrigir os segredos recém-publicados, comece a trabalhar nos segredos confirmados antes da introdução do 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.

   Nota: 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 saber como usar a visão geral de segurança, confira "Filtrando alertas na visão geral de 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

   Nota: 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 "API REST de exame 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.

3. 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 obter mais informações, confira "Como definir padrões personalizados para a verificação de segredos".

À 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.