Analyse des dépendances

L’analyse des dépendances dans GitHub Advanced Security pour Azure DevOps détecte les composants open source utilisés dans votre code source et détecte s’il existe des vulnérabilités associées. Toutes les vulnérabilités détectées des composants open source sont signalées comme une alerte.

GitHub Advanced Security pour Azure DevOps fonctionne avec Azure Repos. Si vous souhaitez utiliser GitHub Advanced Security avec des référentiels GitHub, consultez GitHub Advanced Security.

À propos de l’analyse des dépendances

L’analyse des dépendances génère une alerte pour n’importe quel composant open source, direct ou transitif, qui est vulnérable selon laquelle votre code dépend. Les vulnérabilités directes sont les bibliothèques que votre code utilise directement. Les dépendances transitives sont les bibliothèques ou d’autres logiciels qui utilisent des dépendances directes.

À propos de la détection de l’analyse des dépendances

Un nouvel instantané de vos composants est stocké chaque fois que le graphe de dépendances d'un référentiel change, et après l'exécution d'un pipeline contenant la tâche d'analyse de dépendances pour construire du nouveau code (en d'autres termes, un nouveau commit).

Pour chaque composant vulnérable détecté en cours d’utilisation, le composant et la vulnérabilité sont répertoriés dans le journal de build et affichés sous forme d’alerte dans l’onglet Sécurité avancée. Seuls les avis examinés par GitHub et ajoutés à la base de données GitHub Advisory créent une alerte d’analyse des dépendances. Le journal de génération inclut un lien vers l’alerte individuelle pour une investigation plus approfondie. Pour plus d’informations sur les détails de l’alerte, consultez La résolution des alertes d’analyse des dépendances.

Le journal de génération contient également des informations de base sur chaque vulnérabilité détectée. Ces détails incluent la gravité, le composant affecté, le titre de la vulnérabilité et le CVE associé.

Écosystèmes de packages pris en charge

L’analyse des dépendances prend en charge les dépendances directes et les dépendances transitives pour tous les écosystèmes de packages pris en charge.

Gestionnaire de package	Langages	Formats pris en charge
Cargo	Rust	Cargo.toml, Cargo.lock
CocoaPods	Swift	Podfile.lock
Modules Go	Go	go.mod, go.sum
Gradle	Java	*.lockfile
Maven	Java	pom.xml
npm	JavaScript	package-lock.json, package.json, npm-shrinkwrap.json, lerna.json
NuGet	C#	*.packages.config, *.project.assets, *.csproj
pip	Python	setup.py, requirements.txt
pnpm	JavaScript	package.json
RubyGems	Ruby	Gemfile.lock
Yarn	JavaScript	package.json

À propos des alertes d’analyse des dépendances

L’onglet Sécurité avancée dans Repos dans Azure DevOps est le hub pour afficher vos alertes de sécurité, qui affichent par défaut des alertes d’analyse des dépendances. Vous pouvez filtrer par branche, pipeline, package et gravité. Vous pouvez sélectionner une alerte pour plus de détails, notamment des conseils de correction. À ce stade, le hub d’alertes n’affiche pas d’alertes pour l’analyse effectuée sur les branches de la demande de tirage.

Lorsqu’un package vulnérable est détecté dans votre référentiel, la résolution des alertes d’analyse des dépendances implique généralement la mise à niveau vers une version supérieure du package ou la suppression d’un package incriminé. Ce conseil est vrai pour les dépendances directes et transitives (ou indirectes). L’affichage par défaut dans votre onglet Sécurité avancée est des alertes actives pour la branche par défaut de votre référentiel.

Il n’y a aucun effet sur les résultats si les pipelines ou les branches sont renommés. Cela peut prendre jusqu’à 24 heures avant que le nouveau nom ne s’affiche.

L’état d’une alerte est automatiquement mis à jour Closed lorsque le composant vulnérable n’est plus détecté dans la dernière build pour tous les pipelines où la tâche d’analyse des dépendances est installée. Pour afficher vos alertes résolues, utilisez le State filtre dans la barre d’outils principale et sélectionnez Closed.

Si vous désactivez la sécurité avancée pour votre référentiel, vous perdrez l'accès aux résultats dans l'onglet Sécurité avancée et à la tâche de génération. La tâche de build n'échouera pas, mais tous les résultats des builds exécutés avec la tâche alors que la sécurité avancée est désactivée sont masqués et non conservés.

Détails de l’alerte

Vous pouvez également explorer les détails d’une alerte en cliquant sur une alerte spécifique et des conseils de correction.

Section	Explication
Recommandation	Le texte de recommandation provient directement de notre fournisseur de données de vulnérabilité, la base de données de conseil GitHub. En règle générale, les conseils suggèrent de mettre à niveau le composant identifié vers une version non vulnérable.
Emplacement	La section Emplacements détaille le ou les chemins d’accès où la tâche d’analyse des dépendances a découvert le composant vulnérable en cours d’utilisation. Si le fichier peut être résolu à partir de l’analyse de build sous-jacente vers un fichier validé dans la source, la carte Emplacements s’affiche sous la forme d’un lien cliquable. Si un fichier a été produit dans le cadre d’une build (par exemple, un artefact de build), le lien n’est pas cliquable. Passez en revue les journaux de build pour mieux comprendre comment le composant a été introduit dans la build.
Description	La description est fournie par la description de GitHub Advisory.

Détections

Les pipelines répertoriés sous l’onglet Détections sont les pipelines où le composant vulnérable a été trouvé. Chaque ligne détaille la dernière build du pipeline concerné et la date à laquelle le package a été introduit pour la première fois. Si le package vulnérable a été corrigé dans certains pipelines, mais pas tous, vous voyez des lignes partiellement fixes.

Une fois qu’une alerte a été résolue, l’alerte passe automatiquement à l’état Closed et le dernier pipeline d’exécution sous l’onglet Détections affiche une coche verte, ce qui signifie que le code contenant le composant mis à jour a été exécuté dans ce pipeline :

Gravité

La base de données GitHub Advisory fournit un score CVSS, qui est ensuite traduit en gravité faible, moyenne, élevée ou critique pour une alerte par le biais des instructions suivantes :

Score CVSS	Gravité
1.0 < Score < 4.0	Faible
4.0 < Score < 7.0	Moyenne
7.0 < Score < 9.0	Élevé
Score >= 9.0	Critique

Recherche de détails

Deux sections sont généralement trouvées sous Recherche de détails : package vulnérable et dépendance racine. Le package vulnérable est le composant potentiellement vulnérable. La section dépendance racine contient des composants de niveau supérieur qui sont responsables de la chaîne de dépendances qui entraînent une vulnérabilité.

Si le package vulnérable n’est référencé qu’en tant que dépendance directe, la section « package vulnérable » s’affiche uniquement.

Si le package vulnérable est référencé à la fois en tant que dépendance directe et transitive, le package est affiché dans la section « package vulnérable » et « dépendance racine ».

Si le package vulnérable est référencé uniquement en tant que dépendance transitive, le package est affiché dans la section « package vulnérable » et les dépendances racines référençant le package vulnérable sont affichées dans la section « dépendance racine ».

Gérer les alertes d’analyse des dépendances

Affichage des alertes pour un dépôt

Toute personne disposant d’autorisations contributeur pour un référentiel peut afficher un résumé de toutes les alertes pour un référentiel dans Repos>Advanced Security.

Par défaut, la page des alertes affiche les résultats de l’analyse des dépendances pour la branche par défaut du référentiel.

L’état d’une alerte reflète l’état de la branche par défaut et du pipeline d’exécution le plus récent, même si l’alerte existe sur d’autres branches et pipelines.

Résolution des alertes d’analyse des dépendances

Une dépendance directe est un composant que vous avez dans votre référentiel. Une dépendance transitive ou indirecte est un composant qui est utilisé par une dépendance directe. Votre projet est toujours vulnérable, que la vulnérabilité soit trouvée dans une dépendance directe ou transitive.

La résolution d’une dépendance transitive vulnérable prend généralement la forme de remplacer explicitement la version du composant vulnérable utilisé pour chaque dépendance directe identifiée. Une fois que les dépendances racines ont mis à niveau leur utilisation du composant vulnérable vers une version sécurisée, vous pouvez mettre à niveau chaque dépendance racine plutôt que plusieurs remplacements individuels.

Mise à jour des dépendances pour Yarn/Npm

Hypothétiquement, supposons que ce package présente deux vulnérabilités. L’un est pour axios, une dépendance directe, et l’autre est pour acorn, une dépendance transitive (également appelée dépendance indirecte ou dépendance de dépendance).

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

La version actuelle a axios une vulnérabilité de déni de service (DoS) avec une recommandation de mise à jour vers v0.18.1 ou version ultérieure. Étant donné qu’il s’agit d’une dépendance directe, vous avez un contrôle sur la version de axios ce que vous utilisez ; il vous suffit de mettre à jour la version de celle que axios vous extrayez. La mise à jour package.json ressemble à ce qui suit :

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

À présent, la version de eslint l’affichage package.json dépend d’une version de acorn celle-ci est une vulnérabilité de déni de service d’expression régulière (ReDoS) avec une recommandation de mise à jour vers la version 5.7.4, 6.4.1, 7.1.1 ou une version ultérieure. Si vous recevez une alerte à partir de l’outil d’analyse des dépendances, elle doit vous indiquer la dépendance racine qui nécessite la dépendance vulnérable.

Yarn

Si vous utilisez Yarn, vous pouvez utiliser yarn pourquoi trouver la chaîne de dépendance complète.

> $ 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.

La chaîne de dépendances complète est eslintacorn>espree>. Une fois que vous connaissez la chaîne de dépendances, vous pouvez utiliser une autre fonctionnalité de Yarn, des résolutions de dépendance sélectives, pour remplacer la version d’acorn utilisée.

Utilisez le champ résolutions dans package.json lequel définir un remplacement de version. Trois méthodes différentes pour remplacer un package sont affichées, dans l’ordre le plus mauvais pour le mieux :

{
  "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"
  }
}

L’utilisation du**/acorn modèle remplace toutes les utilisations du package acorn sur toutes les dépendances. C’est dangereux, et arrêt à l’exécution. Par conséquent, il a été supprimé dans Yarn v2.

L’utilisation du eslint/**/acorn modèle remplace toutes les utilisations du package acorn sous le package eslint, et dans tous les packages dont elle dépend. Il est plus sûr que de remplacer le package pour toutes les dépendances, mais il présente toujours des risques si le graphique des dépendances d’un package est volumineux. Ce modèle est recommandé lorsqu’il existe de nombreux sous-packages qui utilisent un package vulnérable et la définition de remplacements pour des sous-packages individuels serait impraticable.

L’utilisation du modèle eslint/espree/acorn remplace uniquement l’utilisation du espreeacorn package dans le eslint package. Il cible spécifiquement la chaîne de dépendances vulnérable et est la méthode recommandée pour remplacer les versions du package.

npm

Si vous utilisez npm 8.3 ou version ultérieure, vous pouvez utiliser le champ remplacements dans votre package.json

Ajoutez un remplacement si vous devez apporter des modifications spécifiques aux dépendances transitives. Par exemple, vous devrez peut-être ajouter un remplacement pour remplacer la version d’une dépendance par un problème de sécurité connu, remplacer une dépendance existante par une duplication ou vérifier que la même version d’un package est utilisée partout.

{
  "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"
        }
    }
   }
}

L’exemple de remplacement illustré illustre la façon de dire « remplacer uniquement l’utilisation du acornespree package dans le eslint package ». Il cible spécifiquement la chaîne de dépendances vulnérable et est la méthode recommandée pour remplacer les versions du package. Les remplacements sont une fonctionnalité native de npm. Il permet de remplacer un package dans votre arborescence de dépendances par une autre version ou un autre package entièrement.

Après avoir défini vos remplacements, vous devez supprimer package-lock.json et node_modules et réexécuter npm install.

Vous ne pouvez pas définir de remplacement pour un package dont vous dépendez directement, sauf si la dépendance et le remplacement lui-même partagent exactement la même spécification. Par exemple, supposons que axios: "0.18.0" nous sommes vulnérables et que nous cherchons à effectuer une mise à niveau vers axios: "0.19.2". Modifiez directement la version de dépendance au lieu d’utiliser le remplacement.

{
  "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",
  }
}

Mettez à jour la version de la dépendance sans définir de remplacement :

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

Mise à jour des dépendances pour Maven

Le mécanisme de résolution des dépendances n’est pas aussi sophistiqué que celui utilisé dans Yarn. Par conséquent, vous ne pouvez avoir qu’une seule version d’une dépendance dans un projet. Pour résoudre ce problème, Maven utilise un algorithme « le plus proche gagne ». Autrement dit, il utilise la version de la dépendance la plus proche de votre projet dans l’arborescence des dépendances.

Par exemple, vous disposez du graphique de dépendance suivant :

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

your-project dépend de A:1.0.0, qui à son tour dépend de B:2.0.0, mais votre projet a également une dépendance directe sur B:1.0.0. Par conséquent, vous avez deux versions différentes de la dépendance B dans votre graphique de dépendances, mais la version 1.0.0 de la dépendance B gagne, car elle est « la plus proche » de votre projet.

Dans certains cas, ce scénario peut fonctionner si les versions sont compatibles. Toutefois, si A:1.0.0 dépend de certaines fonctionnalités de B qui n’est disponible que dans la version 2.0.0, ce comportement ne fonctionne pas. Dans le pire des cas, ce projet peut toujours être compilé mais échoue au moment de l’exécution.

Examinons un exemple réel.

<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>

Supposons que la version de com.fasterxml.jackson.jaxrs:jackson-jaxrs-json-provider vous dépende d’une version de com.fasterxml.jackson.core:jackson-databind celle-ci ayant une désérialisation d’une vulnérabilitéde données non approuvées.

Vous pouvez vérifier cette dépendance à l’aide du plug-inde dépendance Maven. Dans ce cas, vous allez exécuter mvn dependency:tree -Dincludes=com.fasterxml.jackson.core:jackson-databind et obtenir la sortie suivante :

> $ 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] ------------------------------------------------------------------------

Tout d’abord, vérifiez s’il existe une nouvelle version de com.fasterxml.jackson.jaxrs:jackson-jaxrs-json-provider cela ne dépend pas d’une version vulnérable de com.fasterxml.jackson.core:jackson-databind. Si c’est le cas, vous pouvez effectuer une mise à niveau de com.fasterxml.jackson.jaxrs:jackson-jaxrs-json-provider et l’arrêter. Si ce n’est pas le cas, remplacez la version de com.fasterxml.jackson.core:jackson-databind.

Comme indiqué dans l’extrait de code, lors de l’utilisation de Maven le « plus proche gagne », la résolution consiste donc à ajouter une dépendance directe à com.fasterxml.jackson.core:jackson-databind celle-ci pour corriger la vulnérabilité.

<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>

Vous pouvez vérifier que la résolution fonctionne à nouveau en exécutant mvn dependency:tree -Dincludes=com.fasterxml.jackson.core:jackson-databind à nouveau.

$ 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] ------------------------------------------------------------------------

Il est recommandé d’ajouter un commentaire près de la résolution des dépendances, afin que toute personne qui arrive plus tard sache pourquoi la dépendance est là. Elle peut être supprimée une fois que la dépendance racine utilise la nouvelle version ; sinon, vous accumulez des dépendances.

Dans un projet réel, ajoutez la dépendance aussi haut que possible dans la chaîne. Par exemple, vous pouvez ajouter la résolution dans le fichier POM parent, au lieu d’être individuellement dans chaque fichier POM de projet.

Mise à jour des dépendances pour NuGet

L’algorithme de résolution de dépendance utilisé dans NuGet est similaire à Maven, car seule une seule version d’une dépendance peut être utilisée. Toutefois, NuGet n’épingle pas les versions des dépendances.

Par exemple, si vous avez une dépendance <PackageReference Include="A" Version="1.2.3" />, vous pouvez vous attendre à ce que ce package soit équivalent à = 1.2.3, mais cela signifie >= 1.2.3réellement. Pour épingler une version exacte, vous devez utiliser Version="[1.2.3]". Pour plus d’informations, consultez la documentation sur les plages de versions NuGet.

Outre le comportement de plage par défaut, NuGet restaure la version la plus basse applicable pour satisfaire une plage. Ce comportement signifie que, dans de nombreux cas, vous devez définir une plage.

Examinons cet exemple de projet, qui a une dépendance sur 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>

Elle dépend d’une version de Microsoft.AspNetCore.Http.Connections celle-ci vulnérable à une vulnérabilité d’exécution de code à distance (RCE).

Tout d’abord, vous devez vérifier s’il existe une version mise à jour de Microsoft.AspNetCore.App cela dépend d’une version plus récente de Microsoft.AspNetCore.Http.Connections. Si c’est le cas, vous pouvez mettre à niveau Microsoft.AspNetCore.App et arrêter ici. Si ce n’est pas le cas, vous devez remplacer la version de Microsoft.AspNetCore.Http.Connections dont elle dépend.

NuGet n'a pas d'équivalent intégré de `yarn why` ou `mvn dependency:tree`, donc la façon la plus simple de voir l'arbre de dépendances est souvent de visiter nuget.org. Si vous visitez la page NuGet pour Microsoft.AspNetCore.App, vous verrez qu'il dépend de Microsoft.AspNetCore.Http.Connections version >= 1.0.4 && < 1.1.0. Ou, dans une plage de versions NuGet, la syntaxe représentative est [1.0.4,1.1.0).

La vulnérabilité RCE dans Microsoft.AspNetCore.Http.Connections la version 1.0.15a été corrigée. Vous devez donc remplacer la plage de versions.[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>

Il est recommandé d’ajouter un commentaire près de la résolution des dépendances afin que toute personne qui arrive plus tard sache pourquoi la dépendance est là. Elle peut être supprimée une fois que la dépendance racine utilise la nouvelle version. Sinon, vous accumulez des dépendances.

Que se passe-t-il si aucun correctif n’est disponible ?

Quand aucun correctif connu n’est disponible, les options suivantes sont disponibles sous forme d’autres méthodes de correction jusqu’à ce qu’un composant mis à niveau soit disponible :

• Arrêtez d’utiliser le composant et supprimez-le de votre code. Cette suppression sera détectée lors de votre prochaine build avec la tâche d’analyse des dépendances installée
• Contribuer à un correctif au composant lui-même. Si votre organisation a des instructions spécifiques concernant les contributions open source, suivez ces instructions.
• Ignorer l’alerte. Toutefois, les alertes sans correctif connu peuvent toujours poser une menace de sécurité pour votre organisation. Nous vous recommandons de ne pas ignorer une alerte simplement parce qu’il n’y a pas de correctif connu.

Ignorer les alertes d’analyse des dépendances

Pour ignorer les alertes dans Advanced Security, vous avez besoin des autorisations appropriées. Par défaut, seuls les administrateurs de projet sont fournis avec la possibilité d’ignorer les alertes Advanced Security.

Pour ignorer une alerte :

1. Accédez à l’alerte que vous souhaitez fermer et sélectionnez-la sur l’alerte
2. Sélectionnez la liste déroulante Fermer l’alerte
3. Si ce n’est pas déjà fait, sélectionnez Risque accepté ou Faux positif comme raison de fermeture
4. Ajouter un commentaire facultatif dans la zone de texte Commentaire
5. Sélectionnez Fermer pour envoyer et fermer l’alerte
6. L’état d’alerte passe d’Ouvert à Fermé et affiche le motif pour ignorer

Cette action ignore uniquement l’alerte de votre branche sélectionnée. Les autres branches qui peuvent contenir la même vulnérabilité restent actives jusqu’à ce qu’elles n’agissent pas autrement. Toute alerte qui a été précédemment ignorée peut être rouverte manuellement.

Gestion des alertes d'analyse de dépendances sur les pull requests

Si des alertes sont créées pour de nouvelles modifications de dépendances dans une pull request, l'alerte sera signalée comme une annotation dans la section des commentaires de l'onglet Vue d'ensemble de la pull request et comme une alerte dans l'onglet Sécurité avancée du référentiel, avec un nouveau résultat de sélection de branche pour la branche de la pull request.

Vous pouvez voir le manifeste de package affecté, consulter un résumé de la découverte et résoudre l'annotation dans la section Vue d'ensemble.

Pour rejeter les alertes de pull request, vous devez naviguer vers la vue détaillée de l’alerte pour fermer à la fois l’alerte et résoudre l’annotation. Sinon, le simple fait de changer le statut du commentaire (1) résout l’annotation mais ne ferme pas ou ne corrige pas l’alerte sous-jacente.

Pour voir l’ensemble des résultats de votre branche de pull request, naviguez vers Repos>Sécurité avancée et sélectionnez votre branche de pull request. La sélection de Afficher plus de détails (2) sur l’annotation vous dirigera vers la vue détaillée de l’alerte dans l’onglet Sécurité avancée.

Conseil

Les annotations ne seront créées que lorsque les lignes de code affectées sont entièrement uniques à la différence de la pull request.

Résolution des problèmes d’analyse des dépendances

L'analyse des dépendances n'identifie aucun composant

Si la tâche d'analyse des dépendances s'achève sans qu'aucun composant ne soit signalé et sans que des alertes ne soient générées pour les composants présentant des vulnérabilités connues, assurez-vous qu'une étape de restauration des packages a été effectuée avant la tâche AdvancedSecurity-Dependency-Scanning@1.

Par exemple, pour un projet C# (.NET Core), voici un extrait YAML d'exemple :

- task: DotNetCoreCLI@2
  displayName: 'Restore NuGet packages'
  inputs:
    command: 'restore'
    projects: '**/*.csproj'

    # If you are using a private package feed such as Azure Artifacts, you will need additional variables.
    # For more information, see https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/reference/dotnet-core-cli-v2?view=azure-pipelines 
    feedsToUse: 'select'
    ...

- task: AdvancedSecurity-Dependency-Scanning@1

Pour un projet JavaScript, voici un extrait YAML d'exemple :

- task: Npm@1
  displayName: 'npm install'
  inputs:
    command: 'install'
    workingDir: '$(System.DefaultWorkingDirectory)'

- task: AdvancedSecurity-Dependency-Scanning@1

L'analyse de dépendances ne détecte pas de nouvelles vulnérabilités

Si vous lancez une nouvelle build mais que vous ne voyez pas de nouvelles vulnérabilités comme prévu, assurez-vous que la build est exécutée avec un nouveau commit.

Expiration du délai d’attente de la tâche d’analyse des dépendances

Le délai par défaut d'exécution de la tâche d'analyse des dépendances avant l'expiration est de 300 secondes, soit 5 minutes. Si la tâche arrive à expiration avant d'être terminée, vous pouvez définir une variable de pipeline DependencyScanning.Timeout, qui attend un nombre entier représentant les secondes, tel que DependencyScanning.Timeout: 600. Tout ce qui est inférieur au délai d'expiration par défaut de 300 secondes n'a aucun effet.

Pour utiliser cette variable, ajoutez DependencyScanning.Timeout en tant que variable de pipeline :

- task: AdvancedSecurity-Dependency-Scanning@1
- env:
    DependencyScanning.Timeout: 600

Scénario de secours pour la tâche de génération

Si la tâche de génération d’analyse des dépendances bloque l’exécution réussie de votre pipeline et que vous devez ignorer de manière urgente la tâche de génération, vous pouvez définir une variable DependencyScanning.Skip: truede pipeline.

Autorisations de tâche d’analyse des dépendances

La tâche de génération d’analyse des dépendances utilise l’identité de pipeline afin d’appeler les API REST Advanced Security. Les pipelines du même projet ont par défaut accès aux alertes d’extraction. Si vous supprimez ces autorisations à partir du compte de service de build ou si vous avez une configuration personnalisée (par exemple, un pipeline hébergé dans un projet différent du référentiel), vous devez accorder ces autorisations manuellement.

Accordez à Advanced Security: View Alerts l’autorisation au compte de service de build utilisé dans votre pipeline qui est [Project Name] Build Service ([Organization Name]) pour des pipelines délimités par le projet et Project Collection Build Service ([Organization Name]) pour des pipelines délimités par la collection.