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 1: Alinhar a estratégia de distribuição e as metas".
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. Como parte da sua preparação, você trabalhará com suas equipes, usará a automação para coletar dados sobre seus repositórios e habilitará a code scanning.
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. Durante essa fase, concentre-se em aproveitar as APIs e executar eventos de habilitação internos.
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.
Coleta de informações sobre os repositórios
É possível coletar informações programaticamente sobre as diferentes linguagens de programação usadas nos repositórios e usar esses dados para habilitar o code scanning em todos os repositórios que usam a mesma linguagem por meio da API GraphQL do GitHub Enterprise Server.
Nota: é possível usar nossa ferramenta disponível publicamente para coletar esses dados sem executar manualmente as consultas GraphQL descritas neste artigo. Para saber mais, confira o repositório "ghas-enablement tool".
Para coletar informações de repositórios pertencentes a várias organizações em sua empresa, use a consulta abaixo a fim de obter os nomes das organizações e, em seguida, inclua-os na consulta de repositório. Substitua OCTO-ENTERPRISE pelo nome da sua empresa.
query {
enterprise(slug: "OCTO-ENTERPRISE") {
organizations(first: 100) {
totalCount
nodes {
name
}
pageInfo {
endCursor
hasNextPage
}
}
}
}
Para identificar quais repositórios usam quais linguagens, agrupe-os por linguagem no nível da organização. É possível modificar a consulta de exemplo do GraphQL abaixo, substituindo OCTO-ORG pelo nome da organização.
query {
organization(login: "OCTO-ORG") {
repositories(first: 100) {
totalCount
nodes {
nameWithOwner
languages(first: 100) {
totalCount
nodes {
name
}
}
}
pageInfo {
endCursor
hasNextPage
}
}
}
}
Para saber mais sobre como executar consultas do GraphQL, confira "Realizar chamadas com o GraphQL".
Em seguida, converta os dados da consulta do GraphQL em um formato legível, como uma tabela.
| Idioma | Número de repositórios | Nome dos repositórios |
|---|---|---|
| JavaScript (TypeScript) | 4212 | org/repo org/repo |
| Python | 2012 | org/repo org/repo |
| Go | 983 | org/repo org/repo |
| Java | 412 | org/repo org/repo |
| Swift | 111 | org/repo org/repo |
| Kotlin | 82 | org/repo org/repo |
| C | 12 | org/repo org/repo |
É possível filtrar na tabela as linguagens que não têm suporte atualmente no GitHub Advanced Security.
Se você tiver repositórios com várias linguagens, formate os resultados do GraphQL de acordo com a tabela abaixo. Filtre as linguagens sem suporte, mas mantenha todos os repositórios com pelo menos uma linguagem com suporte. Será possível habilitar o code scanning nesses repositórios e todas as linguagens com suporte serão examinadas.
| Linguagens | Número de repositórios | Nome dos repositórios |
|---|---|---|
| JavaScript/Python/Go | 16 | org/repo org/repo |
| Rust/TypeScript/Python | 12 | org/repo org/repo |
Ao compreender quais repositórios usam quais linguagens, é possível identificar aqueles que são candidatos para programas piloto na fase 3 e preparar-se para habilitar o code scanning em todos os repositórios, uma linguagem por vez, na fase 5.
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
Nota: Quando um segredo é detectado em um repositório que habilitou o secret scanning, o GitHub alerta todos os usuários com acesso a alertas de segurança para o repositório.
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 que contém o segredo. Para obter mais informações, confira "Sobre a verificação de segredo".
As
Considerações para a habilitação do secret scanning
a capacidade da secret scanning de GitHub Enterprise Server é ligeiramente diferente da code scanning, pois não requer nenhuma configuração específica por linguagem de programação ou por repositório e exige menos configuração geral para o início do uso. Isso significa que a habilitação da 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 "Configurar a verificação de segredo para seus repositórios". 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 digitalização de segredo".
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 digitalização de segredo".
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.
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 "Proteção por push para repositórios e organizações".
Para ver o próximo artigo desta série, confira "Fase 3: Programas piloto".