{"meta":{"title":"Personalizando sua configuração de ação de revisão de dependência","intro":"Saiba como adicionar uma personalização básica à sua configuração de ação de revisão de dependência.","product":"Qualidade de segurança e código","breadcrumbs":[{"href":"/pt/code-security","title":"Qualidade de segurança e código"},{"href":"/pt/code-security/tutorials","title":"Tutorials"},{"href":"/pt/code-security/tutorials/secure-your-dependencies","title":"Proteger suas dependências"},{"href":"/pt/code-security/tutorials/secure-your-dependencies/customize-dependency-review-action","title":"Personalizar ação de revisão de dependência"}],"documentType":"article"},"body":"# Personalizando sua configuração de ação de revisão de dependência\n\nSaiba como adicionar uma personalização básica à sua configuração de ação de revisão de dependência.\n\n## Introduction\n\nO ação de revisão de dependência verifica seus pull requests em busca de alterações nas dependências e sinaliza um erro caso alguma nova dependência tenha vulnerabilidades conhecidas. Após a instalação, se a execução do fluxo de trabalho for marcada como necessária, a mesclagem das solicitações de pull que introduzem pacotes vulneráveis conhecidos será impedida.\n\nEste 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.\n\n### Pré-requisitos\n\nEste guia supõe que:\n\n* Verifique se o grafo de dependência está habilitado para o repositório. Para obter mais informações, consulte [Habilitar o grafo de dependência](/pt/code-security/how-tos/secure-your-supply-chain/secure-your-dependencies/enable-dependency-graph#enabling-the-dependency-graph-for-a-repository).\n* GitHub Actions está habilitado para o repositório. Para obter mais informações, consulte [Gerenciando configurações de GitHub Actions para um repositório](/pt/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository).\n\n## Etapa 1: Adicionando a ação de revisão de dependência\n\nNesta etapa, adicionaremos o fluxo de trabalho de revisão de dependência ao seu repositório.\n\n1. Em GitHub, acesse a página principal do repositório.\n2. No nome do repositório, clique em ** Actions**.\n\n ![Captura de tela das guias do repositório \"github/docs\". A guia \"Ações\" está realçada com um contorno laranja.](/assets/images/help/repository/actions-tab-global-nav-update.png)\n3. Em \"Comece a usar GitHub Actions\", localize a categoria \"Segurança\" e depois clique em **Ver tudo**.\n4. Encontre \"Revisão de dependência\" e clique em **Configurar**. Como alternativa, pesquise \"Revisão de dependência\" usando a barra de pesquisa.\n5. Isso abrirá o arquivo de fluxo de trabalho GitHub Actions da revisão de dependências, `dependency-review.yml`. Ele deve conter o seguinte:\n\n ```yaml copy\n name: 'Dependency review'\n on:\n pull_request:\n branches: [ \"main\" ]\n\n permissions:\n contents: read\n\n jobs:\n dependency-review:\n runs-on: ubuntu-latest\n steps:\n - name: 'Checkout repository'\n uses: actions/checkout@v6\n - name: 'Dependency Review'\n uses: actions/dependency-review-action@v4\n ```\n\n## Etapa 2: Alterando a gravidade\n\nVocê pode impedir que código contendo dependências vulneráveis seja mesclado, definindo ação de revisão de dependência como obrigatório. No entanto, vale a pena observar que o bloqueio de vulnerabilidades de baixo risco pode ser muito restritivo em algumas circunstâncias. Nessa etapa, vamos alterar a gravidade da vulnerabilidade que fará com que haja falha em um build com a opção `fail-on-severity`.\n\n1. Adicione a opção `fail-on-severity` ao final do arquivo `dependency-review.yml`:\n\n ```yaml copy\n - name: 'Dependency Review'\n uses: actions/dependency-review-action@v4\n with:\n fail-on-severity: moderate\n ```\n\n## Etapa 3: Adicionando licenças a serem bloqueadas\n\nAs vulnerabilidades não são o único motivo pelo qual você pode querer bloquear uma dependência. Se a sua organização tiver restrições sobre os tipos de licenças que podem ser usados, você poderá usar a revisão de dependência para impor essas políticas com a opção `deny-licenses`. Nesta etapa, vamos adicionar uma personalização que interromperá o build se a solicitação de pull introduzir uma dependência que contenha a licença LGPL-2.0 ou BSD-2-Clause.\n\n1. Adicione a opção `deny-licenses` ao final do arquivo `dependency-review.yml`:\n\n ```yaml copy\n - name: 'Dependency Review'\n uses: actions/dependency-review-action@v4\n with:\n fail-on-severity: moderate\n deny-licenses: LGPL-2.0, BSD-2-Clause\n ```\n\n## Etapa 4: Adicionando escopos\n\nPor fim, vamos usar 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.\n\n1. Adicione a opção `fail-on-scopes` ao final do arquivo `dependency-review.yml`:\n\n ```yaml copy\n - name: 'Dependency Review'\n uses: actions/dependency-review-action@v4\n with:\n fail-on-severity: moderate\n deny-licenses: LGPL-2.0, BSD-2-Clause\n fail-on-scopes: development\n ```\n\n## Etapa 5: Verificar a configuração\n\nO arquivo `dependency-review.yml` deve estar assim agora:\n\n```yaml copy\n\nname: 'Dependency Review'\non: [pull_request]\n\npermissions:\n contents: read\n\njobs:\n dependency-review:\n runs-on: ubuntu-latest\n steps:\n - name: 'Checkout Repository'\n uses: actions/checkout@v6\n - name: Dependency Review\n uses: actions/dependency-review-action@v4\n with:\n fail-on-severity: moderate\n deny-licenses: LGPL-2.0, BSD-2-Clause\n fail-on-scopes: development\n```\n\nVocê pode usar essa configuração como um modelo para suas próprias configurações personalizadas.\n\nPara obter mais informações sobre todas as opções de personalização possíveis, consulte o arquivo [LEIAME](https://github.com/actions/dependency-review-action/blob/main/README.md#configuration) na documentação da ação de revisão de dependência.\n\n## Práticas recomendadas\n\nAo personalizar sua configuração de revisão de dependência, há algumas melhores práticas que você pode seguir:\n\n* Escolha listas de bloqueio em vez de listas de permissões. É mais prático compilar uma lista das dependências \"muito ruins\" que você deseja bloquear do que criar uma lista inclusiva de todas as bibliotecas que deseja permitir.\n\n* Escolha bloquear licenças em vez de especificar quais licenças permitir. Há uma grande variedade de licenças disponíveis. 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.\n\n* Escolha `fail-on-severity`. Ter falha 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.\n\n## Leitura adicional\n\n* [Configurando a ação de revisão de dependências](/pt/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/configure-dependency-review-action)\n* [Como aplicar a revisão de dependências em uma organização](/pt/code-security/how-tos/secure-at-scale/configure-organization-security/configure-specific-tools/enforce-dependency-review)"}