Единственная запись, где обе оценки совпадают, — это именно та, где вендор сам подал CVSS в NVD.

Причина не в том, что кто-то что-то скрывает: когда вендор не подаёт оценку, CISA-ADP автоматически выставляет её по наихудшему сценарию, а большинство SCA-инструментов берут именно значение из NVD. Это не баг, а две разные методики оценки — но ваш процесс реагирования построен на 9.8.

И второе: версия, на которую велит обновиться вендор, может быть просто недоступна для скачивания

Проверено на практике (с положительным контролем, перезапускается при каждой генерации таблицы правил):

В таблице исправлений вендора эти версии помечены как Enterprise Support Only — только для клиентов с платной коммерческой поддержкой. Так что если вы действительно затронуты, ваш выбор: обновление через мажорную версию или покупка коммерческой поддержки.

Использование

Требуется JDK 17+. Ноль зависимостей в рантайме, без обращения к сети.

Коды выхода:0 версия не затронута · 2 версия затронута, но условия срабатывания не найдены · 3 условия срабатывания также выполнены.

Как выглядит вывод

Обратная сторона — почему остальные 7 записей не расходятся

По таблице выше легко решить, что «NVD всегда выставляет оценки как попало». Это не так. В том же наборе данных есть ещё 7 записей, где оценка вендора и оценка NVD полностью совпадают:

Контрпримеров нет ни в одном из направлений — это единственный причинно-следственный вывод, на который осмеливается этот инструмент:

• 7 записей с совпадающими оценками → источник оценки во всех случаях — [email protected] (подано самим вендором)
• 8 записей с расходящимися оценками → источник оценки во всех случаях — CISA-ADP (вендор не подавал, оценку автоматически выставила третья сторона по наихудшему сценарию)

Скрипт генерации следит за обоими направлениями двумя отдельными утверждениями (ASSERT4 / ASSERT7); при появлении любого контрпримера отказывается выдавать таблицу.

🔑 Зачем проверять оба направления: утверждение «все совпадающие — самооценка вендора» не исключает, что некоторые расходящиеся тоже самооценка вендора. Если бы такая запись реально появилась, у причинно-следственной связи был бы контрпример, а при проверке лишь одного направления таблица всё равно бы сгенерировалась и осталась полностью «зелёной». Одностороннее утверждение не доказывает причинно-следственную связь.

Методика — пожалуйста, дочитайте до конца, прежде чем делать выводы

• «Не затронуто» не равно «безопасно». Условия срабатывания могут находиться в сторонних библиотеках, от которых вы зависите, задаваться переменными окружения или конфигурационным центром, а возможно, вы просто не передали каталог исходников. В отчёте всегда говорится «не найдено в ваших исходниках», а не «вы не затронуты».
• Покрываются только перечисленные выше четыре партии, всего 15 записей — это не полноценный сканер уязвимостей и не замена SCA.
• В покрытие входит линия Spring Framework 5.3 (OSS-поддержка завершена 2024-08-31, финальная версия 5.3.39). Запуск на spring-core-5.3.39.jar затронет 11 записей, и ни одной исправляющей версии от вендора для этих 11 записей нет в публичном Maven Central (5.3.45 / 5.3.49 / 5.3.50 — все помечены Enterprise Support Only).
• Только сопоставление текста, без AST. Это осознанный компромисс: критический путь обязан быть читаемым и проверяемым вручную — ошибку в непонятном решении никто не заметит.
• Расхождение оценок — объективное наблюдение, это не «вендор что-то скрывает» и не «NVD сообщает наугад».

Откуда данные / как проверить самостоятельно

Таблица правил генерируется скриптом tools/gen_rules.py из четырёх первоисточников, без ручного копирования:

Повторный запуск — это повторная проверка:

В скрипте шесть утверждений; при провале любого из них таблица не выдаётся, три из них напрямую следят за утверждениями этого инструмента:

• ASSERT2 число записей с расхождением вендор⟷NVD — если обнулится, значит, утверждение устарело; немедленная остановка
• ASSERT3 проверка Central с положительным контролем — если контроль не проходит, вся партия 404 аннулируется
• ASSERT4 у совпадающей записи источник оценки обязан быть самооценкой вендора — это единственное доказательство «причины»

License

Apache-2.0