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 Expert 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.
Você precisa habilitar o GHAS em cada projeto piloto, habilitando o recurso para cada repositório ou para todos os repositórios em qualquer organização que participe do projeto. Para obter mais informações, confira "Gerenciando as configurações de segurança e análise do repositório" ou "Gerenciando as configurações de segurança e de análise da sua organização".
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 digitalização de segredos para cada projeto piloto, habilitando o recurso para cada repositório ou para todos os repositórios de qualquer organização que participe do projeto. Para obter mais informações, confira "Gerenciando as configurações de segurança e análise do repositório" ou "Gerenciando as configurações de segurança e de análise da sua organização".
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".