Este artigo faz parte de uma série sobre a adoção do GitHub Advanced Security em escala. Para ver o artigo anterior desta série, confira "Fase 2: Preparo para a habilitação em escala".
Sobre programas piloto
Recomendamos que você identifique algumas equipes e alguns projetos de alto impacto para usar em uma distribuição piloto do GHAS. Com isso, um grupo inicial se familiariza com o GHAS e cria uma base sólida nele antes da distribuição para o restante da empresa.
Essas etapas ajudam você a habilitar o GHAS em sua empresa, começar a usar as funcionalidades dele e revisar seus resultados. Se você estiver trabalhando com GitHub Professional Services, ele poderá fornecer assistência adicional por meio desse processo com sessões de integração, oficinas do GHAS e solução de problemas, conforme necessário.
Antes de iniciar os projetos piloto, recomendamos que você agende algumas reuniões para as equipes, como uma reunião inicial, uma revisão durante o processo e uma sessão de encerramento após a conclusão do piloto. Essas reuniões ajudarão você a fazer todos os ajustes, conforme necessário, e assegurarão que as equipes estejam preparadas e tenham o apoio necessário para concluir o piloto com sucesso.
Testar todos os recursos do GitHub Advanced Security
Você pode habilitar recursos de segurança em larga escala rapidamente com o GitHub-recommended security configuration, uma coleção de configurações de ativação de segurança que podem ser aplicadas 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".
Distribuição piloto do code scanning
Você pode definir rapidamente a configuração padrão para a code scanning em vários repositórios em uma organização usando uma visão geral de segurança. Para obter mais informações, confira "Como definir a configuração padrão da verificação de código em escala".
Você também pode escolher entre habilitar a code scanning para todos os repositórios em uma organização, mas recomendamos configurar a code scanning em um subconjunto de repositórios de forte impacto visual para seu programa piloto.
Para algumas linguagens ou sistemas de compilação, talvez seja necessário definir uma configuração avançada para a code scanning de modo a obter cobertura total da sua base de código. No entanto, a configuração avançada requer um esforço significativamente maior para configurar, personalizar e manter. Dessa forma, recomendamos habilitar a configuração padrão primeiro.
Se sua empresa quiser usar outras ferramentas para análise de código de terceiros com a GitHub code scanning, você poderá usar ações para executar essas ferramentas no GitHub. Como alternativa, é possível carregar os resultados, que são gerados por ferramentas de terceiros como arquivos SARIF, para a code scanning. Para obter mais informações, confira "Integrar com varredura de código".
Distribuição piloto do secret scanning
GitHub verifica repositórios em busca de tipos de segredos conhecidos, a fim de impedir o uso fraudulento de segredos que sofreram commit acidentalmente.
Você precisa habilitar o secret scanning e a proteção por push para cada projeto piloto. Você pode fazer isso com o GitHub-recommended security configuration ou pode criar uma custom security configuration. Para obter mais informações, confira "Aplicação da configuração de segurança recomendada pelo GitHub em sua organização" e "Criando uma configuração de segurança personalizada."
Se você planeja configurar um link para um recurso na mensagem exibida quando um desenvolvedor tenta efetuar push de um segredo bloqueado, agora seria um bom momento para testar e começar a refinar as diretrizes que você planeja disponibilizar.
Comece a revisar a atividade usando a página de métricas de proteção por push na visão geral de segurança. Para obter mais informações, confira "Exibir métricas para proteção por push para a verificação de segredos".
Se você tiver coletado padrões personalizados específicos para sua empresa, especialmente os relacionados aos projetos envolvidos na distribuição piloto do secret scanning, será possível configurá-los. Para obter mais informações, confira "Definir padrões personalizados para a verificação de segredo".
Para saber como exibir e fechar alertas de segredos com check-in no seu repositório, confira "Gerenciar alertas da verificação de segredo".
Para ver o próximo artigo desta série, confira "Fase 4: Criar a documentação interna".