CWEとは？ CVEとの違いや活用例などを解説

サイバーセキュリティ業界においてよく耳にする「脆弱性」。脆弱性にはSQLインジェクションや、クロスサイトスクリプティング、バッファオーバーフローなど多種多様なタイプが存在します。これらの脆弱性の種類を区別することで、開発段階で入り込んだ脆弱性を取り除いたり、脆弱性対処に関する議論を行ったりする上で情報共有がしやすくなります。そこで活用できるのが「CWE」です。本記事ではCWEとは何なのか、よくセキュリティニュースに登場するCVEとは何が違うのか、またどんな場面でCWEが役に立つのかなどについて解説します。

CWEの基本

CWEの概要

CWE（Common Weakness Enumeration）は米国の非営利団体MITREが運営するCWEコミュニティが開発したリストのことで、日本語では「共通脆弱性タイプ」と訳されています。これは、セキュリティに影響を及ぼす可能性のある一般的なソフトウェアやハードウェア等の「弱点（脆弱性）」のタイプを一覧にしたものです。

各弱点のタイプには、以下の例のように「CWE識別子（CWE-ID）」が付与されています。現在、合計940種類（2024年11月現在）の弱点がCWEにリスト化されています。

弱点はソフトウェアやファームウェア、ハードウェア、あるいはサービスコンポーネントの中に存在するもので、ある特定の状況下で脆弱性（vulnerability）を生む可能性のある状態を指します。

多くの場合、弱点は製品の開発中に入り込んでしまいます。しかし、ソフトウェアの開発者やハードウェアの設計者、セキュリティアーキテクトはCWEを活用して脆弱性につながる弱点を知ることで、問題のある製品をデプロイする前にこれらを取り除くことができます。

CWEの歴史

CWEは、セキュリティ上の弱点の種類を識別するための共通の基準を目指したものです。1999年頃から米国政府の支援を受けた非営利団体のMITREが中心となって仕様策定が行われ、2006年3月に最初の原案が公開されました。その後、40を超えるベンダーや研究機関による協力の下で仕様改善や内容拡充が行われ、2008年9月9日にCWEバージョン1.0が公開されています[1]（2024年11月に最新バージョンの4.16がリリース）。

実際に今日のソフトウェアの開発者やセキュリティ研究者は、アーキテクチャ、設計、コード、実装におけるソフトウェアのセキュリティの弱点を除去したり、対処したりするための方法を議論する上で、CWEを共通言語として使っています。

このほかにも、多様な組織や個人がさまざまな理由でCWEを利用することができます。

CWEを用いることのメリット

CWEを使うことのメリットとしては、主に以下の3点が挙げられます[1]。

1. ソフトウェアのアーキテクチャ、デザイン、コードに内在する脆弱性に関して共通の言葉で議論できるようになる。

例えばNISTのNVD、OWASPのTop Ten Project、IPAのJVN iPediaのほか、多数のセキュリティベンダーがCWEを利用して脆弱性情報を提供しています。これにより、組織や個人によって使用する用語が異なる、というような事態を避けることができます。

2. 脆弱性検査ツールなど、ソフトウェアのセキュリティを向上させるためのツールの標準の評価尺度として使用できるようになる。
3. 脆弱性の原因を認識し、脆弱性の低減を行い、再発を防止するための共通の基準として活用できる。

CWEは脆弱性にパッチを当てるユーザーというより、むしろ製品に脆弱性を作り込むのを防ぎたいメーカー（PSIRTチームなど）にとって有益な情報とも言えます。

CWEとCVEの共通点と違い

似たような用語として「CVE」というものを耳にしたことがある方もいるかもしれません。CWEとCVEの共通点や違いは何なのでしょうか。以下の表は、両者の概要や共通点、違いなどについてまとめたものです。

「CWE-1003」については日本語訳も存在

なおCWE-1003は、JVN（*注）に採用される頻度の高い弱点が多く含まれるビュー（View、詳細は後述）であることから、JPCERT/CCのGitHubリポジトリに日本語訳が掲載されています。対象の弱点をより正確にイメージするのにおすすめです。

リポジトリへのリンクは、こちらの記事からご確認いただけます。

（*注：日本で使用されているソフトウェアなどの脆弱性関連情報とその対策情報を提供しているポータルサイト）

CWEの構成要素

CWEの階層構造

CWEでは、弱点タイプが抽象度によって階層構造（親子関係）で分類されています。階層は4つに分かれており、上から順にピラー（Pillar）、クラス（Class）、ベース（Base）、バリアント（Variant）です。上位層に近いほど抽象的な弱点タイプを表し、下位層にいくほど具体的な弱点タイプや個々の弱点を表しています。以下で、実際に特定の弱点タイプの階層構造を見ていきます。

CWEの記載項目

CWE識別子の各ページには、「親ノード」と「子ノード」を含む関連する弱点タイプが「Relationships」としてまとめられています。この情報からその弱点タイプの階層構造（親子関係）を把握することができます。

例えば上図のように、CWE-362（競合状態）の説明ページでは「ChildOf（親ノード）」に691、「ParentOf（子ノード）」に364、366、367、368、421、689、1223、1298とCWE-IDが記載されています。

これらの情報から、この弱点タイプの階層構造は以下のようになります。なお図中の「Composite（コンポジット）」については、後の項目で取り上げます。

※図からわかるように、CWE-IDは必ずしも「Pillar→Class→Base→Variant」という階層構造をとっていません。「Base→Base」といったものなどもあります。

また「Relationships」以外にも、CWE識別子の各ページには以下のような記載項目があります。

• Description（説明）：弱点の概要が説明されている。

• Common Consequences（攻撃による一般的な影響）：情報セキュリティの3要素である完全性（Integrity）、機密性（Confidentiality）、可用性（Availability）に応じて、攻撃によってもたらされる影響が説明されている。

• Potential Mitigations（想定される緩和策）：アーキテクチャ・設計、実装など各フェーズごとに弱点の緩和策が挙げられている。

• Demonstrative Examples（脆弱なコード例）：実際の脆弱なコードを例示し、どのような場面で使われる可能性があるのか等を説明している。

4種類の弱点タイプ

また、CWEでは弱点の種類にID（識別子）を付与するとともに、弱点タイプを4種類に区分しています。具体的にはビュー（View）、カテゴリー（Category）、弱点（Weakness）、複合要因（Compound Element）です。

それぞれについて、以下でご説明します。

• ビュー（View）：ある観点から、いくつかの弱点タイプを選択して集めたものです。例えば、開発者の観点から弱点タイプを集めたビュー（View）にCWE-699、研究者の観点のものにCWE-1000、C言語で作成したソフトウェアに関連するものにCWE-658、Java言語で作成したソフトウェアに関連するものにCWE-660などが割り当てられています。これらは「グループ名」のようなもので、それ自体が弱点タイプを表しているわけではありません。このほかにも、米国立標準技術研究所（NIST）が実際に公表されている脆弱性を考慮し、CWEの中から19個の弱点タイプを選択してNVD（NISTが運営する脆弱性データベース）に掲載した「CWE-635」があります。

NISTが19個の弱点タイプを選択したCWE-635のページ例

• カテゴリー（Category）：共通のテーマの弱点タイプをグループ化したもので、例えばCWE-310の暗号の問題に関連する弱点、CWE-355のユーザインターフェースに関連する弱点がこれに該当します。複数の弱点タイプが集められたものである点はビューと同様ですが、何を基準にグループ化しているかという点が異なります。音楽に例えて言うと、ビューは「今年ヒットした曲」のようなもので、よく売れたものという観点から曲を集めてグループ化しているイメージなのに対し、カテゴリーは「K-pop」「ロック」「洋楽」といったジャンル別に曲をグループ化しているイメージです。

CWE-310（暗号の問題に関連する弱点）のページ例

• 弱点（Weakness）：個々の弱点について表したもので、クラス（Class）、ベース（Base）、バリアント（Variant）の属性が付与されています。

• • クラス（Class）は、最も抽象的な弱点の属性を指します。例えば、CWE-362の「競合状態」がこれに該当します。

• • ベース（Base）は、特定のリソースや技術に依存しない弱点の属性を指します。例えば、CWE-567の「マルチスレッドコンテキスト内の共有データへの非同期アクセス」がこれに該当します。

• • バリアント（Variant）は個々のリソースや技術、コンテキストなどが特定できるような弱点の属性を指します。例えば、CWE-488の「誤ったセッションへのデータ要素の漏えい」がこれに該当します。

• 複合要因（Compound Element）：複数の要因が複合した弱点を表したもので、コンポジット（Composite）とチェーン（chain）の属性が付与されています。

• • コンポジット（Composite）は、複数の弱点が混合して発生する弱点の属性を指します。例えば、CWE-352の「クロスサイトリクエストフォージェリ（CSRF）」がこれに該当します。以下の画像の赤枠で囲った部分のように、コンポジットを構成する各弱点は『Composite Components』としてまとめられています。CWE-352の場合は、CWE-346、CWE-441、CWE-642、CWE-613の4件が合わさって発生する弱点であることがわかります。

• • チェーン（chain）は、ある問題が原因で別の問題が連鎖して発生する弱点の属性を指します。例えば、CWE-680の「整数オーバーフローの発生によるバッファオーバーフロー」がこれに該当します。以下の画像の赤枠で囲った部分のように、連鎖して発生する弱点は『Chain Components』にまとめられています。CWE-680の場合は、CWE-190の弱点を起因としてCWE-680が発生し、CWE-119も連鎖して発生することがわかります。

なお、上記の弱点タイプについて表にまとめたものがこちらです。

代表的なCWE-ID

CWE-IDの例として、ここでは「危険な弱点タイプのトップ25」にランクインしているものを紹介します。このランキングは、CWEの運営元であるMITREが毎年公表しているものです。

以下の表は、2024年のトップ25です。

2024年のトップ2は入れ替わり、1位がクロスサイトスクリプティング（CWE-79）、2位が境界外書き込み（CWE-787）となりました。SQLインジェクション（CWE-89）は2023年と同じく3位にランクインしています。また、2023年にこのトップ25の圏外だった情報漏えい（CWE-200）とリソースの枯渇（CWE-400）が2024年にランキング入りしました。

CWEの活用例

CWEのイメージが掴めてきたところで、ここではどのような人がどのような場面でCWEを使っているのかをご紹介していきます。CWEを使うメリットを知る上で参考になりましたら幸いです。

ソフトウェアの開発者/品質保証エンジニア

＜役割＞

• ソフトウェア開発者：ソフトウェア要件、プロジェクトマネージャからの指示などに従ってソフトウェアを作成/実装する。
• 品質保証エンジニア：ソフトウェアやシステムの品質保証を行うためにテストの設計・実行・管理を行う。

＜CWEを使うと＞

• 先ほど「記載項目」のセクションで紹介したDemonstrative Examples（脆弱なコード例）やPotential Mitigations（想定される緩和策）といったCWEデータを使用することで、検出されたソフトウェアの弱点に対処するための考え得る手順をよりよく理解することができる。
• 弱点を正確な方法で緩和したり、修正したりすることができる。

ハードウェア設計者/検証エンジニア

＜役割＞

• ハードウェア設計者：マイクロエレクトロニクスの分野でハードウェアコンポーネントの作成・統合・検証を行う。
• ハードウェア検証エンジニア：仕様に従ってハードウェアデバイスをテストし評価する責任を負う。

＜CWEを使うと＞

• 検証エンジニアが作成する検証のエビデンスは、ほとんどの場合、さまざまな業界標準に基づいて構築されたセキュリティ要件への準拠をサポートするために使われる。多くの業界標準は、CWEに載っている弱点の情報を使って枠組みを定義している。
• したがって検証エンジニアはCWEデータを使うことで、特定のセキュリティ要件のエビデンスについてより明確に定義することができる。

セキュリティアーキテクト

＜役割＞

• ソフトウェアの統合やプロセスの定義など、安全なソフトウェアやハードウェアのソリューションを高いレベルで設計する。
• 製品全体の目的を考慮するほか、将来配備され、使用されることも踏まえ、製品のすべての側面をセキュリティの観点から適切に設計、保護する。

＜CWEを使うと＞

• より詳細なリスク評価を実施し、より堅牢で脆弱性の少ない製品を提供するのに役立つ。
• 特定の部分によって引き起こされる弱点と、過去のCVEの相関関係を確認することができる。
• レビューされたサービス/アプリケーション/ハードウェアの全体的なセキュリティ体制を改善するために、同じタイプの弱点カテゴリーから他の類似した弱点を事前に特定するのに役立つ。
• 「Operational」ビューを使って、特定の弱点の技術的な情報を確認することができる。例えばCWE-23（相対パストラバーサル）のページの「Operational」ビューを押すと、「Memberships」項目で、この弱点が『OWASP TOP10』の『A01:2021 – Broken Access Control（アクセス制御の不備）』にも載っていることを確認でき、より詳細な検証に必要な手順を実行していくことができる。

セキュリティ研究者/アナリスト

＜役割＞

• 手作業や自動の技術を駆使して弱点を見つけることで、製品にダメージを与える方法を模索し、調査結果をベンダーや一般ユーザーに報告する。

＜CWEを使うと＞

• アーキテクチャや設計、コード、実装におけるソフトウェアのセキュリティの弱点を除去したり、対処したりするための方法を議論する上で、CWEを共通言語として使うことができる。

テクニカルライター

＜役割＞

• 読者が技術的なコンセプト、プロセス、または製品を理解できるようなコンテンツを作る役割を担う。
• 製品に関する文書やプロセスに関する文書、ユーザーインターフェース（UI）のテキスト、技術レポート、ブログ投稿などのプロジェクトに携わる場合がある。
• 技術的な情報をわかりやすく、簡潔で、かつ実用的なコンテンツにすることが目標となる。

＜CWEを使うと＞

• サイバーセキュリティにおけるテクニカルライターにとって、弱点や使われている用語を理解するのに役立つほか、弱点の悪用メカニズムを把握することができるので、レポートやブログ記事、その他セキュリティ関連の正確なコンテンツを執筆する上で助けとなる。
• 弱点がシステムやネットワークにもたらすリスクの危険度を正確に伝えることができ、読者が適切な措置をとることが可能になるほか、リスク緩和もサポートできる。

教育者

＜役割＞

• より安全な製品を設計したり、さらに安全なコードを開発したり、防御手段を定義したりする方法のほか、脆弱性を発見する方法などについて開発者やシステムの設計者を指導する。例えば教師、教授、コンサルタント、または認定プログラムなどが存在する。

＜CWEを使うと＞

• よくあるエラーを製品が提供・運用される前に排除する方法について、開発者を教育・訓練できる。

最後に

上述のように、多種多様な弱点タイプを分類しているCWEは、脆弱性情報を議論・共有する上で役に立つ基準です。さまざまな企業が提供する脆弱性診断ツールなどで利用されているものであるため、ソフトウェアの開発者やセキュリティ研究者、テクニカルライターなど多様なセキュリティ関係者が、製品の開発段階で脆弱性が入り込むのを防いだり、脆弱性情報を把握したりするために活用しています。

自社製品に脆弱性を内在させないためにも、こういった情報を常にチェックしておくことは重要です。弊社マキナレコードでは、CWE情報と併せて最新の脆弱性情報をモニタリングできるサービスなどを提供しています。

ツールのご紹介：VulnDB（Flashpoint）

自社製品の脆弱性への対処には、様々な情報が求められます。例えば、使用するOSSやサードパーティソフトウェアの脆弱性について、ベンダーや製品、バージョンの情報を収集して、影響を評価する必要があります。また、悪用のためのコードが流通しているのであれば、どこに流通しているかを特定し、場合によってはその機能を検証することも必要です。

このような脆弱性に関する様々な情報を蓄積するデータベースに、VulnDBがあります。VulnDBには30万件超の脆弱性が登録されており、この中にはOSSやサードパーティー製品の脆弱性や、CVE/NVDに掲載されない脆弱性も含まれています。情報の質も豊富であり、CWEはもちろん、悪用状況、PoCコードへのリンク、影響を受ける製品やバージョン、脆弱性の発見者、緩和策など、脆弱性の評価に役立つ詳細な分析結果が提供されます。

日本でのVulnDBに関するお問い合わせは、弊社マキナレコードにて承っております。

詳しくは、以下のフォームからお問い合わせください。

参考資料

[1] 2008年9月10日, IPA 独立行政法人 情報処理推進機構, 共通脆弱性タイプ一覧CWE概説