Réduire les faux positifs à grande échelle grâce aux politiques de rejet automatique

Les scanners de sécurité sont indispensables, mais tous les résultats ne nécessitent pas une intervention. Le code de test, les dépendances embarquées, les fichiers générés et les faux positifs connus créent une couche qui masque les vulnérabilités critiques. Les équipes de sécurité perdent des heures à rejeter manuellement les mêmes résultats non pertinents d'un projet et d'un pipeline à l'autre. Résultat : le classement prend plus de temps, une lassitude face aux alertes s'installe et les frictions avec les équipes de développement compromettent l'adoption des scans de sécurité.

Les politiques de rejet automatique des vulnérabilités de GitLab vous permettent de codifier vos décisions de classement une seule fois et de les appliquer automatiquement à chaque exécution du pipeline sur la branche par défaut. Définissez des critères basés sur le chemin de fichier, le répertoire ou l'identifiant de vulnérabilité (vulnérabilités ou expositions communes – CVE, CWE), choisissez un motif de rejet et laissez GitLab faire le reste.

Pourquoi utiliser les politiques de rejet automatique ?

Les politiques de rejet automatique des vulnérabilités permettent aux équipes de sécurité :

• D'éliminer les faux positifs du classement : rejetez automatiquement les résultats dans le code de test, les dépendances embarquées et les fichiers générés.
• D'appliquer des décisions à grande échelle : déployez des politiques centralisées pour rejeter les faux positifs connus dans l'ensemble de votre organisation.
• De garantir la transparence des audits : chaque résultat rejeté automatiquement inclut un motif documenté et un lien vers la politique qui l'a déclenché.
• De conserver l'historique : contrairement aux exclusions de scanners, les vulnérabilités rejetées restent dans votre rapport, ce qui vous permet de réexaminer vos décisions si les conditions évoluent.

Fonctionnement des politiques de rejet automatique

1. Définissez votre politique dans un fichier YAML de politique de gestion des vulnérabilités. Indiquez les critères de correspondance (chemin de fichier, répertoire ou identifiant) et un motif de rejet.
2. Fusionnez et activez. Créez la politique via Sécurisation > Politiques > Nouvelle politique > Politique de gestion des vulnérabilités. Fusionnez la merge request pour l'activer.
3. Exécutez votre pipeline. À chaque exécution du pipeline sur la branche par défaut, les vulnérabilités correspondantes se voient automatiquement attribuer le statut « Rejeté » avec le motif indiqué. Jusqu'à 1 000 vulnérabilités sont traitées par exécution.
4. Mesurez l'impact. Filtrez votre rapport de vulnérabilités avec le statut « Rejeté » pour voir exactement ce qui a été traité et vérifier que les bons résultats sont pris en charge.

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

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

1. Rejeter les vulnérabilités du code de test

Les scanners de test statique de sécurité des applications (SAST) et de dépendances signalent des identifiants codés en dur, des données de test non sécurisées et des dépendances de développement dans les répertoires de test. Ces résultats ne représentent pas des risques en production.

      vulnerability_management_policy:
  - name: "Dismiss test code vulnerabilities"
    description: "Auto-dismiss findings in test directories"
    enabled: true
    rules:
      - type: detected
        criteria:
          - type: file_path
            value: "test/**/*"
      - type: detected
        criteria:
          - type: file_path
            value: "tests/**/*"
      - type: detected
        criteria:
          - type: file_path
            value: "spec/**/*"
      - type: detected
        criteria:
          - type: directory
            value: "__tests__/*"
    actions:
      - type: auto_dismiss
        dismissal_reason: used_in_tests

    

2. Rejeter le code tiers et embarqué

Les vulnérabilités dans les répertoires vendor/, third_party/ ou node_modules versionnés sont gérées en amont, et votre équipe ne peut pas y toucher.

      vulnerability_management_policy:
  - name: "Dismiss vendored dependency findings"
    description: "Findings in vendored code are managed upstream"
    enabled: true
    rules:
      - type: detected
        criteria:
          - type: directory
            value: "vendor/*"
      - type: detected
        criteria:
          - type: directory
            value: "third_party/*"
      - type: detected
        criteria:
          - type: directory
            value: "vendored/*"
    actions:
      - type: auto_dismiss
        dismissal_reason: not_applicable

    

3. Rejeter les CVE identifiées comme faux positifs

Certaines CVE sont signalées de manière récurrente, mais ne s'appliquent pas à votre contexte d'utilisation. Les équipes les rejettent manuellement à chaque apparition. Remplacez les CVE de l'exemple ci-dessous par les vôtres.

      vulnerability_management_policy:
  - name: "Dismiss known false positive CVEs"
    description: "CVEs confirmed as false positives for our environment"
    enabled: true
    rules:
      - type: detected
        criteria:
          - type: identifier
            value: "CVE-2023-44487"
      - type: detected
        criteria:
          - type: identifier
            value: "CVE-2024-29041"
      - type: detected
        criteria:
          - type: identifier
            value: "CVE-2023-26136"
    actions:
      - type: auto_dismiss
        dismissal_reason: false_positive

    

4. Rejeter le code créé et généré automatiquement

Les générateurs Protobuf, gRPC, OpenAPI et les outils de génération automatique de structure de code ORM produisent des fichiers contenant des motifs signalés que votre équipe ne peut pas corriger.

      vulnerability_management_policy:
  - name: "Dismiss generated code findings"
    description: "Generated files are not authored by us"
    enabled: true
    rules:
      - type: detected
        criteria:
          - type: directory
            value: "generated/*"
      - type: detected
        criteria:
          - type: file_path
            value: "**/*.pb.go"
      - type: detected
        criteria:
          - type: file_path
            value: "**/*.generated.*"
    actions:
      - type: auto_dismiss
        dismissal_reason: not_applicable

    

5. Rejeter les vulnérabilités atténuées par l'infrastructure

Cette politique concerne les classes de vulnérabilités telles que XSS (CWE-79) ou l'injection SQL (CWE-89) déjà couvertes par des règles WAF ou une protection au niveau de l'exécution. N'utilisez cette politique que lorsque les contrôles d'atténuation sont vérifiés et appliqués de manière systématique.

      vulnerability_management_policy:
  - name: "Dismiss CWEs mitigated by WAF"
    description: "XSS and SQLi mitigated by WAF rules"
    enabled: true
    rules:
      - type: detected
        criteria:
          - type: identifier
            value: "CWE-79"
      - type: detected
        criteria:
          - type: identifier
            value: "CWE-89"
    actions:
      - type: auto_dismiss
        dismissal_reason: mitigating_control

    

6. Rejeter des familles de CVE dans l'ensemble de votre organisation

Votre équipe a déjà évalué une série de CVE liées à une bibliothèque très répandue ? Appliquez la politique au niveau du groupe pour les rejeter dans des dizaines de projets. Le motif générique (par exemple, CVE-2021-44*) correspond à toutes les CVE avec ce préfixe.

      vulnerability_management_policy:
  - name: "Accept risk for log4j CVE family"
    description: "Log4j CVEs mitigated by version pinning and WAF"
    enabled: true
    rules:
      - type: detected
        criteria:
          - type: identifier
            value: "CVE-2021-44*"
    actions:
      - type: auto_dismiss
        dismissal_reason: acceptable_risk

    

Référence

Premiers pas

Voici comment définir vos premières politiques de rejet automatique :

1. Identifiez les faux positifs. Ouvrez votre rapport de vulnérabilités et triez par « Nécessite un classement ». Recherchez des tendances : fichiers de test, code tiers, la même CVE dans plusieurs projets.
2. Choisissez un scénario. Commencez par le cas d'utilisation ci-dessus qui couvre le plus grand nombre de résultats.
3. Enregistrez votre référence initiale. Notez le nombre de vulnérabilités avec le statut « Nécessite un classement » avant de créer une politique.
4. Créez et activez. 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 la prochaine exécution du pipeline sur la branche par défaut, filtrez par statut « Rejeté » pour confirmer que les bons résultats ont été traités.

Pour tous les détails de configuration, consultez la documentation sur les politiques de gestion des vulnérabilités.

Vous souhaitez maîtriser la gestion des faux positifs liés aux vulnérabilités ? Démarrez un essai gratuit de GitLab Ultimate et configurez votre première politique de rejet automatique dès aujourd'hui.