Fase 2: Preparo para a habilitação em escala

Preparo para a habilitação do code scanning

A Code scanning é um recurso que você usa para analisar o código em um repositório GitHub para encontrar vulnerabilidades de segurança e erros de codificação. Os problemas que forem identificados pela análise serão mostrados em seu repositório. Para saber mais, confira "Sobre a varredura de código".

A distribuição do code scanning em centenas de repositórios pode ser complexa, especialmente quando feita de maneira ineficiente. Seguir essas etapas garantirá que sua distribuição seja eficiente e bem-sucedida.

Preparo das equipes para o code scanning

Primeiro, prepare suas equipes para usar o code scanning. Quanto mais equipes usarem a code scanning, mais dados você terá para conduzir planos de correção e monitorar o progresso da distribuição.

Para obter uma introdução à code scanning, confira:

• "Sobre a varredura de código"
• "Sobre alertas de digitalização de códigos"
• "Avaliar alertas de verificação de código para seu repositório"

Seu foco principal deve ser o preparo do maior número possível de equipes para o uso do code scanning. Também é possível incentivar as equipes a fazer as correções adequadas, mas recomendamos priorizar a habilitação e o uso do code scanning, em vez da correção de problemas, durante essa fase.

Habilitação do code scanning para o seu dispositivo

Antes de prosseguir com os programas piloto e com a distribuição do code scanning em toda a empresa, primeiro você precisa habilitar o code scanning para o seu dispositivo. Para obter mais informações, confira "Como configurar a verificação de código do seu dispositivo".

Preparo para a habilitação do secret scanning

Se um projeto se comunica com um serviço externo, ele pode usar um token ou uma chave privada para a autenticação. Se você marcar um segredo em um repositório, qualquer pessoa que tenha acesso de leitura ao repositório pode usar o segredo para acessar o serviço externo com seus privilégios. O Secret scanning examinará todo o histórico do Git em todos os branches presentes nos repositórios do GitHub em busca de segredos e alertará você ou bloqueará o envio por push contendo o segredo. Para obter mais informações, confira "Sobre a verificação de segredo".

Considerações para a habilitação do secret scanning

Habilitar secret scanning no nível organizacional pode ser fácil, mas clicar em Habilitar tudo no nível da organização e marcar a opção Habilitar a secret scanning automaticamente em cada novo repositório tem alguns efeitos subjacentes que devem ser considerados:

Consumo de licença

Habilitar secret scanning para todos os repositórios maximizará o uso de licenças de GitHub Advanced Security. Isso é bom se você tiver licenças suficientes para os committers atuais para todos esses repositórios. Se o número de desenvolvedores ativos aumentar nos próximos meses, você excederá o limite de licença e não conseguirá usar o GitHub Advanced Security em repositórios recém-criados.

Alto volume inicial de segredos detectados

Se você estiver habilitando o secret scanning em uma organização grande, encontrará um alto número de segredos. Às vezes, as organizações podem se chocar com isso e disparar os alarmes. Se você deseja ativar o secret scanning em todos os repositórios ao mesmo tempo, planeje sua resposta aos vários alertas que serão gerados em toda a organização.

O Secret scanning pode ser habilitado para repositórios individuais. Para obter mais informações, confira "Habilitando a varredura de segredos para seu repositório". O Secret scanning também pode ser habilitado para todos os repositórios em sua organização, conforme descrito acima. Para saber mais sobre como habilitar para todos os repositórios, confira "Gerenciando as configurações de segurança e de análise da sua organização".

Padrões personalizados para o secret scanning

O Secret scanning detecta um grande número de padrões predefinidos, mas também pode ser configurado para detectar padrões personalizados, como formatos de segredos exclusivos de sua infraestrutura ou usados por integradores que o secret scanning do GitHub Enterprise Server não detecta atualmente. Para saber mais sobre os segredos com suporte para os padrões dos parceiros, confira "Padrões de varredura de segredos com suporte".

Ao auditar os repositórios e falar com as equipes de segurança e de desenvolvimento, crie uma lista dos tipos de segredos que você usará posteriormente para configurar padrões personalizados para o secret scanning. Para obter mais informações, confira "Definir padrões personalizados para a verificação de segredo".

Proteção por push para secret scanning

A proteção por push para organizações e repositórios instrui secret scanning a verificar se há segredos com suporte antes que os segredos sejam confirmados na base de código. Para obter mais informações sobre quais segredos têm suporte, confira "Padrões de varredura de segredos com suporte".

Se um segredo for detectado em um push, esse push será bloqueado. A Secret scanning lista todos os segredos detectados para que o autor possa revisar os segredos e removê-los ou, se necessário, permitir que esses segredos sejam enviados por push. Secret scanning também podem verificar pushes em busca de padrões personalizados.

Os desenvolvedores têm a opção de ignorar a proteção por push relatando que um segredo é um falso positivo, que é usado em testes ou que será corrigido mais tarde.

Se um colaborador ignorar um bloco de proteção por push para um segredo, GitHub:

• criará um alerta na guia Segurança do repositório.
• adiciona o evento bypass ao log de auditoria.
• envia um alerta por email para proprietários da organização ou da conta pessoal, gerentes de segurança e administradores de repositório que estiverem inspecionando o repositório, com um link para o segredo e o motivo pelo qual ele foi permitido.

Antes de habilitar a proteção por push, considere se você precisa criar orientações para as equipes de desenvolvedores sobre as condições aceitáveis para ignorar a proteção por push. Você pode configurar um link para esse recurso na mensagem exibida quando um desenvolvedor tenta efetuar push em um segredo bloqueado.

Em seguida, familiarize-se com as diferentes opções para gerenciar e monitorar alertas que são o resultado de um colaborador ignorando a proteção por push.

Para obter mais informações, confira "Sobre a proteção por push".