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 3: Programas piloto".
Antes de habilitar o GitHub Advanced Security, você precisa criar uma documentação interna que defina os processos a serem seguidos pelas equipes. Todos precisam saber o que fazer quando recebem um alerta de segurança, mesmo que o processo simplesmente peça � equipe para aplicar seu melhor julgamento. A documentação também impedirá que os desenvolvedores sejam bloqueados quando tiverem dúvidas. Coloque a documentação sobre o GHAS no mesmo local da documentação existente focada no desenvolvedor, como o portal do desenvolvedor ou uma base de dados de conhecimento personalizada.
Se você tiver executado programas piloto, use as experiências e os comentários das equipes envolvidas ao elaborar sua documentação. Isso é especialmente útil quando você encontra problemas específicos para sua empresa, que outras equipes também podem vir a ter.
Se você ignorar a criação da documentação interna, sua distribuição não ocorrerá no ritmo pretendido. A criação da documentação interna pode atrasar a distribuição inicial em uma ou duas semanas, mas esse tempo será compensado quando os desenvolvedores puderem responder � s próprias perguntas em vez de procurar sua equipe.
A educação é provavelmente a parte mais importante da distribuição, pois ensina aos desenvolvedores o que fazer em diferentes situações. É preciso garantir que os desenvolvedores possam manter a segurança do repositório e que a equipe de segurança esteja autorizada a verificar o que eles estão fazendo e se a ação é realmente o melhor para a segurança. Além da documentação interna, a educação pode assumir a forma de sessões online, sessões de perguntas e respostas etc.
Para ver o próximo artigo desta série, confira "Fase 5: Distribuição e exame de códigos em escala".