Der einzige Eintrag, bei dem beide übereinstimmen, ist genau der, bei dem der Hersteller selbst den CVSS-Score bei NVD eingereicht hat.

Die Ursache ist keine Verschleierung: Wenn der Hersteller keinen Score einreicht, vergibt CISA-ADP automatisch eine Bewertung nach dem Worst Case, und die meisten SCA-Tools übernehmen den NVD-Wert. Das ist kein Bug, sondern die jeweilige Methodik zweier Bewertungssysteme — aber dein Incident-Response-Prozess richtet sich nach 9.8.

Und die zweite Sache: Die vom Hersteller empfohlene Upgrade-Version ist möglicherweise gar nicht herunterladbar

Praxistest (mit Positivkontrolle, wird bei jeder Generierung der Regel-Tabelle erneut ausgeführt):

In der offiziellen Fix-Version-Tabelle sind diese Versionen als Enterprise Support Only markiert — nur für Kunden mit kommerziellem Support. Wenn du also tatsächlich betroffen bist, hast du zwei Optionen: Upgrade über die Major-Version hinweg oder Kauf des kommerziellen Supports.

Verwendung

Erforderlich: JDK 17+. Keine Laufzeitabhängigkeiten, keine Netzwerkverbindung.

Exit-Codes: 0 Version nicht betroffen · 2 Version betroffen, aber keine Auslösebedingungen gefunden · 3 Auslösebedingungen ebenfalls erfüllt.

Wie die Ausgabe aussieht

Die andere Seite — warum die anderen 7 Einträge nicht abweichen

Die obige Tabelle könnte den Eindruck erwecken, dass „NVD immer falsch bewertet". Das stimmt nicht. In denselben Daten gibt es 7 weitere Einträge, bei denen die Herstellerbewertung und die NVD-Bewertung exakt übereinstimmen:

In beide Richtungen gibt es keine Gegenbeispiele — das ist das einzige kausale Urteil, das dieses Tool wagt:

• 7 Einträge mit übereinstimmender Bewertung → Score-Quelle ist ausnahmslos [email protected] (vom Hersteller selbst eingereicht)
• 8 Einträge mit abweichender Bewertung → Score-Quelle ist ausnahmslos CISA-ADP (Hersteller hat nichts eingereicht, Dritter bewertet automatisch nach Worst Case)

Das Generierungsskript überwacht beide Richtungen mit zwei Assertions (ASSERT4 / ASSERT7); sobald ein Gegenbeispiel auftritt, wird die Tabellenerstellung verweigert.

🔑 Warum beide Richtungen prüfen: Die Aussage „Übereinstimmende sind immer herstellereingereicht" schließt nicht aus, dass auch einige Abweichende herstellereingereicht sein könnten. Würde ein solcher Eintrag auftauchen, hätte die Kausalität ein Gegenbeispiel — und bei nur einseitiger Prüfung würde die Tabelle trotzdem generiert und bliebe komplett grün. Eine einseitige Assertion beweist keine Kausalität.

Methodik — Bitte vollständig lesen, bevor du Schlüsse ziehst

• „Nicht betroffen" bedeutet nicht „sicher". Die Auslösebedingungen könnten in einer von dir abhängigen Drittanbieter-Bibliothek liegen, per Umgebungsvariable oder Konfigurationszentrale ausgeliefert werden, oder du hast schlicht kein Quellcode-Verzeichnis übergeben. Der Bericht formuliert immer „nicht in deinem Quellcode gefunden", nicht „du bist nicht betroffen".
• Abgedeckt sind nur die oben aufgeführten vier Chargen mit insgesamt 15 Einträgen — kein Vollsortiment-Vulnerability-Scanner, kein Ersatz für SCA.
• Die Abdeckung umfasst auch die Spring-Framework-5.3-Linie (OSS-Support endete am 2024-08-31, letzte Version 5.3.39). Ein Lauf mit spring-core-5.3.39.jar trifft 11 Einträge, und für keinen dieser 11 Einträge existiert die vom Hersteller angegebene Fix-Version auf dem öffentlichen Maven Central (5.3.45 / 5.3.49 / 5.3.50, alle als Enterprise Support Only markiert).
• Es wird nur Textabgleich durchgeführt, kein AST. Das ist eine bewusste Abwägung: Kritische Pfade müssen für Menschen lesbar und selbst überprüfbar sein — eine unverständliche Erkennung, die Fehler macht, würde niemand bemerken.
• Bewertungsunterschiede sind objektive Messwerte, kein „der Hersteller verheimlicht etwas" und kein „NVD meldet Unsinn".

Woher die Daten stammen / Wie du selbst prüfen kannst

Die Bewertungstabelle wird von tools/gen_rules.py aus vier Primärquellen generiert, nicht handschriftlich:

Ein erneuter Lauf ist eine erneute Überprüfung:

Das Skript enthält sechs Assertions; schlagen sie fehl, wird die Tabellenerstellung verweigert. Drei davon prüfen direkt die Kernaussagen dieses Tools:

• ASSERT2 Anzahl der Einträge mit Abweichung Hersteller⟷NVD —— geht sie auf null zurück, ist die Kernaussage widerlegt; sofortiger Stopp
• ASSERT3 Central-Erkennung mit Positivkontrolle —— schlägt die Kontrolle fehl, sind alle 404-Ergebnisse dieser Charge ungültig
• ASSERT4 Bei übereinstimmenden Einträgen muss die Score-Quelle der Hersteller selbst sein —— das ist der einzige Beleg für die „Ursache"

License

Apache-2.0