両者が一致する唯一のケースこそ、ベンダーが自ら NVD に CVSS を提出したケースです。

原因は誰かが隠しているわけではありません:ベンダーがスコアを提出しない場合、CISA-ADP が最悪ケースで自動採点し、多くの SCA ツールは NVD の数値を採用します。 これはバグではなく、2 つの評価体系それぞれの基準の違いです —— しかし、あなたのインシデント対応フローは 9.8 を前提に動いています。

もう一つの問題:公式が指定するアップグレード先が、そもそもダウンロードできない可能性がある

実測(陽性対照付き、ルール表生成のたびに再実行):

公式の Fix version 表では、これらのバージョンは Enterprise Support Only とマークされています —— 商用サポートを購入した顧客のみ対象です。 つまり、実際に該当する場合の選択肢は:メジャーバージョンアップグレード、または商用サポートの購入です。

使い方

JDK 17+ が必要です。実行時依存ゼロ、オフライン動作。

終了コード:0 バージョン非該当 · 2 バージョン該当だがトリガー条件が見つからない · 3 トリガー条件も成立。

出力例

逆側の検証 —— なぜ他の 7 件は差異がないのか

上の表を見ると「NVD は常にいい加減なスコアを付ける」と思われがちです。違います。 同じデータセットには他に 7 件あり、 公式評価と NVD 評価が完全に一致しています:

どちらの方向にも反例はありません、これがこのツールが唯一断言できる因果関係です:

• 7 件評価一致 → スコアソースはすべて [email protected](ベンダー自身が提出)
• 8 件評価不一致 → スコアソースはすべて CISA-ADP(ベンダー未提出、第三者による最悪ケースの自動採点)

生成スクリプトは 2 つのアサーションでそれぞれの方向を監視します(ASSERT4 / ASSERT7)、いずれかに反例が出れば表の生成を拒否します。

🔑 なぜ両方向を検証するのか:「一致するものはすべてベンダー自己評価」という命題は、「不一致の一部もベンダー自己評価である」可能性を排除しません。 実際にそのようなエントリが現れた場合、因果関係に反例が生じますが、片方向のみの検証では表は生成され、すべて緑のままになります。 片方向のアサーションでは因果関係を証明できません。

基準 —— 結論を出す前に最後までお読みください

• 「非該当」は「安全」を意味しません。 トリガー条件は依存するサードパーティライブラリ内にある可能性があり、環境変数や設定センターから配信される可能性もあり、 単にソースディレクトリを渡していないだけかもしれません。レポートの表現は常に「あなたのソースコードには見つからなかった」であり、「影響を受けない」ではありません。
• 上記の 4 バッチ、合計 15 件のみをカバーしており、全量の脆弱性スキャナではなく、SCA の代替にはなりません。
• カバレッジには Spring Framework 5.3 系が含まれます(2024-08-31 に OSS サポート終了、最終版 5.3.39)。 spring-core-5.3.39.jar で実行すると 11 件に該当しますが、この 11 件について公式が指定する修正版は 公開 Maven Central には 1 つも存在しません(5.3.45 / 5.3.49 / 5.3.50、すべて Enterprise Support Only とマーク)。
• テキストマッチングのみで、AST は行いません。これは意図的なトレードオフです:重要なパスは人間が読んで自分で検証できる必要がある —— 理解できない判定は、誤りがあっても誰も気づけません。
• 評価の差異は客観的な読み取り値であり、「公式が隠している」のでも「NVD がいい加減」なのでもありません。

データの出所 / 自分で検証する方法

判定表は tools/gen_rules.py が4 つの一次ソースから生成します。手作業の転記はありません:

再実行すれば再検証になります:

スクリプトには6 つのアサーションがあり、失敗すれば表の生成を拒否します。うち 3 つはこのツールの主張を直接監視しています:

• ASSERT2 公式⟷NVD 不一致の件数 —— ゼロになれば主張が無効になった証拠なので、即座に停止
• ASSERT3 Central プローブは陽性対照付き —— 対照が通らなければ、そのバッチの 404 はすべて無効
• ASSERT4 一致するケースのスコアソースはベンダー自己評価でなければならない —— これが「因果関係」の唯一の証拠

License

Apache-2.0