NATOとAIセキュリティ企業AISLEがCVE採番機関（CNA）に — ENISA Root傘下は20機関へ拡大

2026年8月6日、EUサイバーセキュリティ機関 ENISA（エニサ） は、NATOの通信情報機関（NCIA） とAI脆弱性管理企業 AISLE（エール） が、CVE番号制度の採番機関 CNA に加わったと発表した。2機関はENISAが運営する「ENISA Root」傘下に参加し、ENISA Root傘下のCNAは計20機関（ENISAが直接参画させた12機関＋MITRE Rootから移行した8機関）になった。

CVE・CNA・Rootとは

CVE（Common Vulnerabilities and Exposures） は、公開されたソフトウェアの脆弱性に付与される世界共通の識別番号（例: CVE-2026-XXXXX）だ。政府機関、ベンダー、研究者が同じ番号で脆弱性を指し示せるようにするための制度で、脆弱性情報の追跡や対策情報の共有の基盤になっている。

この番号を発行する権限を持つ組織を CNA（CVE Numbering Authority、CVE採番機関） と呼ぶ。セキュリティベンダーやソフトウェアメーカー、各国の機関がCNAとして参加し、自社製品や担当領域で発見された脆弱性に番号を割り当てる。

CNAの管理・育成を担う上位組織が Root だ。これまでCVE制度は米国の非営利団体 MITRE が中心となって運営してきたが、2025年11月、ENISAが欧州の機関・団体を対象とするCVE Rootに認定された。制度の運営は複数のRootによる体制に移行しつつある。

なぜ今、体制を変えるのか

ENISAの最高サイバーセキュリティ・運用責任者（Chief Cybersecurity and Operations Officer）Hans de Vries氏は、今回の拡大の背景について次のように述べている。

「世界のサイバーセキュリティ環境の最近の動向と、脆弱性の発見・悪用に影響を与えるフロンティアAIモデルの出現は、強固な脆弱性管理インフラと能力を構築する必要性を浮き彫りにしている」

AIによるコード生成や脆弱性調査が進むにつれ、発見される脆弱性の数と速度は増すことが見込まれる。番号を発行する機関を増やし、地域ごとに処理能力を分散させることで、制度全体の拡張性と回復力を高める狙いがある。

NATO（NCIA）: 国際同盟組織としてCNAに

NATO側は、NATO Communications and Information Agency（NCIA） の一部である NATOサイバーセキュリティセンター（NCSC） がCNAとして登録された（2026年8月5日付のNCIA発表）。NCSCはNATOのネットワーク防衛やインシデント対応を担う組織で、NATO組織内で発見された対象脆弱性にCVE IDを付与できるようになったとされる。

政府・軍事組織のセキュリティ運用と、公的な脆弱性情報の枠組みが結び付いた形で、ENISAは一貫した運用と信頼できる調整を通じて、欧州・国際レベルでの脆弱性管理を推進する狙いだとしている。

AISLE: 自社製品に直接CVE IDを発行

もう1つのAISLEは、AIによる脆弱性の検出から修正までを支援する「AIネイティブな脆弱性ライフサイクル管理」を手がける企業だ（本拠: サンフランシスコとプラハ）。2026年7月22日、自社製品で発見した脆弱性にCVE IDを直接発行できるCNAに指定されたと発表していた。

従来は自社製品の脆弱性でも、他機関のCNAに発行を依頼して待つ必要があった。CNAになることで、情報公開までの時間を短縮し、顧客への脆弱性情報の提供を迅速化できる。共同創業者でCISOのJaya Baloo氏は「協調的な情報開示はサイバーセキュリティで最も重要な仕事の1つであり、それは自社製品を、他人に求めるのと同じ基準で扱うことから始まる」と述べている。

AISLEはこれまでに、OpenSSL、Linux、Apache、OpenEMRなど、広く使われるオープンソースソフトウェアで数百件の脆弱性を報告してきた実績がある。AIが脆弱性発見のペースを速める中で、信頼できる調整と迅速な開示の重要性は増すと同社はみている。

日本への影響

CVE IDは日本でも広く使われている。JPCERT/CC（日本のコンピュータ緊急対応調整機関） はCNAとして活動し、国内ベンダーの多くも自社製品向けにCVE IDを発行している。JVN（Japan Vulnerability Notes） やIPAの脆弱性情報にもCVE IDが併記されるのが一般的だ。

今回のENISA Rootの拡大は欧州での出来事だが、CVE制度の運営が「米国（MITRE）中心」から多極化する流れの一環だ。世界共通の識別子を前提にした脆弱性管理（JVNやNVDの参照、パッチ管理など）を運用する日本の組織にとっても、無関係な話ではない。今後もRootやCNAの増加が続けば、脆弱性情報の公開元や公開タイミングがさらに多様化する可能性がある。

今、何をすべきか

1. 脆弱性管理プロセスでCVE IDを追跡する — 採用している製品の脆弱性情報（JVN、NVD、ベンダーアドバイザリ）をCVE IDで管理し、パッチ適用の優先順位付けに使う
2. 重要製品のベンダーの開示体制を確認する — ベンダーがCNAとして迅速に情報公開しているかは、サプライチェーンリスクの評価材料になる
3. AI時代の脆弱性増加に備える — AIによるコード生成・脆弱性調査の普及で、開示される脆弱性の数と速度は増える見込み。パッチ適用プロセスの自動化や優先順位付けの仕組みを検討する
4. 制度の変化を追う — CVE制度の運営体制（Rootの増加、採番機関の拡大）は今後も変わり得る。情報源としてCVE.orgやENISAの発表をフォローする

CVE番号は、脆弱性という「世界共通の言語」の辞書だ。採番の担い手が増えることは、その辞書の信頼性と速さを高める取り組みと言える。

出典: ENISA — ENISA scales up its role in the CVE Program（2026年8月6日） / NCIA — NCIA enhances cooperation on cybersecurity vulnerability management（2026年8月5日） / AISLE — AISLE Named a CVE Numbering Authority（2026年7月22日）