Skip to main content

Práticas recomendadas para proteger o código na sua cadeia de suprimentos

Orientação sobre como proteger o centro de sua cadeia de suprimentos — o código que você escreve e o código de que você depende.

Sobre este guia

Este guia descreve mudanças de maior impacto que você pode fazer para melhorar a segurança do seu código. Cada seção descreve uma alteração que você pode fazer em seus processos para melhorar a segurança. As mudanças de maior impacto estão listadas primeiro.

Qual o risco?

Os principais riscos no processo de desenvolvimento incluem:

  • Usar dependências com vulnerabilidades de segurança que um invasor pode explorar.
  • Vazar as credenciais de autenticação ou um token que um invsor poderia usar para acessar seus recursos.
  • Introduzir uma vulnerabilidade ao seu próprio código que um invasor poderia explorar.

Esses riscos abrem seus recursos e projetos para serem atacados, aléme de serem enviados diretamente para qualquer um que utilize um pacote que você criar. As seções a seguir explicam como você pode proteger você mesmo e seus usuários desses riscos.

Crie um programa de gerenciamento de vulnerabilidades para dependências

Você pode proteger o código do qual você depende criando um programa de gerenciamento de vulnerabilidades para dependências. Em alto nível, isto deve incluir processos para garantir que você:

  1. Crie um inventário de suas dependências.

  2. Saiba quando há uma vulnerabilidade de segurança em uma dependência.

  3. Impor revisões de dependência em suas solicitações de pull.

  4. Avalie o impacto dessa vulnerabilidade no seu código e decida qual ação tomar.

Geração de inventário automática

Como primeiro passo, você deverá fazer um inventário completo das suas dependências. O gráfico de dependências para um repositório mostra dependências para ecossistemas compatíveis. Se você verificar suas dependências, ou usar outros ecossistemas, você deverá completar isto com dados de ferramentas de terceiros ou listando dependências manualmente. Se você tiver pelo menos acesso de leitura ao repositório, poderá exportar o grafo de dependência para o repositório como uma SBOM (conta de materiais de software) compatível com SPDX, por meio da GitHub interface do usuário ou da API REST do GitHub. Para obter mais informações, confira "Como exportar uma lista de materiais de software para seu repositório".

Detecção automática de vulnerabilidades em dependências

Dependabot pode ajudar você a monitorar as suas dependências e notificar você quando contiverem uma vulnerabilidade conhecida. Você pode até mesmo habilitar o Dependabot para gerar automaticamente solicitações pull que atualizam a dependência para uma versão segura. Para obter mais informações, confira "Sobre alertas do Dependabot" e "Sobre as atualizações de segurança do Dependabot".

Detecção automática de vulnerabilidades em solicitações de pull

O ação de revisão de dependência impõe uma revisão de dependência nas suas solicitações de pull, facilitando que você veja se uma solicitação de pull introduzirá uma versão vulnerável de uma dependência no repositório. Quando uma vulnerabilidade é detectada, o ação de revisão de dependência pode bloquear a mesclagem da solicitação de pull. Para obter mais informações, confira "Sobre a análise de dependência".

Avaliação da exposição ao risco de uma dependência vulnerável

Ao descobrir que você está usando uma dependência vulnerável, por exemplo, uma biblioteca ou uma estrutura, você deve avaliar o nível de exposição do seu projeto e determinar que ação deve tomar. Normalmente, as vulnerabilidades são relatadas com uma pontuação de gravidade para mostrar a gravidade do seu impacto. A pontuação de gravidade é um guia útil, mas não pode dizer o impacto total da vulnerabilidade no seu código.

Para avaliar o impacto de uma vulnerabilidade no seu código, você também precisa considerar como usar a biblioteca e determinar o nível de risco que isso realmente representa para o seu sistema. Talvez a vulnerabilidade seja parte de um recurso que você não usa, e você pode atualizar a biblioteca afetada e continuar com o seu ciclo normal da versão. Ou talvez seu código esteja mal exposto a riscos e você precisa atualizar a biblioteca afetada e enviar uma construção atualizada imediatamente. Essa decisão depende de como você está usando a biblioteca em seu sistema, e é uma decisão que só você tem o conhecimento para tomar.

Proteja seus tokens de comunicação

O código geralmente precisa se comunicar com outros sistemas por meio de uma rede e exige segredos (como uma senha, ou uma chave de API) para efetuar a autenticação. Seu sistema precisa de acesso a esses segredos para ser executado, mas a prática recomendada é não incluí-los no seu código-fonte. Isso é especialmente importante para repositórios aos quais muitas pessoas podem ter acesso e crítico para repositórios públicos.

Detecção automática de segredos confirmados em um repositório

Note

O Secret scanning está disponível para os seguintes repositórios:

  • Repositórios públicos (grátis)

  • Repositórios privados e internos em organizações que usam o GitHub Enterprise Cloud com GitHub Advanced Security habilitado

  • Repositórios pertencentes ao usuário para GitHub Enterprise Cloud com Enterprise Managed Users

O GitHub faz parcerias com muitos provedores para detectar automaticamente quando o commit dos segredos é feito ou quando esses segredos são armazenados em seus repositórios públicos e pacotes npm públicos de que você depende, e notificará o provedor para que ele possa tomar as medidas apropriadas para garantir que sua conta permaneça segura. Para obter mais informações, confira "Sobre alertas secretos de verificação".

Se a sua organização usar o GitHub Advanced Security, você poderá habilitar os alertas de verificação de segredo para usuários em qualquer repositório pertencente à organização, incluindo repositórios privados. Além disso, os alertas de verificação de segredo para usuários estão disponível(is) e em versão prévia pública em repositórios de propriedade do usuário para o GitHub Enterprise Cloud com Enterprise Managed Users.

Você também pode definir padrões personalizados para detectar segredos adicionais no repositório, organização ou empresa. Para obter mais informações, confira "Sobre alertas secretos de verificação".

Armazenamento seguro de segredos que você usa em GitHub Enterprise Cloud

Além do código, você provavelmente precisa usar segredos em outros locais. Por exemplo, para permitir que os fluxos de trabalho do GitHub Actions, o Dependabot ou o ambiente de desenvolvimento dos GitHub Codespaces se comunique com outros sistemas. Para obter mais informações sobre como armazenar e usar segredos com segurança, confira "Usar segredos em ações do GitHub", "Configurando o acesso a registros privados para Dependabot" e "Gerenciando segredos específicos da sua conta para o GitHub Codespaces".

Mantenha padrões de codificação vulneráveis fora do seu repositório

Note

O Code scanning está disponível para os seguintes tipos de repositório:

  • Repositórios públicos no GitHub.com

  • Repositórios de propriedade da organização em GitHub Enterprise Cloud com GitHub Advanced Security habilitado

Criar um processo de revisão de pull request

Você pode melhorar a qualidade e a segurança do seu código garantindo que todos os pull requests sejam revisados e testados antes do merge. GitHub tem muitas funcionalidades que você pode usar para controlar a revisão e o processo de merge. Para começar, confira "Sobre branches protegidos".

Digitalize o seu código para padrões vulneráveis

Os padrões de código inseguro são muitas vezes difíceis para os revisores identificarem sem ajuda. Além de digitalizar seu código para encontrar segredos, você pode verificar se há padrões associados a vulnerabilidades de segurança. Por exemplo, uma função que não é segura na memória, ou falhar ao escapar de entrada do usuário que poderia levar a uma vulnerabilidade de injeção. GitHub oferece várias maneiras diferentes de abordar como e quando você digitaliza o seu código. Para começar, confira "Sobre a varredura de código".

Próximas etapas