Schwachstellen-Rauschen mit Auto-Dismiss-Richtlinien gezielt reduzieren

Security-Scanner sind unverzichtbar – doch nicht jeder Fund erfordert eine Reaktion. Testcode, eingebettete Abhängigkeiten, generierte Dateien und bekannte False Positives erzeugen Rauschen, das die tatsächlich relevanten Schwachstellen überlagert. Durch das manuelle Schließen immer gleicher, irrelevanter Findings über Projekte und Pipelines hinweg entsteht repetitiver Aufwand im Security-Team. Die Folge: langsameres Triage, Alert-Fatigue und Reibung mit Entwicklungsteams – bis hin zu sinkender Akzeptanz des Security-Scannings selbst.

Mit den Auto-Dismiss-Richtlinien für Schwachstellen lassen sich Triage-Entscheidungen einmalig in Richtlinien festlegen und automatisch auf jede Pipeline des Standard-Branches anwenden. Kriterien werden anhand von Dateipfad, Verzeichnis oder Schwachstellen-Kennung (CVE, CWE) definiert, ein Abweisungsgrund festgelegt – und GitLab übernimmt den Rest.

Warum Auto-Dismiss?

Auto-Dismiss-Richtlinien ermöglichen Security-Teams:

• Triage-Aufwand reduzieren: Findings in Testcode, eingebetteten Abhängigkeiten und generierten Dateien werden automatisch abgewiesen.
• Entscheidungen organisationsweit durchsetzen: Bekannte False Positives lassen sich zentral über die gesamte Organisation hinweg abweisen.
• Prüfnachweise sicherstellen: Jeder automatisch abgewiesene Fund enthält einen dokumentierten Abweisungsgrund mit Verweis auf die auslösende Richtlinie.
• Datenbasis erhalten: Im Gegensatz zu Scanner-Ausschlüssen verbleiben abgewiesene Schwachstellen im Report – Entscheidungen lassen sich bei veränderten Bedingungen jederzeit überprüfen.

So funktionieren Auto-Dismiss-Richtlinien

1. Richtlinie definieren: In einer YAML-Richtliniendatei Abgleichkriterien (Dateipfad, Verzeichnis oder Kennung) und einen Abweisungsgrund festlegen.
2. Zusammenführen und aktivieren: Richtlinie über Secure > Policies > New policy > Vulnerability management policy erstellen. Nach dem Merge des MR ist sie aktiv.
3. Pipeline ausführen: Bei jeder Pipeline des Standard-Branches werden übereinstimmende Schwachstellen automatisch auf „Dismissed" gesetzt und mit dem festgelegten Grund versehen. Pro Ausführung werden bis zu 1.000 Schwachstellen verarbeitet.
4. Ergebnis prüfen: Den Vulnerability-Report nach Status „Dismissed" filtern – so lässt sich nachvollziehen, welche Findings bereinigt wurden und ob die richtigen Einträge erfasst werden.

Anwendungsfälle mit einsatzbereiten Konfigurationen

Jedes Beispiel enthält eine Richtlinienkonfiguration, die direkt kopiert, angepasst und eingesetzt werden kann.

1. Schwachstellen in Testcode abweisen

SAST- und Dependency-Scanner melden hartcodierte Zugangsdaten, unsichere Fixtures und entwicklungsspezifische Abhängigkeiten in Testverzeichnissen. Diese stellen kein Produktionsrisiko dar.

      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. Eingebetteten und Drittanbieter-Code abweisen

Schwachstellen in vendor/, third_party/ oder eingecheckten node_modules werden upstream verwaltet und sind für das eigene Team nicht direkt behebbar.

      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. Falsch-Positiv-CVEs abweisen

Bestimmte CVEs werden wiederholt gemeldet, gelten im eigenen Nutzungskontext aber als nicht zutreffend. Bisher wurden diese bei jedem Auftreten manuell abgewiesen. Die Beispiel-CVEs unten durch eigene ersetzen.

      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. Generierten und automatisch erstellten Code abweisen

Protobuf-, gRPC-, OpenAPI-Generatoren und ORM-Scaffolding-Tools erzeugen Dateien mit gemeldeten Mustern, die vom eigenen Team nicht gepatcht werden können.

      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. Durch Infrastruktur abgemilderte Schwachstellen abweisen

Schwachstellenklassen wie XSS (CWE-79) oder SQL-Injection (CWE-89), die durch WAF-Regeln oder Laufzeitschutz bereits adressiert sind. Diese Konfiguration nur einsetzen, wenn die abmildernden Kontrollen nachweislich vorhanden und durchgängig durchgesetzt sind – eine lückenhafte Durchsetzung macht die Abweisung ungültig.

      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. CVE-Familien organisationsweit abweisen

Bei einer Welle verwandter CVEs für eine weit verbreitete Bibliothek, die das Team bereits bewertet hat: Richtlinie auf Gruppenebene anwenden und über Dutzende Projekte hinweg abweisen. Das Wildcard-Muster (z. B. CVE-2021-44*) erfasst alle CVEs mit diesem Präfix.

      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

    

Kurzübersicht

Erste Schritte

So lassen sich Auto-Dismiss-Richtlinien einrichten:

1. Rauschen identifizieren: Den Vulnerability-Report öffnen und nach „Needs triage" sortieren. Nach Mustern suchen: Testdateien, eingebetteter Code, CVEs, die in mehreren Projekten wiederholt auftauchen.
2. Anwendungsfall auswählen: Mit dem Anwendungsfall beginnen, der die meisten Findings abdeckt.
3. Ausgangslage festhalten: Anzahl der Schwachstellen mit Status „Needs triage" vor Erstellung der Richtlinie notieren.
4. Erstellen und aktivieren: Über Secure > Policies > New policy > Vulnerability management policy navigieren. Konfiguration aus dem gewählten Anwendungsfall einfügen, dann MR mergen.
5. Ergebnis validieren: Nach der nächsten Pipeline des Standard-Branches den Report nach Status „Dismissed" filtern und prüfen, ob die erwarteten Findings erfasst wurden.

Vollständige Konfigurationsdetails in der Dokumentation zu Vulnerability-Management-Richtlinien.

GitLab Ultimate kostenlos testen und erste Auto-Dismiss-Richtlinie konfigurieren.