CVEを民間部門に引き渡せ

出典：Warakorn Hamprasop／Alamy Stock Photo

オピニオン

Common Vulnerability Enumeration（CVE。現在はCommon Vulnerabilities and Exposuresの略称として呼ばれる）は、そもそも実際には存在していなかった空白を埋めるために、1999年に作られた。 

CVEの取り組みは、David MannとSteve Christey-Coleyが執筆した「Towards a Common Enumeration of Vulnerabilities,」というホワイトペーパーから生まれた。この論文の要旨は、脆弱性の「共通の列挙（common enumeration）」が必要だという点にある。しかし、すでに1年以上前から、広範囲をカバーする公開の脆弱性データベース（VDB）が存在していたことを見落としている。 

CVEの開始時点で、ISS（後にIBMが買収）は、1997年8月の時点で完全に公開されたVDBを維持していた。私が共同創業に関わったRepent Security Inc.も、1998年の初頭から中頃にかけて、VDBの商用サブスクリプションを提供していた。 

それ以前にも脆弱性をカタログ化しようとする取り組みはあったが、いずれも網羅性にはばらつきがあり、もちろん完全に包括的なものはなかった。MITREが新たなVDBを望んだことは、古典的な標準に関するXKCDのコミックを想起させる。 

当初のCVEホワイトペーパーは、脆弱性に対する一貫した命名方式の必要性を強調し、バグの同一性が追跡しにくくなる例として次を挙げている。「例えば、1991年に発見されたある脆弱性は、推測可能なファイルハンドルを介してNFSファイルシステムへの不正アクセスを可能にした」とホワイトペーパーは述べる。「ISS X-Force Databaseではこの脆弱性はnfs-guessとラベル付けされ、CyberCop Scanner 2.4ではNFS file handle guessing checkと呼ばれ、同じ脆弱性が（他の脆弱性とともに）CERT Advisory CA-91.21でも特定されている。これはSunOS NFS Jumbo and fsirand Patchesというタイトルである。」 

これらのバグを追跡するために共通点を探すには、個々人が脆弱性の説明文を読み比べるしかなく、それはすぐに負担が大きくなり、誤りも生じやすくなる、と同論文は主張する。 

見落としがちだが、この説明にはかなりの皮肉が含まれている。というのも、彼ら自身がそれをISS X-Force 77に明確に相互参照しているわけでもなく、またISSがCERTやSunへリンクしており、彼らが切実に必要だと言う相互参照を提供していることにも触れていないからだ。この例は、別の目的も果たしている。最終的にCVE-1999-0167が公開されることを考えると、それはISSにしかリンクしておらず、彼らの例の土台であるCERTやSunにはリンクしていない。 

1999年9月の開始時点で、CVEのレコードは321件で、当時知られていた3,700件超の脆弱性のごく一部にすぎなかった。26年前の当時でさえ、MITREがVDB運用の世界でいかにうまくやれないか、その舞台はすでに整っていたように思える。

MITREの欠陥ある連邦CVEプログラム資金モデル 

MITREは、連邦政府資金による研究開発センター（FFRDC）として、プロジェクトの資金提供を受けている。MITREのようなFFRDCは、契約の付与方法を規定する米国政府の規則に従う。彼らの利点の一つは、政府契約としては比較的まれな、入札なし・競争なしの契約を得られることが多い点だ。一定の基準を満たすはずの契約を政府に提案し、受け入れられれば、他の企業が競争できない形で仕事を得る。これこそが、MITREが長年にわたりCVE契約を享受できた理由であり、客観的に見て平凡以下の実績にもかかわらず、契約が続いてきた。

連邦規則集（Code of Federal Regulations）第48編「連邦調達規則（Federal Acquisition Regulations）システム」は、MITREがこの種の契約で従うべき規則群の一つであり、特に第35部「研究開発契約（Research and Development Contracting）」が該当する。契約の募集（35.007）、授与のための評価（35.008）、そして特にFFRDCに関する条項（35.017）には、CVE契約はそもそも授与されるべきではなかったと主張できるだけの文言がある。 

MITREへの資金提供の基準には、「斬新なアイデア（novel ideas）」を有すること、「特定分野で最高の能力（highest competence）」を持つこと、「特別な能力（special competency）」を持つこと、そして「既存の社内リソースや請負業者のリソースでは満たせない」業務を行うことが含まれる。

私は弁護士でも政府規則の起草者でもないが、これらの点を一般人として解釈すれば、CVEは斬新なアイデアではなく、創設者たちが当時の他者より特別に専門的だったわけでもなく、また当時であればそのような取り組みは無償で得られたか、ISSを通じて契約することもできたはずだ、と強く示唆していると私は主張したい。

第48編の別の規定として、35.017-4条に基づき、契約スポンサー（この場合はサイバーセキュリティ・インフラストラクチャ安全保障庁（CISA））は、契約を延長する前にレビューを実施することが求められる。35.017-4(c)によれば、レビューの一部には「代替リソースの検討（consideration of alternative resources）」や、「スポンサーのニーズを満たすための…効率性と有効性の評価（assessment of the efficiency and effectiveness for … meeting the sponsor’s needs）」が含まれるべきであり、さらにFFRDCが「客観性（objectivity）…迅速な対応能力（quick response capability）、専門分野における最新性（currency）」を維持していることも含まれる。重要なのは、CISAがFFRDCが「費用対効果の高い運用（cost-effective operation）」を行っているかどうかを評価する義務がある点だ。

さらに、政府運営の国防調達大学（Defense Acquisition University）によれば、「FFRDCが任務を遂行するには、FFRDCとスポンサーの間に特別な関係が存在する必要がある」。その一覧は概ね上記と一致するが、もう一つ加わる。「適応性（Adaptability）— スポンサーの新たなニーズに対応し、将来の重大な課題を予見する能力」。

これは、MITREがCVEプログラム運営でまさに失敗してきた点と、なぜ不足しているのかを列挙したリストのように読める。MITREが客観的ではないと受け取られてきた事例は歴史的に数多くあり、その傾向は今日に至るまで続いている。 

MITREには迅速な対応能力がない。研究者はCVE IDの割り当てを受けるまでに、数日、数週間、数カ月、さらには数年待たされる。私が1993年以来、何らかの形でVDBを管理してきた経験に基づけば、MITREとCVEチームのリーダーが脆弱性データベース管理の分野で専門性を持たない（少なくともそう主張できる）理由を説明するには、まったく別の連載記事が必要になるだろう。 

この話題はCVE Boardで2017年の時点ですでに議論されていたにもかかわらず、クラウド／Software-as-a-Service（SaaS）の脆弱性に対する割り当て方針をMITREがようやく採用したのは2024年になってからだった。これは「適応性」や「将来の重大な課題」を予見するという基準を満たしているとは到底言えない。

最後に、費用対効果の高い運用も考慮事項であり、MITREはプログラム初期からその点で失敗してきた。 

2004年から2005年にかけて、MITREはCVEプログラム運営のために約500万ドルを受け取っており、当時としても理解に苦しむ金額だった。コミュニティ主導のデータベースであるOSVDBは、はるかに多くの脆弱性をカタログ化でき、しかも費用はそのごく一部で済んでいた。2024/2025年に話を進めると、その資金は驚愕の2,900万ドルへと爆発的に増えた。 Jerry Gamblinは計算を行い、「契約期間中に公開された43,625件のCVEそれぞれに対して、MITREは664.01ドルを受け取った」と結論づけた。

2011年以来、商用VDBに携わってきた者として、あの費用のごく一部で、より優れたデータベースを運用できると断言できる。MITREの実績とCVEへの資金提供を踏まえると、政府説明責任局（GAO）は二つの問いを投げかけなければならないと私は考える。第一に、MITREは脆弱性データベースを運営するFFRDCとしての要件を満たしているのか。第二に、より高い成果を出す商用／契約の代替手段が存在する2026年において、そもそもFFRDCが必要なのか。GAOは結局のところ、「詐欺、浪費、濫用、そして不適切な管理」を調査する任務を負う機関なのだから。