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:
- O gráfico de dependência está habilitado para o repositório. O gráfico de dependência é habilitado por padrão para repositórios públicos e você pode optar por habilitá-lo para repositórios privados. Para obter mais informações, consulte "Configurando o grafo de dependência".
- O GitHub Actions está habilitado no repositório. Para obter mais informações, confira "Gerenciando as configurações do GitHub Actions para um repositório".
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.
-
Em GitHub, acesse a página principal do repositório.
-
No nome do repositório, clique em Ações.
-
Em "Introdução a GitHub Actions", localize a categoria "Segurança" e clique em Exibir tudo.
-
Localize "Revisão de dependência" e clique em Configurar. Como alternativa, pesquise "Revisão de dependência" usando a barra de pesquisa.
-
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
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
.
-
Adicione a opção
fail-on-severity
ao final do arquivodependency-review.yml
:YAML - name: 'Dependency Review' uses: actions/dependency-review-action@v4 with: fail-on-severity: moderate
- 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.
-
Adicione a opção
deny-licenses
ao final do arquivodependency-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
- 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.
-
Adicione a opção
fail-on-scopes
ao final do arquivodependency-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
- 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:
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
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.