要約

  • MITREの2002年の進捗報告は、CVEの一般公開を1999年９月、初回の掲載を321件と記録する。目的は既存のツールとデータベースを結ぶ論理的な橋だった。
  • 1999年の設計論文は、N個の脆弱性データベースを相互に結ぶ作業をおよそN²とし、共通索引を使えばN個の対応付けで済むと説明した。深刻度、個別の設定、ツールの性能は索引の仕事から外した。

違う名前では同じ欠陥を追えない

当時のセキュリティー製品は、それぞれ独自の脆弱性データベースを持っていた。スキャナーの警告とソフトウェアの公告が同じ問題を指すかどうか、名称だけでは分からない。MITREの原論文は、この不一致が製品比較や検出結果の突き合わせを難しくすると述べた。診断件数を増やしても、同一性を確認する橋がなければ作業は進まない。

そこで必要とされたのは、全ツールを作り直すことではなかった。各問題に固有の名前と、他の問題と見分けられる短い説明を付ける。それぞれのデータベースがその名前に自分の項目を対応させれば、他のすべての製品に個別の翻訳表を作らずに済む。N²対Nという比較は脆弱性の数ではなく、情報源を接続する負担の差を示した。

設計者たちは巨大な共通分類体系も作らなかった。1999年の文章はCVEを対照表または索引と呼ぶ。危険度や分類方法は各データベースが自分の目的に応じて決められる。共有部分を細くしたからこそ、異なる製品が同じ名前を使える余地が生まれた。

番号は危険度の点数ではない

CVEの形式には接頭辞と年と数字が入る。しかし原論文は、数字が発見順や深刻度を意味しないと明記した。ある機械に対象ソフトウェアがあるか、設定によって攻撃可能か、検出ツールが適切に扱ったかも番号からは分からない。共通の呼び名と現場のリスク評価は別の仕事だ。

その呼び名を付ける過程には判断が要った。候補に暫定的なCAN番号を与え、編集委員会が正式なCVE項目にするか審査する。1999年の手順には、重複による却下、記述の修正、複数報告の統合、一件を分ける判断が含まれる。「一つの欠陥」をどこで区切るかは、単純な採番プログラムだけでは決められなかった。

2002年のMITRE報告が振り返る公開初日の321件は、既存の商用ツールに代わる診断器ではなく、論理的な橋の最初の板だった。スキャナーが番号を出し、製品提供者が同じ番号で更新情報を示せば、運用者は二つの記録を結べる。実際の版を調べて、適切な修正を適用し、動作を確認する作業はそこで始まる。

321という数は最初の公開項目数だ。世界の全欠陥数でも、修復済み機械の数でもない。CVEは三枚の異なる診断票に同じ傷を指さす場所を与えた。傷を直す手は、別の現場に残された。