Compartilhar via

Verificação de dependência

  • Artigo

A verificação de dependência no GitHub Advanced Security para Azure DevOps detecta os componentes de software livre usados no código-fonte e detecta se há vulnerabilidades associadas. As vulnerabilidades encontradas de componentes de software livre são sinalizadas como um alerta.

O GitHub Advanced Security para Azure DevOps funciona com o Azure Repos. Se você quiser usar o GitHub Advanced Security com repositórios do GitHub, consulte o GitHub Advanced Security.

Sobre a verificação de dependência

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

Sobre a detecção de verificação de dependência

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 detectado em uso, o componente e a vulnerabilidade são listados no log de build e exibidos como um alerta na guia Segurança Avançada. Somente os avisos revisados pelo GitHub e adicionados ao Banco de Dados de Assistente do GitHub criam um alerta de verificação de dependência. O log de build inclui um link para o alerta individual para uma investigação mais aprofundada. Para obter mais informações sobre os detalhes do alerta, exiba a correção de alertas de verificação de dependência.

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

Captura de tela de uma saída de build de verificação de dependência

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

Sobre alertas de verificação de dependência

A guia Segurança Avançada em Repos no Azure DevOps é o hub para exibir seus alertas de segurança, que por padrão mostram alertas de verificação de dependência. Você pode filtrar por ramificação, pipeline, pacote e gravidade. Você pode selecionar em um alerta para obter mais detalhes, incluindo diretrizes de correção. No momento, o hub de alertas não exibe alertas para varredura concluída em ramificações de PR.

Quando um pacote vulnerável é detectado em seu repositório, corrigir alertas de verificação de dependência normalmente envolve a atualização para uma versão de pacote mais alta ou a remoção de um pacote ofensivo. Esse conselho é válido para dependências diretas e transitivas (ou indiretas). O modo de exibição padrão na guia Segurança Avançada é alertas ativos para o branch padrão do repositório.

Não haverá efeito nos resultados se pipelines ou branches forem renomeados – pode levar até 24 horas até que o novo nome seja exibido.

Captura de tela do modo de exibição de alerta de verificação de dependência para um repositório

O estado de um alerta é atualizado automaticamente para Closed quando o componente vulnerável não é mais detectado no build mais recente para pipelines em que a tarefa de verificação de dependência é instalada. Para exibir os alertas resolvidos, utilize o State filtro na barra de ferramentas principal e selecione Closed.

Captura de tela da exibição de alertas de verificação de dependência fechados

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 build não falhará, mas os resultados de builds executados com a tarefa enquanto a Segurança Avançada estiver desabilitada estão ocultos e não foram armazenados.

Detalhes do Alerta

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

Captura de tela mostrando detalhes de um alerta de verificação de dependência

Seção Explicação
Recomendação O texto da recomendação vem diretamente do nosso provedor de dados de vulnerabilidade, o Banco de Dados de Assistente do GitHub. Normalmente, as diretrizes sugerem a atualização do componente identificado para uma versão não vulnerável.
Local A seção Locais detalha os caminhos em que a tarefa de verificação de dependência descobriu o componente vulnerável em uso. Se o arquivo puder ser resolvido da verificação de build subjacente para um arquivo confirmado na origem, o cartão Locais aparecerá como um link clicável. Se um arquivo foi produzido como parte de um build (por exemplo, um artefato de build), o link não é clicável. Examine os logs de build para entender melhor como o componente foi trazido para o build.
Descrição A descrição é fornecida pela descrição do Assistente do GitHub.

Detecções

Os pipelines listados na guia Detecções são os pipelines em que o componente vulnerável foi encontrado. Cada linha detalha o build mais recente do pipeline afetado e a data em que o pacote foi introduzido pela primeira vez. Se o pacote vulnerável tiver sido corrigido em alguns pipelines, mas não em todos, você verá linhas parcialmente fixas.

Captura de tela da exibição de detecções de verificação de dependência para um alerta sem correção

Depois que um alerta for resolvido, o alerta será movido automaticamente para o Closed estado e o pipeline de execução mais recente na guia Detecções exibirá 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 tela da exibição de detecções de verificação de dependência para um alerta

Severidade

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

Pontuação CVSS Severidade
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

Localizar detalhes

Duas seções são comumente encontradas em Localizar detalhes: pacote vulnerável e 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 responsáveis pela cadeia de dependências que levam 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".

Gerenciar alertas de verificação de dependência

Visualizando alertas de um repositório

Qualquer pessoa com permissões de colaborador para um repositório pode exibir um resumo de todos os alertas de um repositório no Repos>Advanced Security.

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

O status de um alerta reflete o estado do branch padrão e do pipeline de execução mais recente, mesmo que o alerta exista em outros branches e pipelines.

Corrigindo alertas de verificação 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 substituir explicitamente a versão do componente vulnerável usado para cada dependência direta identificada. Depois que as dependências raiz tiverem atualizado o 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.

Atualizando dependências para Yarn/Npm

Hipoteticamente, digamos que este pacote tenha duas vulnerabilidades. Uma é para axios, uma dependência direta e outra 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 axios tem uma vulnerabilidade de serviço de negação (DoS) com uma recomendação para atualizar para v0.18.1 ou superior. Como é uma dependência direta, você tem controle sobre a versão que axios você usa; tudo o que você precisa fazer é atualizar a versão da axios qual você efetua pull. A atualização 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 em package.json mostrado depende de uma versão acorn é uma vulnerabilidade de negação de serviço de expressão regular (ReDoS) com uma recomendação para atualizar para a versão 5.7.4, 6.4.1, 7.1.1 ou superior. Se você receber um alerta da ferramenta de verificação de dependência, ele deverá informar a dependência raiz que requer a dependência vulnerável.

Yarn

Se você estiver usando o Yarn, poderá usar yarn por que 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ências, você pode usar outro recurso do Yarn, resoluções de dependência seletiva, para substituir a versão do acorn que é usada.

Use o campo package.json resoluções para definir uma substituição de versão. Três métodos diferentes para substituir um pacote são mostrados, na ordem da pior para a 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 todos os usos do pacote de acorn em todas as dependências. É perigoso, e quebrar em runtime. Como resultado, ele foi removido no Yarn v2.

O uso do eslint/**/acorn padrão substitui todos os usos do pacote de acorn no pacote eslint e em todos os pacotes dos quais ele depende. É mais seguro do que substituir o pacote para todas as dependências, mas ainda terá alguns riscos se o grafo de dependência 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 do acorn em espree pacote no eslint pacote. Ele tem como alvo especificamente a cadeia de dependência vulnerável e é a maneira recomendada de substituir as versões do pacote.

npm

Se você estiver usando npm 8.3 ou superior, poderá usar o campo substituições em seu package.json

Adicione uma substituição se precisar fazer alterações específicas em dependências transitivas. Por exemplo, talvez seja necessário adicionar uma substituição para substituir a versão de uma dependência por 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 lugares.

{
  "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 a maneira do npm de dizer "substituir somente o uso do acorn em espree pacote no eslint pacote". Ele tem como alvo especificamente a cadeia de dependência vulnerável e é a maneira recomendada de substituir as versões do pacote. As substituições são um recurso nativo 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 suas substituições, você deve excluir seu package-lock.json e node_modules executar 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 própria substituição compartilhem exatamente a mesma especificação. Por exemplo, digamos que axios: "0.18.0" seja 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",
  }
}

Atualize a versão da dependência sem definir uma substituiçã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 grafo de dependência:

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

your-project depende A:1.0.0, o que, por sua vez, depende B:2.0.0 , mas seu projeto também tem uma dependência B:1.0.0direta. Portanto, você tem duas versões diferentes da dependência B no grafo de dependência, mas a versão 1.0.0 da dependência B vence, pois ela é "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 de B disponível apenas na versão 2.0.0 , esse comportamento não funcionará. Na pior das hipóteses, esse projeto ainda pode ser compilado, mas falhará em runtime.

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 da com.fasterxml.jackson.jaxrs:jackson-jaxrs-json-provider qual você depende de com.fasterxml.jackson.core:jackson-databind uma versão que tenha uma desserialização da vulnerabilidadede dados não confiáveis.

Você pode verificar essa dependência usando o plug-in de dependência do Maven. Nesse 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 que não depende de com.fasterxml.jackson.jaxrs:jackson-jaxrs-json-provider uma versão vulnerável de com.fasterxml.jackson.core:jackson-databind. Nesse caso, você pode atualizar com.fasterxml.jackson.jaxrs:jackson-jaxrs-json-provider e parar por aí. Caso contrário, substitua a versão de com.fasterxml.jackson.core:jackson-databind.

Conforme mostrado no snippet de código, ao usar Maven o "mais próximo vence", a resolução é adicionar uma dependência direta a com.fasterxml.jackson.core:jackson-databind isso corrige 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] ------------------------------------------------------------------------

É recomendável adicionar um comentário próximo à 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 depois 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, você pode adicionar a resolução no arquivo POM pai, em vez de 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, no qual 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" />, poderá esperar que esse pacote seja equivalente a = 1.2.3, mas isso realmente significa >= 1.2.3. Para fixar uma versão exata, você deve usar Version="[1.2.3]". Para obter mais informações, consulte a documentação de 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 atender a 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 em 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 vulnerável a uma vulnerabilidade de execução de código remoto (RCE).

Primeiro, você deve verificar se há uma versão atualizada disso depende de Microsoft.AspNetCore.App uma versão mais recente de Microsoft.AspNetCore.Http.Connections. Nesse caso, você pode atualizar Microsoft.AspNetCore.App e parar aqui. Caso contrário, você precisará substituir a versão dela Microsoft.AspNetCore.Http.Connections .

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

A vulnerabilidade Microsoft.AspNetCore.Http.Connections do RCE foi corrigida na versão 1.0.15, portanto, você precisa substituir o intervalo de versão para 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>

É recomendável adicionar um comentário próximo à 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 depois que 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 código - essa remoção é detectada na 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 sua organização tiver diretrizes específicas sobre contribuições de software livre, siga essas diretrizes.
  • Ignorar o alerta. No entanto, alertas sem correção conhecida ainda podem representar uma ameaça à segurança para sua organização. Recomendamos que você não ignore um alerta apenas porque não há nenhuma correção conhecida.

Ignorar alertas de verificação de dependência

Para ignorar alertas na Segurança Avançada, você precisa das permissões apropriadas. Por padrão, somente os administradores de projeto são fornecidos com a capacidade de ignorar alertas de Segurança Avançada.

Para ignorar um alerta:

  1. Vá para o alerta que você deseja fechar e selecione no alerta
  2. Selecione a lista suspensa 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 à caixa de texto Comentário .
  5. Selecione Fechar para enviar e fechar o alerta.
  6. O estado de alerta muda de Abrir para Fechado e exibe o motivo da demissão.

Captura de tela mostrando como ignorar um alerta de verificação de dependência

Essa ação descarta apenas o alerta para o branch selecionado. Outros branches que podem conter a mesma vulnerabilidade permanecem ativos até que, de outra forma, tenha agido. Qualquer alerta que tenha sido descartado anteriormente pode ser reaberto manualmente.

Gerenciamento alertas de verificação de dependência em solicitações de pull

Se forem criados alertas para novas alterações de código em uma solicitação de pull, o alerta será relatado como uma anotação na seção de comentários da guia Visão geral da solicitação de pull e como um alerta na guia Repositório de Segurança Avançada. Há uma nova entrada do seletor de branch para o branch de solicitação de pull.

É possível ver o manifesto do pacote afetado, acessar um resumo da descoberta e resolver a anotação na seção Visão geral.

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

Para ignorar alertas de solicitação de pull, navegue 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 de pull de dependência fechada.

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

Dica

As anotações só serão criadas quando as linhas de código afetadas forem totalmente exclusivas para a diferença da solicitação de pull em comparação com o branch de destino da solicitação de pull.