ContextQMD
Back to Gitlabhq

Politique de gestion des vulnérabilités

doc-locale/fr-fr/user/application_security/policies/vulnerability_management_policy.md

19.3.011.9 KB
Original Source

{{< details >}}

  • Édition : GitLab Ultimate
  • Offre : GitLab.com, GitLab Self-Managed, GitLab Dedicated

{{< /details >}}

{{< history >}}

  • Introduction de la prise en charge de l'application des politiques sur les projets dans GitLab 17.7 avec un feature flag nommé vulnerability_management_policy_type. Activé par défaut.
  • Introduction de la prise en charge de l'application des politiques sur les groupes dans GitLab 17.8 au niveau du groupe avec un feature flag nommé vulnerability_management_policy_type_group. Activé par défaut.
  • Disponibilité générale dans GitLab 17.9. Les feature flags vulnerability_management_policy_type et vulnerability_management_policy_type_group ont été supprimés.

{{< /history >}}

Utilisez une politique de gestion des vulnérabilités pour résoudre automatiquement les vulnérabilités qui ne sont plus détectées, rejeter automatiquement les vulnérabilités correspondant à des critères spécifiques ou remplacer les niveaux de gravité des vulnérabilités. Cela peut contribuer à réduire la charge de travail liée au triage des vulnérabilités.

Lorsqu'un scanner détecte une vulnérabilité sur la branche par défaut, il crée un enregistrement de vulnérabilité avec le statut Nécessite un classement. Une fois la vulnérabilité corrigée et le prochain scan de sécurité exécuté, le scan ajoute N'est plus détectée au journal d'activité de l'enregistrement, mais le statut de l'enregistrement ne change pas. Vous pouvez changer le statut en Résolue soit manuellement, soit en utilisant une politique de gestion des vulnérabilités.

Les politiques de gestion des vulnérabilités garantissent que les règles sont appliquées de manière cohérente. Par exemple, vous pouvez créer des politiques qui :

  • Résoudre automatiquement les vulnérabilités qui remplissent tous les critères suivants :
    • N'est plus détectée sur la branche par défaut.
    • Détectée par un scan SAST.
    • Risque faible.
  • Rejeter automatiquement les vulnérabilités trouvées dans les fichiers de test avec la raison Utilisation pour des tests.
  • Rejeter les vulnérabilités avec des identifiants CVE spécifiques avec la raison Faux positif.
  • Remplacer (ou modifier) la gravité en critique pour les vulnérabilités correspondant à des modèles CVE spécifiques dans le code de production.

Une politique de gestion des vulnérabilités n'affecte que les vulnérabilités ayant le statut Nécessite un classement ou Confirmée.

La politique de gestion des vulnérabilités est appliquée lorsqu'un pipeline s'exécute sur la branche par défaut ou lorsque des vulnérabilités sont détectées par un scan consultatif.

Lorsque les politiques utilisent la résolution automatique, pour chaque vulnérabilité qui n'est plus détectée par le même scanner et qui correspond aux règles de la politique :

  • L'utilisateur GitLab Security Policy Bot définit le statut de l'enregistrement de vulnérabilité sur Résolue.
  • Une note concernant le changement de statut est ajoutée à l'enregistrement de la vulnérabilité.

Lorsque les politiques utilisent le rejet automatique, pour chaque vulnérabilité correspondant aux critères de la politique :

  • L'utilisateur GitLab Security Policy Bot définit le statut de l'enregistrement de vulnérabilité sur Rejetée.
  • La raison du rejet est définie selon la configuration de la politique.
  • Une note concernant le changement de statut est ajoutée à l'enregistrement de la vulnérabilité.

Les politiques peuvent identifier les vulnérabilités correspondant à un ensemble de critères et remplacer leur gravité :

  • L'utilisateur GitLab Security Policy Bot définit, augmente ou diminue le niveau de gravité, selon la configuration de la politique.
  • Une note concernant le changement de gravité est ajoutée à l'enregistrement de la vulnérabilité.

Pour limiter la charge et la durée du pipeline, un maximum de 1 000 vulnérabilités par pipeline sont traitées pour les actions de résolution automatique ou de rejet automatique. Les actions de résolution automatique ou de rejet automatique reprennent dans les pipelines suivants, jusqu'au maximum, jusqu'à ce que toutes les vulnérabilités correspondantes soient traitées.

Restrictions {#restrictions}

  • Vous pouvez attribuer un maximum de cinq règles à chaque politique.
  • Vous pouvez attribuer un maximum de cinq politiques de gestion des vulnérabilités à chaque projet de politique de sécurité.
  • Lorsqu'un scan de détection des secrets détecte qu'une clé secrète précédemment détectée n'est plus détectée, la vulnérabilité n'est pas résolue automatiquement. Au lieu de cela, elle reste dans Needs Triage car la clé secrète supprimée a déjà été exposée. Le statut de la vulnérabilité ne doit être résolu manuellement qu'après la révocation ou la rotation de la clé secrète.

Politiques de rejet automatique {#auto-dismiss-policies}

{{< history >}}

  • Introduction de la prise en charge des politiques de rejet automatique pour les groupes et tous les projets de ces groupes dans GitLab 18.8 avec un feature flag nommé auto_dismiss_vulnerability_policies. Activé par défaut.
  • Disponibilité générale dans GitLab 18.10. L'indicateur de fonctionnalité auto_dismiss_vulnerability_policies a été supprimé.
  • Introduction de la prise en charge des champs de critères identifier_type et values dans GitLab 18.10 avec un feature flag nommé security_policies_severity_customize. Activé par défaut.
  • En disponibilité générale dans GitLab 19.0. L'indicateur de fonctionnalité security_policies_severity_customize a été supprimé.

{{< /history >}}

Les politiques de rejet automatique prennent en charge les critères suivants :

  • Chemin d'accès au fichier : Correspond aux vulnérabilités en fonction du chemin d'accès au fichier où elles ont été trouvées. Prend en charge les modèles glob comme test/**/*.
  • Répertoire : Correspond aux vulnérabilités trouvées dans des répertoires spécifiques. Prend en charge les modèles glob comme vendor/*.
  • Identifiant : Correspond aux vulnérabilités en fonction de leurs identifiants (CVE, CWE ou identifiants spécifiques au scanner). Prend en charge les modèles avec caractères génériques comme CVE-2023-*.

Les critères d'identifiant prennent également en charge :

  • La spécification d'un type d'identifiant (cve, cwe ou owasp) pour correspondre à des formats d'identifiant spécifiques.
  • L'utilisation d'un tableau values pour faire correspondre plusieurs identifiants avec la logique OR.

Vous pouvez combiner plusieurs critères en utilisant :

  • Logique AND. Pour être rejetée, la vulnérabilité doit correspondre à tous les critères.
  • Logique OR. Pour être rejetée, la vulnérabilité peut correspondre à l'une des règles.

Les raisons de rejet suivantes sont prises en charge :

  • Risque acceptable : La vulnérabilité est connue et acceptée en tant que risque commercial.
  • Faux positif : La vulnérabilité est signalée de manière incorrecte.
  • Contrôle d'atténuation : Une protection équivalente est fournie par d'autres contrôles.
  • Utilisation pour des tests : La vulnérabilité fait partie du code de test ou des données de test.
  • Non applicable : La vulnérabilité se trouve dans du code qui n'est plus mis à jour.

Politiques de remplacement de la gravité {#severity-override-policies}

{{< history >}}

{{< /history >}}

Les politiques qui remplacent la gravité des vulnérabilités utilisent les mêmes critères que les politiques de rejet automatique :

  • Chemin d'accès au fichier : Correspond aux vulnérabilités en fonction du chemin d'accès au fichier où elles ont été trouvées.
  • Répertoire : Correspond aux vulnérabilités trouvées dans des répertoires spécifiques.
  • Identifiant : Correspond aux vulnérabilités en fonction de leurs identifiants.

Pour les critères d'identifiant, vous pouvez éventuellement spécifier un type d'identifiant pour ne correspondre qu'à des formats d'identifiant spécifiques :

  • ID CVE : Correspond aux identifiants CVE tels que CVE-2021-44228 ou aux modèles tels que CVE-2023-*.
  • ID CWE : Correspond aux identifiants CWE tels que CWE-79 ou aux modèles tels que CWE-*.
  • OWASP : Correspond aux identifiants OWASP tels que A1 ou A03:2021.

Les opérations de gravité suivantes sont prises en charge :

  • Set : Définit la gravité sur un niveau spécifique (info, low, medium, high ou critical).
  • Augmenter : Augmente la gravité d'un niveau.
  • Diminuer : Diminue la gravité d'un niveau.

Créer une politique de gestion des vulnérabilités {#create-a-vulnerability-management-policy}

Créez une politique de gestion des vulnérabilités pour résoudre ou rejeter automatiquement les vulnérabilités correspondant à des critères spécifiques.

Prérequis :

  • Par défaut, seuls les propriétaires de groupe, de sous-groupe ou de projet disposent des autorisations requises pour créer ou attribuer un projet de politique de sécurité. Cela peut être modifié en utilisant des rôles personnalisés rôles personnalisés.

Pour créer une politique de gestion des vulnérabilités :

  1. Dans la barre supérieure, sélectionnez Rechercher ou aller à et trouvez votre projet.
  2. Accédez à Sécurisation > Politiques.
  3. Sélectionnez Nouvelle politique.
  4. Dans Politique de gestion des vulnérabilités, sélectionnez Sélectionner la politique.
  5. Renseignez les champs et définissez le statut de la politique sur Activé.
  6. Sélectionnez Créer une stratégie.
  7. Examinez et fusionnez la merge request.

Une fois la politique de gestion des vulnérabilités créée, les règles de la politique sont appliquées aux pipelines sur la branche par défaut.

Modifier une politique de gestion des vulnérabilités {#edit-a-vulnerability-management-policy}

Modifiez une politique de gestion des vulnérabilités pour en changer les règles.

  1. Dans la barre supérieure, sélectionnez Rechercher ou aller à et trouvez votre projet.
  2. Accédez à Sécurisation > Politiques.
  3. Dans la ligne de la politique, sélectionnez Éditer.
  4. Modifiez les détails de la politique.
  5. Sélectionnez Sauvegarder les modifications.
  6. Examinez et fusionnez la merge request.

La politique de gestion des vulnérabilités a été mise à jour. Lors de la prochaine exécution d'un pipeline sur la branche par défaut, les règles de la politique sont appliquées.

Schéma {#schema}

Lorsqu'une politique de gestion des vulnérabilités est créée ou modifiée, elle est vérifiée par rapport au schéma de politique de gestion des vulnérabilités pour confirmer sa validité.