GitLab : 5 façons de corriger les niveaux de gravité trompeurs des vulnérabilités

Un rapport de vulnérabilités d'entreprise typique fait remonter des centaines de résultats à chaque cycle d'analyse, tous classés selon le Common Vulnerability Scoring System (CVSS). Le problème : le CVSS décrit les caractéristiques théoriques d'une vulnérabilité et exposition communes (CVE), et non sa pertinence dans votre environnement. Une vulnérabilité critique dans une bibliothèque utilitaire à usage interne ne représente pas le même risque qu'une vulnérabilité modérée dans un service d'authentification exposé au public. Pourtant, ces deux cas sont traités de manière identique jusqu'à ce que quelqu'un les analyse manuellement. Il est également impossible de mettre à l'échelle ce travail de classement.

Les politiques de gestion des vulnérabilités de GitLab peuvent désormais remplacer automatiquement ces niveaux de gravité CVSS par défaut, selon des conditions que vous définissez : votre rapport de vulnérabilités reflète ainsi votre modèle de risque réel plutôt qu'un modèle générique.

Fonctionnement des politiques de remplacement de la gravité

Une politique de remplacement de la gravité est un type de politique de gestion des vulnérabilités qui ajuste automatiquement les niveaux de gravité des vulnérabilités de chaque pipeline de la branche par défaut. Vous définissez des règles avec des critères de correspondance (identifiant CVE, identifiant CWE, chemin de fichier ou répertoire) et une action de remplacement. Lorsqu'une vulnérabilité correspond, le Security Policy Bot de GitLab met immédiatement à jour sa gravité.

Trois opérations de remplacement sont disponibles :

• Définir la gravité : force la gravité à un niveau précis (information, faible, modéré, élevé ou critique).
• Augmenter la gravité : fait monter la gravité d'un niveau.
• Diminuer la gravité : fait descendre la gravité d'un niveau.

Les remplacements manuels effectués par des utilisateurs autorisés ont toujours la priorité sur les remplacements définis par politique. Chaque modification automatisée est consignée dans l'historique de la vulnérabilité et dans les événements d'audit, ce qui vous garantit une traçabilité complète de ce qui a été modifié et pourquoi.

Cas d'utilisation avec configurations prêtes à l'emploi

Chaque exemple ci-dessous inclut une configuration de politique que vous pouvez copier, personnaliser et appliquer immédiatement.

1. Rétrograder les CVE à faible risque dans les services internes

Les scanners de sécurité ne savent pas quels projets sont des outils internes, des utilitaires de test ou des services en production. Ils évaluent chaque CVE de la même façon, quel que soit le contexte de déploiement. Pour les équipes qui gèrent des tableaux de bord d'administration internes, des outils de développement ou des traitements par lots sans exposition au trafic externe, une vulnérabilité de dépendance classée comme critique ne justifie souvent pas la même réponse que si elle se trouvait dans une API exposée aux clients.

Cette politique diminue la gravité de CVE spécifiques détectées dans les répertoires de services internes :

      vulnerability_management_policy:
  - name: "Downgrade CVEs in internal services"
    description: "Internal-only services have lower exposure risk"
    enabled: true
    rules:
      - type: detected
        criteria:
          - type: identifier
            identifier_type: cve
            values:
              - "CVE-2023-44487"
              - "CVE-2024-29041"
          - type: directory
            value: "internal/**/*"
    actions:
      - type: severity_override
        severity_override_operation: decrease

    

Remplacez les valeurs CVE par les identifiants que votre équipe a évalués comme présentant un risque moindre pour les déploiements internes. L'opération decrease fait baisser la gravité d'un niveau (critique devient élevée, élevée devient modérée), ce qui préserve la priorité relative sans surréagir à des scores inadaptés au contexte.

2. Augmenter la gravité des vulnérabilités d'injection dans le code en production

Certaines catégories de vulnérabilités nécessitent une réponse plus forte lorsqu'elles sont détectées dans le code source en production. Le cross-site scripting, ou XSS (CWE-79), et l'injection SQL (CWE-89) figurent régulièrement parmi les types de vulnérabilités les plus exploités, selon l'Open Web Application Security Project (OWASP) et la base de données des vulnérabilités exploitées connues (Known Exploited Vulnerabilities ou KEV) de l'Agence de cybersécurité et de sécurité des infrastructures (CISA). Si votre scanner signale ces vulnérabilités comme modérées ou élevées dans votre répertoire src/, votre processus de classement doit les traiter comme critiques.

Cette politique définit la gravité à critique pour les résultats XSS et SQLi dans le code en production :

      vulnerability_management_policy:
  - name: "Upgrade XSS and SQLi in production code"
    description: "Injection vulnerabilities in src/ are always Critical"
    enabled: true
    rules:
      - type: detected
        criteria:
          - type: identifier
            identifier_type: cwe
            values:
              - "CWE-79"
              - "CWE-89"
          - type: directory
            value: "src/**/*"
    actions:
      - type: severity_override
        severity_override_operation: set
        severity_override_value: critical

    

Associez cette politique à une politique d'approbation des merge requests qui exige l'approbation de l'équipe de sécurité pour les résultats critiques. La politique de remplacement de la gravité garantit que les bons résultats sont signalés et priorisés dans le rapport de vulnérabilités, tandis que la politique d'approbation s'assure que les nouvelles vulnérabilités détectées ne peuvent pas atteindre la production sans révision.

3. Normaliser la gravité entre les différents scanners

Il arrive que des scanners différents attribuent des niveaux de gravité différents à la même CVE. Votre scanner d'analyse statique de sécurité des applications (SAST) peut évaluer un résultat comme élevé, tandis que l'analyse des dépendances le qualifiera de modéré. Ces incohérences créent de la confusion lors du classement et compliquent la définition de seuils d'approbation cohérents entre les types d'analyse.

Utilisez une politique de remplacement de la gravité pour imposer un niveau de référence cohérent. Si votre équipe de sécurité a évalué une famille de CVE spécifique et déterminé qu'elle doit toujours être élevée quel que soit le scanner, définissez ce paramètre explicitement :

      vulnerability_management_policy:
  - name: "Normalize log4j severity to High"
    description: "Consistent severity for log4j CVEs across all scanners"
    enabled: true
    rules:
      - type: detected
        criteria:
          - type: identifier
            identifier_type: cve
            values:
              - "CVE-2021-44228"
              - "CVE-2021-45046"
              - "CVE-2021-45105"
    actions:
      - type: severity_override
        severity_override_operation: set
        severity_override_value: high

    

Cette approche est particulièrement utile pour les organisations qui utilisent plusieurs types d'analyse (SAST, analyse des dépendances, analyse des conteneurs) et pour lesquelles la même vulnérabilité sous-jacente apparaît avec des évaluations différentes selon la méthode de détection.

4. Aligner la gravité sur les renseignements d'exploitation

Les scores CVSS sont statiques. Ils n'évoluent pas lorsqu'une vulnérabilité commence à être activement exploitée, et ils ne tiennent pas compte de la probabilité d'exploitation réelle. Le score EPSS (Exploit Prediction Scoring System) de FIRST et le catalogue KEV de la CISA fournissent les informations manquantes.

Lorsque vos renseignements sur les menaces indiquent qu'une CVE de gravité modérée est désormais activement exploitée (KEV) ou présente une forte probabilité d'exploitation (score EPSS supérieur à 0,5), utilisez un remplacement de la gravité pour l'augmenter :

      vulnerability_management_policy:
  - name: "Upgrade actively exploited CVEs"
    description: "CVEs in CISA KEV catalog should be treated as Critical"
    enabled: true
    rules:
      - type: detected
        criteria:
          - type: identifier
            identifier_type: cve
            values:
              - "CVE-2024-3094"
              - "CVE-2023-4966"
              - "CVE-2023-22515"
    actions:
      - type: severity_override
        severity_override_operation: set
        severity_override_value: critical

    

Maintenez une liste évolutive des entrées KEV pertinentes pour votre pile et mettez la politique à jour au fur et à mesure que de nouvelles CVE sont ajoutées au catalogue. Vous créez ainsi une boucle de rétroaction entre les renseignements sur les menaces et la gravité visible par les développeurs, sans que les analystes aient à ajuster manuellement chaque résultat.

5. Appliquer des modèles de risque au niveau du groupe dans l'organisation

Les politiques des projets individuels ne sont pas évolutives lorsque votre organisation compte des centaines ou des milliers de projets. Les politiques de remplacement de la gravité peuvent être appliquées au niveau du groupe, ce qui affecte tous les projets du groupe. Combinez-les à policy_scope pour cibler des politiques sur les projets correspondant à un label de framework de conformité spécifique.

Par exemple, une organisation disposant d'un framework de conformité « PCI-DSS » peut imposer un traitement de gravité plus strict pour les vulnérabilités d'injection dans tous les projets à périmètre PCI, tout en appliquant une politique plus légère aux groupes d'outils internes :

      vulnerability_management_policy:
  - name: "PCI projects: upgrade injection severity"
    description: "All injection vulnerabilities are Critical in PCI scope"
    enabled: true
    policy_scope:
      compliance_frameworks:
        - id: 12345
    rules:
      - type: detected
        criteria:
          - type: identifier
            identifier_type: cwe
            values:
              - "CWE-79"
              - "CWE-89"
              - "CWE-78"
              - "CWE-94"
    actions:
      - type: severity_override
        severity_override_operation: set
        severity_override_value: critical

    

Avec ce modèle, l'équipe de sécurité définit le modèle de risque une seule fois pour qu'il s'applique de manière cohérente partout. Aucune configuration par projet. Aucune dépendance vis-à-vis du bon vouloir de chaque équipe pour configurer les choses correctement.

Premiers pas

Suivez ces étapes pour créer des politiques de gestion des vulnérabilités :

1. Identifiez le décalage. Ouvrez votre rapport de vulnérabilités et filtrez par « Nécessite un classement ». Recherchez des schémas : résultats critiques dans du code de test, résultats modérés faisant l'objet d'une exploitation active, évaluations incohérentes entre les types d'analyse.
2. Choisissez un cas d'utilisation. Commencez par le scénario ci-dessus qui couvre le plus grand nombre de résultats incohérents.
3. Définissez votre base de référence. Notez la distribution des gravités avant de créer une politique (nombre de résultats critiques, élevés, modérés dans le périmètre cible).
4. Créez et appliquez une politique. Accédez à Sécurisation > Politiques > Nouvelle politique > Politique de gestion des vulnérabilités. Collez la configuration du cas d'utilisation ci-dessus, puis fusionnez la merge request.
5. Validez les résultats. Après le prochain pipeline de la branche par défaut, vérifiez les gravités mises à jour dans le rapport de vulnérabilités. Filtrez le journal d'activité pour identifier les résultats ajustés et confirmer leur exactitude.

Référence rapide

FAQ

Quelle est la différence entre le rejet automatique et le remplacement de la gravité ? Le rejet automatique supprime les résultats de votre file de classement active. Le remplacement de la gravité les conserve, mais ajuste leur niveau de priorité : ils continuent d'être suivis et examinés avec l'urgence appropriée.

Peut-on combiner des remplacements de gravité avec d'autres types de politiques ? Oui. Les remplacements de gravité s'appliquent aux résultats sur la branche default, ce qui affecte les vulnérabilités apparaissant dans les rapports de vulnérabilités GitLab. Vous pouvez ensuite utiliser des politiques d'approbation des merge requests pour contrôler les nouvelles vulnérabilités détectées.

Les remplacements de gravité s'appliquent-ils rétroactivement aux vulnérabilités existantes ? Oui. Lorsqu'une politique de remplacement de gravité est appliquée, elle traite les vulnérabilités correspondantes dont le statut est « Nécessite un classement » ou « Confirmé » lors du prochain pipeline de la branche par défaut, jusqu'à 1 000 par exécution.

Que se passe-t-il si deux politiques définissent des gravités contradictoires ? Les remplacements manuels ont toujours la priorité. En cas de conflit entre politiques, la politique la plus récente a la priorité. Examinez régulièrement vos politiques pour éviter les critères qui se chevauchent.

Les équipes de développement peuvent-elles contourner les politiques de remplacement de gravité ? Non. Les politiques sont gérées dans un projet de politique de sécurité à accès restreint. Les équipes de développement ne peuvent ni les modifier ni les désactiver. Les utilisateurs autorisés peuvent appliquer des remplacements manuels sur des vulnérabilités individuelles, qui auront la priorité.

Envie de faire en sorte que votre rapport de vulnérabilités reflète les risques réels ? Consultez la documentation sur les politiques de remplacement de la gravité ou démarrez un essai gratuit de GitLab Ultimate pour essayer cette fonctionnalité dès aujourd'hui.