Configurar a verificação de dependências

A verificação de dependência no GitHub Advanced Security for Azure DevOps deteta os componentes de código aberto usados em seu código-fonte e deteta se há alguma vulnerabilidade associada. Qualquer vulnerabilidade encontrada de componentes de código aberto é sinalizada como um alerta. Você precisará do GitHub Advanced Security for Azure DevOps ou, se estiver usando a experiência autônoma, do GitHub Code Security for Azure DevOps habilitado.

O GitHub Advanced Security for Azure DevOps funciona com o Repositórios do Azure. Para usar a Segurança Avançada do GitHub com repositórios do GitHub, consulte Segurança Avançada do GitHub.

Pré-requisitos

Categoria Requerimentos
Permissões - Para visualizar um resumo de todos os alertas para um repositório: Colaborador permissões para o repositório.
- Para descartar alertas em Segurança Avançada: permissões de administrador do projeto.
- Para gerir permissões em Segurança Avançada: Membro do grupo Administradores de Coleção de Projetos ou Segurança Avançada: gerir configurações permissões definidas como Permitir.
Tarefas da cadeia de processamento - Em Definições da organização>Definições>>, certifique-se de que Desativar tarefas do Marketplace está desativado. A digitalização de código e a análise de dependências dependem de tarefas do Azure Pipelines distribuídas através do Visual Studio Marketplace. Se desativares as tarefas do Marketplace, a configuração predefinida não consegue executar análises e os pipelines de configuração avançada podem indicar que falta uma tarefa. Para mais informações, consulte Gestão de tarefas.

Para obter mais informações sobre permissões de Segurança Avançada, consulte Gerenciar permissões de Segurança Avançada.

Sobre a verificação de dependências

A verificação de dependência gera um alerta para qualquer componente de código aberto, direto ou transitivo, considerado vulnerável do qual seu código depende. As vulnerabilidades diretas são as bibliotecas que seu código usa diretamente. Dependências transitivas são as bibliotecas ou outros softwares que as dependências diretas usam.

Saiba mais sobre a deteção de dependências

Um novo instantâneo de seus componentes é armazenado sempre que o gráfico de dependência de um repositório é alterado e depois que um pipeline que contém a tarefa de verificação de dependência é executado.

Para cada componente vulnerável detetado em uso, o componente e a vulnerabilidade são listados no log de compilação e exibidos como um alerta na guia Segurança Avançada. Somente os avisos revisados pelo GitHub e adicionados ao Banco de Dados de Avisos do GitHub criam um alerta de verificação de dependência. O registo de compilação inclui um link para o alerta individual para investigação mais aprofundada. Para obter mais informações sobre os detalhes do alerta, consulte Corrigindo alertas de verificação de dependência.

O log de compilação também contém informações básicas sobre cada vulnerabilidade detetada. Esses detalhes incluem a gravidade, o componente afetado, o título da vulnerabilidade e a CVE associada.

Captura de ecrã da saída de compilação de uma análise de dependências.

Note

A varredura de dependências requer executar um pipeline configurado com a AdvancedSecurity-Dependency-Scanning@1 tarefa ou executar um pipeline num repositório com a configuração padrão de varredura de dependências ativada. Ativar Segurança Avançada ou Segurança de Código não executa automaticamente a varredura de dependências.

Para obter uma lista de ecossistemas e versões de componentes suportados, consulte Ecossistemas de pacotes suportados.

Saiba mais sobre alertas de verificação de dependência

A guia Segurança Avançada em Repos no Azure DevOps é o hub para exibir os alertas de segurança, que, por padrão, mostra alertas de análise de dependências. Pode filtrar por ramo, pipeline, pacotagem, gravidade, âmbito de dependência e percentil do Sistema de Previsão de Explorações (EPSS). Você pode selecionar um alerta para obter mais detalhes, incluindo orientação de correção. No momento, o hub de alertas não exibe alertas para análises concluídas em ramificações de PR.

Quando um pacote vulnerável é detetado em seu repositório, a correção de alertas de verificação de dependência geralmente envolve a atualização para uma versão superior do pacote ou a remoção de um pacote ofensivo. Este conselho é válido tanto para dependências diretas como transitivas (ou indiretas). A visualização padrão no separador Segurança Avançada mostra os alertas ativos para a ramificação padrão do seu repositório.

Não há impacto nos resultados se os fluxos de trabalho ou as ramificações forem renomeados - pode demorar até 24 horas para que o novo nome seja exibido.

Captura de ecrã da página de alertas de varredura de dependências com os filtros percentuais Scope e EPSS.

Priorizar alertas por âmbito de dependência

O âmbito de dependência indica se uma dependência vulnerável é usada em tempo de execução ou apenas durante o desenvolvimento. Na página Alertas, utilize o filtro de seleção única Âmbito para mostrar alertas de dependências de tempo de execução ou de desenvolvimento.

As dependências só de desenvolvimento apresentam o distintivo Development na lista de alertas. Os detalhes de alerta também mostram o âmbito da dependência quando o resultado da varredura inclui estes metadados. Se os metadados do âmbito não estiverem disponíveis, o Advanced Security omite o emblema e o detalhe do âmbito sem alterar qualquer outro comportamento do alerta.

O âmbito aplica-se ao resultado específico da dependência, não ao pacote globalmente. O mesmo pacote pode ter um âmbito diferente quando é detetado noutro caminho de dependência ou projeto.

Priorize alertas com EPSS

O Exploit Prediction Scoring System (EPSS) estima a probabilidade de uma vulnerabilidade de software ser explorada no mundo real. O EPSS fornece uma pontuação e um percentil; o Advanced Security apresenta o percentil para alertas de análise de dependências. Um percentil mais elevado indica que a vulnerabilidade tem uma classificação superior em relação à probabilidade prevista de exploração em relação a outras vulnerabilidades pontuadas.

Utilize o percentil do EPSS juntamente com a gravidade ao priorizar a remediação. A gravidade reflete o impacto potencial de uma vulnerabilidade, enquanto o EPSS ajuda a avaliar a probabilidade de exploração. Na página de Alertas , use o filtro percentil EPSS para especificar um intervalo percentil e foque-se nos alertas de dependência que cumpram esse intervalo. Os limites do alcance são inclusivos e combinam-se com quaisquer outros filtros que aplique.

O filtro percentil EPSS agrupa as vulnerabilidades nas seguintes categorias:

Percentil do EPSS Categoria
90-100% Muito alto
70-90% Alto
50-70% Médio
0-50% Baixo

Os dados do EPSS não estão disponíveis para todas as consultas. Quando um alerta não tem metadados EPSS, a Segurança Avançada não mostra o percentil do EPSS nos detalhes do alerta. Os metadados em falta não afetam a gravidade, o estado ou as orientações de remediação do alerta.

O estado de um alerta é atualizado automaticamente para Closed quando o componente vulnerável não é mais detetado na compilação mais recente para todos os pipelines onde a tarefa de verificação de dependência está instalada. Para visualizar os alertas resolvidos, utilize o State filtro na barra de ferramentas principal e selecione Closed.

Captura de ecrã de visualização de alertas de varredura de dependências fechadas.

Se você desativar a Segurança Avançada para seu repositório, perderá o acesso aos resultados na guia Segurança Avançada e na tarefa de compilação. A tarefa de compilação não falha, mas todos os resultados das compilações executadas com a tarefa enquanto a Segurança Avançada está desativada ficam ocultos e não são mantidos.

Detalhes do alerta

Você também pode detalhar detalhes sobre um alerta clicando em um alerta específico e em orientações de correção.

Captura de ecrã da informação sobre o percentil de ameaça do EPSS num alerta de análise de dependências.

Secção Explicação
Scope O âmbito indica se a dependência vulnerável é usada em tempo de execução ou apenas durante o desenvolvimento. Esta informação só aparece quando os metadados do âmbito da dependência estão disponíveis para o resultado.
Percentil do EPSS O percentil do EPSS indica como a vulnerabilidade se posiciona para a probabilidade prevista de exploração em relação a outras vulnerabilidades pontuadas. Esta linha aparece apenas quando os metadados EPSS estão disponíveis para o aviso.
Recomendação O texto da recomendação vem diretamente do nosso provedor de dados de vulnerabilidade, o GitHub Advisory Database. Normalmente, as orientações sugerem a atualização do componente identificado para uma versão não vulnerável.
Localização A seção Locais detalha os caminhos onde a tarefa de verificação de dependência descobre o componente vulnerável em uso. Se o ficheiro puder ser resolvido a partir da análise de construção subjacente para um ficheiro comprometido na origem, o cartão de Localizações aparecerá como um link clicável. Se um arquivo foi produzido como parte de uma compilação (por exemplo, um artefato de compilação), o link não é clicável. Revise os logs de compilação para entender melhor como o componente foi trazido para a compilação.
Descrição A descrição é fornecida pelo comunicado do GitHub Advisory.

Deteções

Os pipelines listados na aba Deteções são aqueles onde o componente vulnerável foi encontrado. Cada linha detalha a compilação mais recente do pipeline afetado e a data em que o pacote foi introduzido pela primeira vez. Se o pacote vulnerável for corrigido em alguns pipelines, mas não em todos, verás linhas parcialmente corrigidas.

Captura de ecrã da vista de deteção de varredura de dependências para um alerta sem correção.

Depois que um alerta é resolvido, o alerta é movido automaticamente para o Closed estado e o pipeline de execução mais recente na guia Deteções exibe uma marca de seleção verde, o que significa que o código que contém o componente atualizado foi executado nesse pipeline:

Captura de ecrã da visualização das deteções da análise de dependências para um alerta.

Gravidade

O GitHub Advisory Database fornece uma pontuação CVSS, que é então traduzida em uma gravidade baixa, média, alta ou crítica para um alerta por meio das seguintes diretrizes:

Pontuação CVSS Gravidade
1.0 < Pontuação < 4.0 Baixo
4.0 < Pontuação < 7.0 Médio
7.0 < Pontuação < 9.0 Alto
Pontuação >= 9,0 Crítico

Encontrar detalhes

Duas seções são comumente encontradas em Detalhes da Pesquisa: o pacote vulnerável e a dependência raiz. O pacote vulnerável é o componente potencialmente vulnerável. A seção de dependência raiz contém componentes de nível superior que são responsáveis pela cadeia de dependência que leva a uma vulnerabilidade.

Se o pacote vulnerável for referenciado apenas como uma dependência direta, você verá apenas a seção "pacote vulnerável".

Se o pacote vulnerável for referenciado como uma dependência direta e transitiva, o pacote será mostrado na seção "pacote vulnerável" e "dependência raiz".

Se o pacote vulnerável for referenciado apenas como uma dependência transitiva, o pacote será mostrado na seção "pacote vulnerável" e as dependências raiz que fazem referência ao pacote vulnerável serão mostradas na seção "dependência raiz".

Gerir alertas de varredura de dependências

Visualizando alertas para um repositório

Por padrão, a página de alertas mostra os resultados da verificação de dependência para a ramificação padrão do repositório.

O status de um alerta reflete o estado da ramificação padrão e do pipeline de execução mais recente, mesmo que o alerta exista em outras ramificações e pipelines.

Limpeza automática de alertas de configurações de pipelines obsoletas

A limpeza automática esconde os resultados antigos de análise quando as configurações do pipeline deixam de ser executadas. Não esconde um alerta simplesmente porque o alerta ou o seu ramo existe há mais de 90 dias. Este comportamento aplica-se a alertas de varredura de código e varredura de dependências.

O que torna uma configuração obsoleta?

A limpeza utiliza o tempo de conclusão mais recente da fase do pipeline associada a uma configuração de varrimento. Uma fase torna-se desatualizada quando esse tempo de conclusão foi há mais de 90 dias, por defeito.

A Segurança Avançada marca o registo de fase do pipeline como inativo, mas mantém os seus resultados. Depois, a vista de alerta esconde um alerta apenas quando todos os resultados mais recentes associados a esse alerta provêm de configurações obsoletas. Se algum desses resultados vier de uma configuração ativa, o alerta pode ainda aparecer.

Data ou atividade Utilizado para a limpeza de 90 dias?
Quando o alerta foi detetado pela primeira vez No
Quando o alerta foi detetado pela última vez No
Quando a ramificação foi escaneada pela última vez Não de forma independente. A limpeza acompanha a fase associada do pipeline, que pode ser partilhada entre ramificações.
O tempo de conclusão mais recente da fase associada do pipeline Yes

Porque é que uma deteção de ramificação antiga pode permanecer visível ou reaparecer?

Ramificações diferentes podem partilhar o mesmo registo de atividade de fase do pipeline. Quando essa fase é executada novamente noutra ramificação, a Segurança Avançada atualiza o seu tempo de conclusão e reativa as configurações associadas. Como resultado, deteções mais antigas numa ramificação que não foi executada recentemente podem permanecer visíveis ou reaparecer.

Por exemplo, considere esta sequência:

  1. Uma fase de pipeline deteta uma vulnerabilidade em develop.
  2. Essa fase não é executada em nenhuma ramificação por mais de 90 dias. Depois de a limpeza o marcar como inativo, a Segurança Avançada esconde o alerta se não houver resultados mais recentes de outras configurações ativas.
  3. A mesma fase é executada em feature/update-build. O Advanced Security reativa as suas configurações associadas, para que a deteção mais antiga develop possa voltar a aparecer.

A execução feature/update-build não analisa develop. Altera o estado de atividade da fase do pipeline partilhado, que controla se a Advanced Security mostra o resultado mais antigo.

Por esta razão, pode aparecer um alerta com uma data antiga da primeira ou da última vez que foi visto. Essas datas descrevem a deteção na ramificação, não o estado de atividade da fase do pipeline. Reativar a configuração não torna o resultado antigo numa nova deteção nem exige que a sua data original em que foi visto pela primeira vez mude.

O que deves verificar?

Quando uma deteção antiga permanece visível, reveja as execuções da mesma fase do pipeline entre ramificações, não apenas a ramificação mostrada no alerta. Para verificar se a vulnerabilidade ainda existe nessa ramificação, execute uma análise nessa ramificação.

Importante

A limpeza automática esconde resultados. Não corrige a vulnerabilidade nem descarta o alerta. Se a configuração associada voltar a estar ativa, alertas abertos anteriormente ocultos podem regressar como alertas abertos.

Corrigindo alertas de análise de dependência

Uma dependência direta é um componente que você tem em seu repositório. Uma dependência transitiva ou indireta é um componente que é usado por uma dependência direta. Seu projeto ainda está vulnerável, independentemente de a vulnerabilidade ser encontrada em uma dependência direta ou transitiva.

Corrigir uma dependência transitiva vulnerável geralmente assume a forma de sobrescrever explicitamente a versão do componente vulnerável utilizada em cada dependência direta identificada. Depois que as dependências raiz atualizarem seu uso do componente vulnerável para uma versão segura, você poderá atualizar cada dependência raiz em vez de várias substituições individuais.

Atualizar dependências do Yarn/Npm

Hipoteticamente, digamos que este pacote tem duas vulnerabilidades. Um é para axios, uma dependência direta, e um é para acorn, uma dependência transitiva (também conhecida como dependência indireta ou dependência de dependência).

{
 "name": "my-package",
 "version": "1.0.0",
 "dependencies": {
   "axios": "0.18.0",
   "eslint": "5.16.0",
 }
}

A versão atual do axios tem uma vulnerabilidade de negação de serviço (DoS) com uma recomendação de atualização para v0.18.1 ou superior. Por ser uma dependência direta, tens controlo sobre a versão de axios que utilizas; tudo o que precisas de fazer é atualizar a versão de axios que importas. O atualizado package.json é semelhante a:

{
  "name": "my-package",
  "version": "1.0.0",
  "dependencies": {
    "axios": "0.19.2",
    "eslint": "5.16.0",
  }
}

Agora, a versão do eslint mostrada no package.json depende de uma versão do acorn que possui uma vulnerabilidade de negação de serviço por expressão regular, "Re-DoS", com a recomendação de atualizar para a versão 5.7.4, 6.4.1, 7.1.1 ou superior. Se receberes um alerta da ferramenta de análise de dependências, ele deverá informar a dependência raiz que requer a dependência vulnerável.

Fios

Se você estiver usando o Yarn, poderá usar o yarn why para encontrar a cadeia de dependência completa.

> $ yarn why acorn
 yarn why v1.22.4
 [1/4] Why do we have the module "acorn"...?
 [2/4] Initialising dependency graph...
 [3/4] Finding dependency...
 [4/4] Calculating file sizes...
 => Found "acorn@6.4.0"
 info Reasons this module exists
   - "eslint#espree" depends on it
   - Hoisted from "eslint#espree#acorn"
 info Disk size without dependencies: "1.09MB"
 info Disk size with unique dependencies: "1.09MB"
 info Disk size with transitive dependencies: "1.09MB"
 info Number of shared dependencies: 0
 Done in 0.30s.

A cadeia de dependência completa é eslint>espree>acorn. Depois de conhecer a cadeia de dependência, pode usar outra funcionalidade do Yarn, que são as "resoluções seletivas de dependências", para substituir a versão de acorn que está a ser utilizada.

Use o campo de resoluções em package.json para definir uma substituição de versão. Três métodos diferentes para substituir um pacote são mostrados, em ordem do pior para o melhor:

{
  "name": "yarn-resolutions",
  "version": "1.0.0",
  "license": "MIT",
  "dependencies": {
    "axios": "0.19.2",
    "eslint": "5.16.0"
  },
  "resolutions": {
    // DO NOT USE!
    "**/acorn": "6.4.1",
    // BETTER
    "eslint/**/acorn": "6.4.1",
    // BEST
    "eslint/espree/acorn": "6.4.1"
  }
}

O uso do**/acorn padrão substitui todas as utilizações do pacote acorn em todas as dependências. É perigoso e quebra em tempo de execução, por isso o removemos no Yarn v2.

O uso do padrão eslint/**/acorn substitui todas as utilizações do pacote acorn dentro do pacote eslint e de quaisquer pacotes dos quais ele dependa. É mais seguro do que sobrepor o pacote para todas as dependências, mas ainda pode apresentar alguns riscos se o grafo de dependências de um pacote for grande. Esse padrão é recomendado quando há muitos subpacotes que usam um pacote vulnerável e definir substituições para subpacotes individuais seria impraticável.

O uso do padrão eslint/espree/acorn substitui apenas o uso de acorn do pacote espree dentro do pacote eslint. Ele visa especificamente a cadeia de dependência vulnerável e é a maneira recomendada de substituir versões de pacote.

npm

Se estiver a usar o npm 8.3 ou superior, pode usar o campo overrides no seu package.json

Adicione uma substituição se precisar fazer alterações específicas nas dependências transitivas. Por exemplo, pode ser necessário substituir a versão de uma dependência devido a um problema de segurança conhecido, substituir uma dependência existente por uma bifurcação ou garantir que a mesma versão de um pacote seja usada em todos os locais.

{
  "name": "npm-overrides",
  "version": "1.0.0",
  "license": "MIT",
  "dependencies": {
    "axios": "0.19.2",
    "eslint": "5.16.0"
  },
   "overrides":{
       "eslint": {
        "espree": {
          "acorn": "6.4.1"
        }
    }
   }
}

O exemplo de substituição mostrado demonstra o modo como o npm indica "sobrepor apenas o uso de acorn no pacote espree no pacote eslint". Isto destina-se especificamente à cadeia de dependências vulnerável e é a maneira recomendada de sobrepor versões de pacotes. As substituições são uma característica nativa do npm. Ele fornece uma maneira de substituir um pacote em sua árvore de dependência por outra versão ou outro pacote inteiramente.

Depois de definir as suas substituições, deve excluir o package-lock.json e o node_modules e executar o npm install novamente.

Você pode não definir uma substituição para um pacote do qual depende diretamente, a menos que a dependência e a substituição em si compartilhem exatamente a mesma especificação. Por exemplo, digamos que axios: "0.18.0" é vulnerável e estamos procurando atualizar para axios: "0.19.2". Altere diretamente a versão de dependência em vez de usar a substituição.

{
  "name": "npm-overrides",
  "version": "1.0.0",
  "license": "MIT",
  "dependencies": {
    "axios": "0.18.0"
  },
  "overrides": {
    // BAD, will throw an EOVERRIDE error
    // "axios": "0.19.2",
  }
}

Atualizar a versão da dependência sem definir uma sobreposição:

{
  "name": "npm-overrides",
  "version": "1.0.0",
  "license": "MIT",
  "dependencies": {
    "axios": "0.19.2"
  }
}

Atualizando dependências para o Maven

O mecanismo de resolução de dependência não é tão sofisticado quanto o usado no Yarn. Como resultado, você só pode ter uma única versão de uma dependência em um projeto. Para resolver esse problema, o Maven usa um algoritmo de "vitórias mais próximas". Ou seja, ele usa a versão da dependência mais próxima do seu projeto na árvore de dependências.

Por exemplo, você tem o seguinte gráfico de dependência:

your-project --- A:1.0.0 --- B:2.0.0
      \
       \__ B:1.0.0

your-project depende do A:1.0.0, que por sua vez depende, B:2.0.0 mas o seu projeto também tem uma dependência direta do B:1.0.0. Portanto, você tem duas versões diferentes da dependência B em seu gráfico de dependência, mas a versão 1.0.0 da dependência B vence por estar "mais próxima" do seu projeto.

Em alguns casos, esse cenário pode funcionar se as versões forem compatíveis. No entanto, se A:1.0.0 depender de algum recurso do B que só está disponível na versão 2.0.0 , então esse comportamento não funciona. Na pior das hipóteses, este projeto ainda pode ser compilado, mas falha em tempo de execução.

Vamos dar uma olhada em um exemplo do mundo real.

<project>
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.microsoft.customer360</groupId>
  <artifactId>maven-dependencies</artifactId>
  <packaging>jar</packaging>
  <version>1.0-SNAPSHOT</version>
  <name>maven-dependencies</name>
  <url>http://maven.apache.org</url>
  <dependencies>
    <dependency>
      <groupId>com.fasterxml.jackson.jaxrs</groupId>
      <artifactId>jackson-jaxrs-json-provider</artifactId>
      <version>2.10.3</version>
    </dependency>
</project>

Digamos que a versão de com.fasterxml.jackson.jaxrs:jackson-jaxrs-json-provider de que dependes depende de uma versão de com.fasterxml.jackson.core:jackson-databind que tenha uma vulnerabilidade de desserialização de dados não confiáveis.

Você pode verificar esta dependência usando o plugin de dependência Maven. Neste caso, você executaria mvn dependency:tree -Dincludes=com.fasterxml.jackson.core:jackson-databind e obteria a seguinte saída:

> $ mvn dependency:tree -Dincludes=com.fasterxml.jackson.core:jackson-databind
 [INFO] Scanning for projects...
 [INFO]
 [INFO] ------------< com.microsoft.customer360:maven-dependencies >------------
 [INFO] Building maven-dependencies 1.0-SNAPSHOT
 [INFO] --------------------------------[ jar ]---------------------------------
 [INFO]
 [INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ maven-dependencies ---
 [INFO] com.microsoft.customer360:maven-dependencies:jar:1.0-SNAPSHOT
 [INFO] \- com.fasterxml.jackson.jaxrs:jackson-jaxrs-json-provider:jar:2.10.3:compile
 [INFO]    \- com.fasterxml.jackson.jaxrs:jackson-jaxrs-base:jar:2.10.3:compile
 [INFO]       \- com.fasterxml.jackson.core:jackson-databind:jar:2.10.3:compile
 [INFO] ------------------------------------------------------------------------
 [INFO] BUILD SUCCESS
 [INFO] ------------------------------------------------------------------------
 [INFO] Total time:  0.928 s
 [INFO] Finished at: 2020-04-27T14:30:55+02:00
 [INFO] ------------------------------------------------------------------------

Primeiro, verifique se há uma nova versão de com.fasterxml.jackson.jaxrs:jackson-jaxrs-json-provider que não dependa de uma versão vulnerável de com.fasterxml.jackson.core:jackson-databind. Se sim, você pode atualizar com.fasterxml.jackson.jaxrs:jackson-jaxrs-json-provider e parar por aí. Caso contrário, substitua a versão do com.fasterxml.jackson.core:jackson-databind.

Como mostrado no trecho de código, ao utilizar o Maven, o "mais próximo vence", então a solução passa por adicionar uma dependência direta em com.fasterxml.jackson.core:jackson-databind que resolva a vulnerabilidade.

<project>
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.microsoft.customer360</groupId>
  <artifactId>maven-dependencies</artifactId>
  <packaging>jar</packaging>
  <version>1.0-SNAPSHOT</version>
  <name>maven-dependencies</name>
  <url>http://maven.apache.org</url>
  <dependencies>
    <dependency>
      <groupId>com.fasterxml.jackson.jaxrs</groupId>
      <artifactId>jackson-jaxrs-json-provider</artifactId>
      <version>2.10.3</version>
    </dependency>
    <!-- Dependency resolutions -->
    <!-- jackson-jaxrs-json-provider -->
    <dependency>
      <groupId>com.fasterxml.jackson.core</groupId>
      <artifactId>jackson-databind</artifactId>
      <version>2.9.10.4</version>
    </dependency>
  </dependencies>
</project>

Você pode verificar se a resolução funciona executando mvn dependency:tree -Dincludes=com.fasterxml.jackson.core:jackson-databind novamente.

$ mvn dependency:tree -Dincludes=com.fasterxml.jackson.core:jackson-databind
[INFO] Scanning for projects...
[INFO]
[INFO] ------------< com.microsoft.customer360:maven-dependencies >------------
[INFO] Building maven-dependencies 1.0-SNAPSHOT
[INFO] --------------------------------[ jar ]---------------------------------
[INFO]
[INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ maven-dependencies ---
[INFO] com.microsoft.customer360:maven-dependencies:jar:1.0-SNAPSHOT
[INFO] \- com.fasterxml.jackson.core:jackson-databind:jar:2.9.10.4:compile
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  0.827 s
[INFO] Finished at: 2020-04-27T14:32:42+02:00
[INFO] ------------------------------------------------------------------------

Recomendamos que adiciones um comentário junto à resolução de dependências, para que qualquer pessoa que venha posteriormente saiba por que a dependência está lá. Ele pode ser removido uma vez que a dependência raiz usa a nova versão; caso contrário, você acumulará dependências.

Em um projeto real, adicione a dependência o mais alto possível na cadeia. Por exemplo, pode adicionar a resolução no arquivo POM pai, em vez de o fazer individualmente em cada arquivo POM do projeto.

Atualizando dependências para o NuGet

O algoritmo de resolução de dependência usado no NuGet é semelhante ao Maven, em que apenas uma única versão de uma dependência pode ser usada. No entanto, o NuGet não fixa versões de dependência.

Por exemplo, se você tiver uma dependência <PackageReference Include="A" Version="1.2.3" />, você pode esperar que este pacote seja equivalente a = 1.2.3, mas na verdade significa >= 1.2.3. Para fixar uma versão exata, deve usar Version="[1.2.3]". Para obter mais informações, consulte a documentação dos intervalos de versões do NuGet.

Além do comportamento de intervalo padrão, o NuGet restaura a versão mais baixa aplicável para satisfazer um intervalo. Esse comportamento significa que, em muitos casos, você precisa definir um intervalo.

Vamos dar uma olhada neste projeto de exemplo, que tem uma dependência de Microsoft.AspNetCore.App:

<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <TargetFramework>netcoreapp3.1</TargetFramework>
    <RootNamespace>NuGet.Dependencies</RootNamespace>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore.App" Version="2.1.14" />
  </ItemGroup>
</Project>

Depende de uma versão de Microsoft.AspNetCore.Http.Connections que seja vulnerável a uma vulnerabilidade de execução remota de código (RCE).

Primeiro, deve verificar se há uma versão atualizada de Microsoft.AspNetCore.App que depende de uma versão mais recente do Microsoft.AspNetCore.Http.Connections. Se sim, você pode atualizar Microsoft.AspNetCore.App e parar aqui. Se não, tens de substituir a versão de que Microsoft.AspNetCore.Http.Connections depende.

O NuGet não tem um equivalente integrado ao yarn why ou ao mvn dependency:tree, portanto, a maneira mais fácil de ver a árvore de dependências é frequentemente visitar nuget.org. Se visitar a página do NuGet para Microsoft.AspNetCore.App, verá que depende de Microsoft.AspNetCore.Http.Connectionsversion >= 1.0.4 && < 1.1.0. Ou, em um intervalo de versões do NuGet, a sintaxe representativa é [1.0.4,1.1.0).

A vulnerabilidade RCE em Microsoft.AspNetCore.Http.Connections foi corrigida na versão 1.0.15, então você precisa substituir o intervalo de versões a ser[1.0.15, 1.1.0).

<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <TargetFramework>netcoreapp3.1</TargetFramework>
    <RootNamespace>NuGet.Dependencies</RootNamespace>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore.App" Version="2.2.8" />
  </ItemGroup>

  <ItemGroup Label="Dependency Resolutions">
    <!-- Microsoft.AspNetCore.App -->
    <PackageReference Include="Microsoft.AspNetCore.Http.Connections" Version="[1.0.15,1.1.0)" />
  </ItemGroup>
</Project>

Recomendamos que você adicione um comentário perto da resolução de dependência para que qualquer pessoa que venha mais tarde saiba por que a dependência está lá. Ele pode ser removido quando a dependência raiz usa a nova versão. Caso contrário, você acumulará dependências.

E se não houver nenhuma correção disponível?

Quando nenhuma correção conhecida estiver disponível, as seguintes opções estarão disponíveis como outros métodos de correção até que um componente atualizado esteja disponível:

  • Pare de usar o componente e remova-o do seu código - esta remoção é detetada na sua próxima compilação com a tarefa de verificação de dependência instalada
  • Contribua com uma correção para o próprio componente. Se a sua organização tiver diretrizes específicas sobre contribuições de código aberto, siga essas diretrizes.
  • Descartando o alerta. No entanto, alertas sem correção conhecida ainda podem representar uma ameaça à segurança da sua organização. Recomendamos que você não descarte um alerta apenas porque não há nenhuma correção conhecida.

Ignorar alertas de verificação de dependência

Para descartar um alerta, execute as seguintes etapas:

  1. Aceda ao alerta que pretende fechar e clique no alerta.

  2. Selecione o menu pendente Fechar alerta.

  3. Se ainda não estiver selecionado, selecione Risco aceito ou Falso positivo como o motivo do fechamento.

  4. Adicione um comentário opcional na caixa de texto Comentário.

  5. Selecione Fechar para enviar e feche o alerta.

  6. O estado de alerta muda de Aberto para Fechado e exibe o motivo da demissão.

    Captura de ecrã a mostrar como ignorar um alerta de varredura de dependências.

Esta ação elimina o alerta em todas as filiais. Outras ramificações que contenham a mesma vulnerabilidade também serão descartadas. Qualquer notificação de alerta anteriormente descartada pode ser reaberta manualmente.

Gerenciando alertas de varredura de dependência em solicitações pull

Se forem criados alertas para novas alterações de código em uma solicitação pull, o alerta será relatado como uma anotação na seção de comentários da guia Visão geral da solicitação pull e como um alerta na guia Advanced Security repository. Uma nova entrada do seletor de ramificação está disponível para a ramificação de solicitação pull.

Você pode ver o manifesto do pacote afetado, ver um resumo da descoberta e resolver a anotação na seção Visão geral.

Captura de tela da anotação de solicitação pull de dependência ativa.

Para descartar alertas de solicitação pull, você deve navegar até a exibição de detalhes do alerta para fechar o alerta e resolver a anotação. Caso contrário, simplesmente alterar o status do comentário (1) resolve a anotação, mas não fecha nem corrige o alerta subjacente.

Captura de tela da anotação de solicitação pull de dependência fechada.

Para ver todo o conjunto de resultados para a sua branch de pull request, navegue até Repos>Advanced Security e selecione a sua branch de pull request. Selecionar Mostrar mais detalhes (2) na anotação direciona você para a exibição de detalhes do alerta na guia Segurança Avançada.

Gorjeta

As anotações só são criadas quando as linhas de código afetadas são inteiramente únicas para a diferença presente na solicitação pull em comparação com o branch de destino da solicitação pull.

  • Última atualização a