Skip to main content

Esta versão do GitHub Enterprise Server foi descontinuada em 2024-09-25. Nenhum lançamento de patch será feito, mesmo para questões críticas de segurança. Para obter melhor desempenho, segurança aprimorada e novos recursos, atualize para a última versão do GitHub Enterprise Server. Para obter ajuda com a atualização, entre em contato com o suporte do GitHub Enterprise.

Personalizando sua configuração de ação de revisão de dependência

Saiba como adicionar uma personalização básica à sua configuração de ação de revisão de dependência.

Quem pode usar esse recurso?

Proprietários de repositórios, proprietários de organizações, gerentes de segurança e usuários com a função de administrador

Introdução

O ação de revisão de dependência verifica as solicitações de pull em busca de alterações de dependência e gera um erro quando novas dependências têm vulnerabilidades conhecidas. Após a instalação, se a execução do fluxo de trabalho for marcada como necessária, as pull requests que introduzem pacotes vulneráveis conhecidos serão impedidas de mesclar.

Este guia mostra como adicionar três personalizações muito comuns: builds com falha com base no nível de gravidade da vulnerabilidade, licença de dependência e escopo.

Pré-requisitos

Este guia supõe que:

Etapa 1: Adicionando a ação de revisão de dependência

Nesta etapa, adicionaremos o fluxo de trabalho de revisão de dependência ao seu repositório.

  1. Em GitHub, acesse a página principal do repositório.

  2. No nome do repositório, clique em Ações.

    Captura de tela das guias do repositório "github/docs". A guia "Ações" está realçada com um contorno laranja.

  3. Em "Introdução a GitHub Actions", localize a categoria "Segurança" e clique em Exibir tudo.

  4. Localize "Revisão de dependência" e clique em Configurar. Como alternativa, pesquise "Revisão de dependência" usando a barra de pesquisa.

  5. Isso abrirá o arquivo de fluxo de trabalho GitHub Actions da revisão de dependência, dependency-review.yml. Ele deve conter o seguinte:

    YAML
    name: 'Dependency review'
    on:
      pull_request:
        branches: [ "main" ]
    
    permissions:
      contents: read
    
    jobs:
      dependency-review:
        runs-on: ubuntu-latest
        steps:
          - name: 'Checkout repository'
            uses: actions/checkout@v4
          - name: 'Dependency Review'
            uses: actions/dependency-review-action@v4
    

Etapa 2: Alterando a gravidade

Você pode impedir que o código que contém dependências vulneráveis seja mesclado definindo ação de revisão de dependência como obrigatório. No entanto, vale a pena notar que o bloqueio de vulnerabilidades de baixo risco pode ser muito restritivo em algumas circunstâncias. Nessa etapa, alteraremos a gravidade da vulnerabilidade que fará com que uma compilação falhe com a opção fail-on-severity.

  1. Adicione a opção fail-on-severity ao final do arquivo dependency-review.yml:

    YAML
          - name: 'Dependency Review'
            uses: actions/dependency-review-action@v4
            with:
              fail-on-severity: moderate
    

Etapa 3: Adicionando licenças para bloquear

As vulnerabilidades não são o único motivo pelo qual você pode querer bloquear uma dependência. Se sua organização tiver restrições sobre os tipos de licenças que você pode usar, você poderá usar a revisão de dependência para impor essas políticas com a opção deny-licenses. Nesta etapa, adicionaremos uma personalização que interromperá a compilação se a solicitação de pull introduzir uma dependência que contenha a licença LGPL-2.0 ou BSD-2-Clause.

  1. Adicione a opção deny-licenses ao final do arquivo dependency-review.yml:

    YAML
          - name: 'Dependency Review'
            uses: actions/dependency-review-action@v4
            with:
              fail-on-severity: moderate
              deny-licenses: LGPL-2.0, BSD-2-Clause
    

Etapa 4: Adicionando escopos

Por fim, usaremos a opção fail-on-scopes para impedir a mesclagem de dependências vulneráveis em ambientes de implantação específicos, neste caso, o ambiente de desenvolvimento.

  1. Adicione a opção fail-on-scopes ao final do arquivo dependency-review.yml:

    YAML
          - name: 'Dependency Review'
            uses: actions/dependency-review-action@v4
            with:
              fail-on-severity: moderate
              deny-licenses: LGPL-2.0, BSD-2-Clause
              fail-on-scopes: development
    

Etapa 5: Verificação da configuração

O arquivo dependency-review.yml deve estar assim agora:

YAML

name: 'Dependency Review'
on: [pull_request]


permissions:
  contents: read


jobs:
  dependency-review:
    runs-on: ubuntu-latest
    steps:
      - name: 'Checkout Repository'
        uses: actions/checkout@v4
      - name: Dependency Review
        uses: actions/dependency-review-action@v4
        with:
          fail-on-severity: moderate
          deny-licenses: LGPL-2.0, BSD-2-Clause
          fail-on-scopes: development

Você pode usar essa configuração como um modelo para suas próprias configurações personalizadas.

Para obter mais informações sobre todas as opções de personalização possíveis, consulte o arquivo LEIAME na documentação da ação de revisão de dependência.

Práticas recomendadas

Ao personalizar sua configuração de revisão de dependência, há algumas práticas recomendadas que você pode seguir:

  • Escolha listas de bloqueio em vez de listas de permissões. É mais prático compilar uma lista das dependências "realmente ruins" que você deseja bloquear do que criar uma lista inclusiva de todas as bibliotecas que deseja permitir.

  • Escolha bloquear licenças em vez de especificar quais licenças permitir. Há uma grande variedade de licenças disponíveis por aí. Por isso, geralmente é mais prático excluir aquelas que você sabe que são incompatíveis com as licenças atuais do que compilar uma lista completa de licenças compatíveis.

  • Escolha fail-on-severity. Falhar com base na gravidade de uma vulnerabilidade é uma boa maneira de equilibrar a necessidade de segurança com a necessidade de criar experiências de baixo atrito para os desenvolvedores.

Leitura adicional