Irreführende CVSS-Scores automatisch korrigieren – 5 Richtlinienmuster

Ein typischer Enterprise-Schwachstellenbericht zeigt pro Scan-Zyklus Hunderte von Findings – alle nach dem Common Vulnerability Scoring System (CVSS) eingestuft. Das Problem: CVSS beschreibt die theoretischen Eigenschaften einer Common Vulnerabilities and Exposures (CVE), nicht ob sie in der eigenen Umgebung relevant ist. Eine kritische Schwachstelle in einer internen Hilfsbibliothek ist nicht dasselbe Risiko wie eine mittlere Schwachstelle in einem öffentlich zugänglichen Authentifizierungsdienst. Trotzdem werden beide identisch behandelt, bis jemand jede einzelne manuell triagiert. Diese Triage-Arbeit skaliert nicht.

GitLab-Schwachstellenmanagement-Richtlinien können diese Standard-CVSS-Schweregrade jetzt automatisch auf Basis selbst definierter Bedingungen überschreiben – sodass der Schwachstellenbericht das tatsächliche Risikomodell widerspiegelt, nicht ein generisches.

Wie Severity-Override-Richtlinien funktionieren

Eine Severity-Override-Richtlinie ist ein Typ von Schwachstellenmanagement-Richtlinie, der Schwachstellen-Schweregrade automatisch bei jeder Default-Branch-Pipeline anpasst. Regeln werden mit Übereinstimmungskriterien (CVE-ID, CWE-ID, Dateipfad oder Verzeichnis) und einer Override-Aktion definiert. Wenn eine Schwachstelle übereinstimmt, aktualisiert GitLabs Security Policy Bot ihren Schweregrad sofort.

Drei Override-Operationen stehen zur Verfügung:

• Set Severity: Erzwingt einen bestimmten Schweregrad (info, low, medium, high oder critical).
• Increase Severity: Erhöht den Schweregrad um eine Stufe.
• Decrease Severity: Senkt den Schweregrad um eine Stufe.

Manuelle Überschreibungen durch autorisierte Nutzende haben stets Vorrang vor Richtlinien-Overrides. Jede automatisierte Änderung wird in der Schwachstellenhistorie und den Audit Events protokolliert – so entsteht eine vollständige Aufzeichnung darüber, was sich wann und warum geändert hat.

Anwendungsfälle mit einsatzbereiten Konfigurationen

Jedes der folgenden Beispiele enthält eine Richtlinienkonfiguration, die direkt kopiert, angepasst und angewendet werden kann.

1. CVEs in internen Diensten herabstufen

Security-Scanner wissen nicht, welche Projekte interne Werkzeuge, Test-Utilities oder Produktionsdienste sind. Sie bewerten jede CVE gleich, unabhängig vom Deployment-Kontext. Für Teams, die interne Admin-Dashboards, Entwicklerwerkzeuge oder Batch-Verarbeitungsjobs betreiben, die nie externen Traffic empfangen, rechtfertigt eine kritisch bewertete Abhängigkeitsschwachstelle oft nicht dieselbe Reaktion wie eine in einer kundenseitigen API.

Diese Richtlinie senkt den Schweregrad bestimmter CVEs in Verzeichnissen interner Dienste:

      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

    

Die CVE-Werte durch die Identifier ersetzen, die das Team für interne Deployments als geringeres Risiko eingestuft hat. Die decrease-Operation senkt den Schweregrad um eine Stufe (Critical wird High, High wird Medium) – relative Prioritäten bleiben erhalten, ohne auf kontextunangemessene Scores überzureagieren.

2. Injektionsschwachstellen in Produktionscode hochstufen

Bestimmte Schwachstellenklassen erfordern eine stärkere Reaktion, wenn sie in Produktionsquellcode gefunden werden. Cross-Site-Scripting (CWE-79) und SQL-Injection (CWE-89) gehören laut OWASP und dem Known Exploited Vulnerabilities (KEV)-Katalog von CISA zu den am häufigsten ausgenutzten Schwachstellentypen. Wenn der Scanner diese Schwachstellen im src/-Verzeichnis als Medium oder High meldet, muss der Triage-Prozess sie als Critical behandeln.

Diese Richtlinie setzt den Schweregrad für XSS- und SQLi-Findings in Produktionscode auf Critical:

      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

    

Diese Richtlinie lässt sich mit einer Merge-Request-Approval-Richtlinie kombinieren, die für Critical-Findings eine Security-Team-Freigabe verlangt. Der Severity Override stellt sicher, dass die richtigen Findings im Schwachstellenbericht markiert und priorisiert werden. Die Approval-Richtlinie stellt sicher, dass neu erkannte Findings die Produktion nicht ohne Review erreichen.

3. Schweregrade über Scanner hinweg normalisieren

Verschiedene Scanner weisen derselben CVE manchmal unterschiedliche Schweregrade zu. Der Static Application Security Testing (SAST)-Scanner meldet ein Finding möglicherweise als High, während Dependency Scanning es als Medium einstuft. Diese Inkonsistenzen erzeugen Verwirrung bei der Triage und erschweren es, konsistente Freigabe-Schwellenwerte über Scanner-Typen hinweg festzulegen.

Eine Severity-Override-Richtlinie erzwingt eine konsistente Ausgangsbasis. Hat das Security-Team eine bestimmte CVE-Familie bewertet und festgestellt, dass sie unabhängig vom Scanner stets High sein sollte, lässt sich das explizit festlegen:

      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

    

Das ist besonders nützlich für Unternehmen, die mehrere Scanner-Typen betreiben (SAST, Dependency Scanning, Container Scanning), bei denen dieselbe zugrundeliegende Schwachstelle je nach Erkennungsmethode mit unterschiedlichen Bewertungen erscheint.

4. Schweregrade an Ausnutzungsintelligenz ausrichten

CVSS-Scores sind statisch. Sie ändern sich nicht, wenn eine Schwachstelle aktiv ausgenutzt wird, und sie berücksichtigen keine reale Ausnutzungswahrscheinlichkeit. FIRSTs Exploit Prediction Scoring System (EPSS) und CISAs KEV-Katalog liefern das fehlende Signal.

Wenn Threat Intelligence zeigt, dass eine Medium-CVE aktiv ausgenutzt wird (KEV) oder eine hohe Ausnutzungswahrscheinlichkeit hat (EPSS über 0,5), lässt sie sich per Severity Override hochstufen:

      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

    

Eine laufend gepflegte Liste der relevanten KEV-Einträge pflegen und die Richtlinie aktualisieren, wenn neue CVEs zum Katalog hinzugefügt werden. So entsteht eine Rückkopplungsschleife zwischen Threat Intelligence und dem entwicklerseitig sichtbaren Schweregrad – ohne manuelle Anpassung jedes einzelnen Findings.

5. Organisationsweite Risikomodelle auf Group-Ebene anwenden

Einzelne Projektrichtlinien skalieren nicht, wenn eine Organisation Hunderte oder Tausende von Projekten hat. Severity-Override-Richtlinien können auf Group-Ebene angewendet werden und betreffen dann jedes Projekt in der Group. In Kombination mit policy_scope lassen sich Richtlinien auf Projekte mit einem bestimmten Compliance-Framework-Label ausrichten.

Eine Organisation mit dem Compliance-Framework "PCI-DSS" kann beispielsweise eine strengere Schweregradbehandlung für Injektionsschwachstellen für alle PCI-relevanten Projekte durchsetzen, während für interne Tooling-Groups eine leichtere Richtlinie gilt:

      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

    

Dieses Muster bedeutet: Das Security-Team definiert das Risikomodell einmalig, und es wird überall konsistent angewendet. Keine projektbezogene Konfiguration. Keine Abhängigkeit davon, dass einzelne Teams sich an die Einrichtung erinnern.

Erste Schritte

So werden Schwachstellenmanagement-Richtlinien erstellt:

1. Die Diskrepanz identifizieren. Den Schwachstellenbericht öffnen und nach „Needs triage" filtern. Nach Mustern suchen: Critical-Findings in Testcode, Medium-Findings mit aktiver Ausnutzung, inkonsistente Bewertungen über Scanner-Typen hinweg.
2. Einen Anwendungsfall wählen. Mit dem Szenario oben beginnen, das die meisten fehlausgerichteten Findings abdeckt.
3. Die Ausgangssituation festhalten. Die Schweregradverteilung vor der Richtlinienerstellung notieren (wie viele Critical-, High-, Medium-Findings im Zielbereich).
4. Erstellen und anwenden. Zu Secure > Policies > New policy > Vulnerability management policy navigieren. Die Konfiguration aus dem obigen Anwendungsfall einfügen, dann den MR mergen.
5. Ergebnisse validieren. Nach der nächsten Default-Branch-Pipeline den Schwachstellenbericht auf aktualisierte Schweregrade prüfen. Das Aktivitätsprotokoll filtern, um zu sehen, welche Findings angepasst wurden, und bestätigen, dass die richtigen betroffen sind.

Kurzreferenz

FAQ

Was ist der Unterschied zwischen Auto-Dismiss und Severity Override?
Auto-Dismiss entfernt Findings aus der aktiven Triage-Warteschlange. Severity Override hält sie sichtbar, passt aber ihre Prioritätsstufe an – sie werden weiterhin verfolgt und mit angemessener Dringlichkeit geprüft.

Lassen sich Severity Overrides mit anderen Richtlinientypen kombinieren?
Ja. Severity Overrides gelten für Findings auf dem default-Branch und betreffen Schwachstellen im GitLab-Schwachstellen-Reporting. Merge-Request- Approval-Richtlinien lassen sich verwenden, um neu erkannte Findings zu kontrollieren.

Gelten Severity Overrides rückwirkend für bestehende Schwachstellen?
Ja. Wenn eine Severity-Override-Richtlinie angewendet wird, verarbeitet sie übereinstimmende Schwachstellen mit dem Status „Needs triage" oder „Confirmed" bei der nächsten Default-Branch-Pipeline – bis zu 1.000 pro Durchlauf.

Was passiert, wenn zwei Richtlinien widersprüchliche Schweregrade setzen?
Manuelle Overrides haben stets Vorrang. Bei Richtlinienkonflikten hat die zuletzt angewendete Richtlinie Vorrang. Richtlinien regelmäßig überprüfen, um überlappende Kriterien zu vermeiden.

Können Entwicklungsteams Severity-Override-Richtlinien umgehen?
Nein. Richtlinien werden in einem Security-Policy-Projekt mit eingeschränktem Zugriff verwaltet. Entwicklungsteams können sie weder ändern noch deaktivieren. Autorisierte Nutzende können manuelle Overrides für einzelne Schwachstellen anwenden, die Vorrang haben.

Schwachstellenberichte, die das tatsächliche Risiko widerspiegeln? Dokumentation zu Severity-Override-Richtlinien lesen oder kostenlose GitLab-Ultimate-Testversion starten.