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

Preparando-se para habilitar 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 obter mais informações, consulte [AUTOTITLE](/code-security/code-scanning/introduction-to-code-scanning/about-code-scanning).

A distribuição code scanning entre centenas de repositórios pode ser difícil, especialmente quando feita de forma ineficiente. Siga estas etapas para garantir uma distribuição eficiente e bem-sucedida.

Preparando equipes para code scanning

Primeiro, prepare suas equipes para usar code scanning. Quanto mais equipes usarem code scanning, mais dados você terá para desenvolver planos de correção e monitorar o progresso em sua implementação.

Para uma introdução a code scanning, veja: * Sobre a varredura de código * Sobre alertas de digitalização de códigos * Avaliar alertas de varredura de código para seu repositório

Seu foco principal deve estar preparando o maior número possível de equipes para usar code scanning . Você também pode incentivar as equipes a remediar de forma adequada, mas recomendamos priorizar a habilitação e o uso de code scanning durante essa fase, em vez de resolver problemas.

Habilitando code scanning para seu dispositivo

Antes de continuar com os programas piloto e distribuir code scanning em toda a empresa, primeiro você deve habilitar code scanning para seu dispositivo. Para saber mais, confira Como configurar a verificação de código do seu dispositivo.

Preparando-se para habilitar 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ê inserir 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. Secret scanning examinará todo o histórico do Git em todos os branches presentes em seus repositórios GitHub para buscar segredos e, ao encontrá-los, alertará você ou bloqueará o push que os contém. Para saber mais, confira Sobre a verificação de segredo.

Considerações ao habilitar 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 selecionar a opção Habilitar secret scanning automaticamente para cada novo repositório tem alguns efeitos downstream que você deve estar ciente:

Consumo de licença

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

Alto volume inicial de segredos detectados

Se você estiver habilitando secret scanning em uma organização grande, esteja preparado para ver um grande número de segredos encontrados. Às vezes, as organizações podem se chocar com isso e disparar os alarmes. Se você quiser ativar secret scanning em todos os repositórios ao mesmo tempo, planeje como irá responder a vários alertas em toda a organização.

          Secret scanning pode ser habilitado para repositórios individuais. Para saber mais, confira [AUTOTITLE](/code-security/secret-scanning/enabling-secret-scanning-features/enabling-secret-scanning-for-your-repository). 
          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 [AUTOTITLE](/organizations/keeping-your-organization-secure/managing-security-settings-for-your-organization/managing-security-and-analysis-settings-for-your-organization).

Padrões personalizados para secret scanning

          Secret scanning detecta um grande número de padrões padrão, mas também pode ser configurado para detectar padrões personalizados, como formatos secretos exclusivos para sua infraestrutura ou usados por integradores que GitHubnão secret scanning detectam no momento. Para saber mais sobre os segredos com suporte para padrões de parceiros, confira [AUTOTITLE](/code-security/secret-scanning/introduction/supported-secret-scanning-patterns).

Ao auditar seus repositórios e falar com as equipes de segurança e desenvolvedores, crie uma lista dos tipos secretos que você usará posteriormente para configurar padrões personalizados.secret scanning Para saber mais, 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 secret scanning instrui a verificar por push os 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, consulte Padrões de varredura de segredos com suporte.

Se uma informação confidencial for detectada em um push, esse push será bloqueado. Secret scanning lista todos os segredos detectados para que o autor possa examinar os segredos e removê-los ou, se necessário, permitir que esses segredos sejam enviados por push. Secret scanning também podem verificar pushes para detectar padrões personalizados.

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

Quando um colaborador ignora um bloco de proteção por push, GitHub:

• Cria um alerta na guia Segurança do repositório, da organização e da empresa
• Adiciona o evento de desvio ao registro de auditoria
• Envia um alerta de email para proprietários de conta pessoal, organização e empresas, gerentes de segurança e administradores de repositório que estão assistindo ao 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 enviar 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 saber mais, confira Sobre a proteção por push.

Próximas Etapas 

Para ver o próximo artigo desta série, confira Fase 3: Programas piloto.