CWE-1000は脆弱性じゃない⁉ CWEが直感的に分かりにくい理由

CRAでは、デジタル要素を備えた製品を市場に提供する時点で、既知の悪用可能な脆弱性がないことが求められています。また、IEC 62443-4-1やJIS T 81001-5-1でも、既知の脆弱性の検出・評価・修正を含む、製品ライフサイクルを通じた脆弱性管理が求められています。こうした活動において、CWEの活用は有効な手段の一つです。

CodeSonarをはじめ、多くの静的解析ツールでは、検出を行うチェッカー（ワーニングクラス）とCWE IDとのマッピングが提供されています。しかし、静的解析ツールでCWEに関連する問題を検出しても、実際の検出内容とCWE IDの説明がうまく結び付かないと感じたことがある方も少なくないのではないでしょうか。

CWEは、MISRA C/C++やSEI CERT C/C++ Coding Standardなどのコーディングガイドラインとは異なる性質を持っています。本項では、直感的には理解しにくいCWEの概要を改めて整理し、CWEを有効に活用するための情報を提供します。

1. CWEの定義

CWEはCommon Weakness Enumerationのアクロニムであり、日本語では「共通脆弱性タイプ」と呼ばれています。

IPAは、CWEを「ソフトウェアにおけるセキュリティ上の弱点（脆弱性）の種類を識別するための共通の基準」と説明しています。

IPA：共通脆弱性タイプ一覧CWE概説

IPAの説明を読むと、「CWEはソフトウェアの脆弱性を分類した一覧なのだろう」と理解するかもしれません。この理解は完全な誤りではありませんが、CWEの対象をソフトウェアだけに限定してしまう点では不正確です。

CWEの公式サイトでは、CWEを次のように定義しています。

First, we should describe what CWE is. CWE is a community-developed list of common software and hardware weakness types that could have security ramifications. A “weakness” is a condition in a software, firmware, hardware, or service component that, under certain circumstances, could contribute to the introduction of vulnerabilities. Weakness conditions are in many cases introduced by the developer during development of the product.

CWE：New to CWE

CWEは、ソフトウェア、ファームウェア、ハードウェア、サービスコンポーネントなどに存在し、一定の条件下で脆弱性の発生に寄与し得る「Weakness（弱点）」のタイプを整理した一覧です。これは、ソフトウェアだけに限定されたものではありません。

ここで重要なのは、CWEが列挙しているのは個別製品で確認された脆弱性そのものではなく、脆弱性につながり得る弱点の種類だという点です。それぞれのエントリには、CWE-120やCWE-284のようなCWE IDが付与されています。

2. CWEの役割

上述のとおり、CWEは、ソフトウェアやハードウェアなどに存在するセキュリティ上の弱点を分類・識別するための体系です。その多くは、特定のプログラミング言語や特定の実装方法だけに焦点を当てたものではありません。したがって、CWEはコーディング規約ではありません。

CWEは、MISRA C/C++やSEI CERT C/C++ Coding Standardと同列に語られることがありますが、両者は目的と粒度が異なります。CWEは、脆弱性につながり得る弱点の種類を分類するための体系です。一方、MISRA C/C++やSEI CERT C/C++ Coding Standardは、実装時に守るべき具体的なルールや推奨事項を示すコーディング規約です。

3. CWEとCVEの関係

CWEとCVEは、名前が似ているため違いが分かりにくいかもしれません。

CVEはCommon Vulnerabilities and Exposuresのアクロニムであり、日本語では「共通脆弱性識別子」と呼ばれています。CVEは、個別製品などで確認された具体的な脆弱性を識別するために採番される識別子です。

一方、CWEは、その脆弱性の原因や性質に関係する弱点の種類を分類するために使われます。そのため、CVEを具体的な事例、CWEをその原因・性質を表す抽象的な分類と捉えることができます。

Weakness（弱点）とVulnerabilities（脆弱性）は何が違うのかと疑問に思うかもしれません。製品に弱点が存在し、それが悪用可能な状態になると、具体的な脆弱性として発見されることがあります。CVEはその具体的な脆弱性を識別するためのものであり、CWEは脆弱性につながった弱点の種類を表します。つまり、CVEが具体であり、CWEが抽象となります。

たとえば、CVE-2014-0160は、Heartbleedと呼ばれるOpenSSLの脆弱性です。

NVD：CVE-2014-0160

NVDのページでは、Weakness EnumerationとしてCWE-125が関連付けられています。

CWE-125：Out-of-bounds Read

これは、Heartbleedという個別の脆弱性が、メモリ境界外のデータを読み取ることが可能な状態という弱点に起因していたことを示しています。CWEは個別の脆弱性そのものではなく、その脆弱性につながった弱点の種類を表すものです。そのため、「製品の中にCWE-125という個別の脆弱性が存在する」という意味ではありません。

実際の運用では、まず個別の脆弱性が発見され、その根本原因や弱点の性質を分析した後にCWE IDが関連付けられることがあります。因果関係としては弱点が脆弱性の発生に寄与していますが、識別・登録の時系列ではCVEの公開後にCWEマッピングが追加される場合もあります。

4. CWEの構造

IPAはCWEの構造を以下のように説明しています。

CWEでは多種多様な脆弱性の種類を脆弱性タイプとして分類し、それぞれにCWE識別子（CWE-ID）を付与して階層構造で体系化しています。上位層に近いほど抽象的な脆弱性タイプを表し、下位層にいくほど具体的な脆弱性タイプや個々の脆弱性を表しています。

脆弱性タイプは、ビュー（View）、カテゴリー（Category）、脆弱性（Weakness）、複合要因（Compound Element）の4種類に分類されます。

IPA：共通脆弱性タイプ一覧CWE概説

コーディング規約、たとえばMISRAでは、各Ruleはそれぞれ具体的な実装上の要求事項を示します。Ruleごとに対象や重要度は異なりますが、いずれも開発者が実装時に従うべきルールとして提示されています。それに対してCWEでは、同じCWE ID形式の中に、役割や抽象度が異なるエントリが混在しています。 この点が、CWEを直感的に理解しにくくしている大きな理由です。

たとえば、次の2つを比較します。

• CWE-1000：Research Concepts
• CWE-120：Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')

CWE-1000はViewタイプのエントリです。CWE-1000自体は、個別の弱点や脆弱性を説明するものではありません。CWEに登録されているWeaknessを、挙動の抽象度や相互関係に基づいて整理した全体マップです。一方、CWE-120はWeaknessタイプかつBaseレベルのエントリです。入力サイズを確認せずにバッファーへコピーするという、比較的具体的な弱点パターンを説明しています。

CWE-1000とCWE-120は、見た目は単なるID違いに見えます。しかし、CWE-1000は整理・ナビゲーションのためのViewであり、CWE-120は弱点の種類を表すWeaknessです。役割も粒度も大きく異なります。

さらに、CWE-1000はマップとして階層的な関係を持ち、子要素や孫要素が用意されています。なお、すべてのViewがCWE-1000と同じ階層構造を持つわけではありません。Viewによっては、特定の観点に基づいてエントリを一覧化する構成もあります。

2026年8月3日時点で最新のCWE v4.20では、CWE-1000の直下にあるPillarレベルのWeaknessとして、次の10個のCWE IDが用意されています。

• CWE-284：Improper Access Control
• CWE-435：Improper Interaction Between Multiple Correctly-Behaving Entities
• CWE-664：Improper Control of a Resource Through its Lifetime
• CWE-682：Incorrect Calculation
• CWE-691：Insufficient Control Flow Management
• CWE-693：Protection Mechanism Failure
• CWE-697：Incorrect Comparison
• CWE-703：Improper Check or Handling of Exceptional Conditions
• CWE-707：Improper Neutralization
• CWE-710：Improper Adherence to Coding Standards

PillarはWeaknessの中で最も抽象度の高いレベルです。たとえば、次のCWE IDを見てみましょう。

CWE-284：Improper Access Control

CWE-284は、「製品が、許可されていない主体からのリソースへのアクセスを制限しない、または誤って制限する」というアクセス制御全般の弱点を表します。CWE-284の下位にはClassやBaseなどのWeaknessが関連付けられており、より具体的な弱点へと展開されています。ただし、CWE全体が必ずPillar → Class → Base → Variantという一本道で構成されているわけではありません。Weakness間の関係は、対象となる技術や整理の観点によって異なります。

この関係をグラフ化したものが以下の図です。

CWE-284

下図の枠内をドラッグするとスクロールします。同様に枠内でマウスホイールを回転すると図が拡大・縮小します。

繰り返しになりますが、CWE IDはすべて同じ抽象度を表すものではありません。

CWE-1000は、ソフトウェアを中心としたResearch Conceptsの観点から、CWEに登録されているWeaknessを技術的な抽象度や相互関係に基づいて整理したViewです。

一方、次のCWEもViewタイプですが、異なる目的を持ちます。CWE-1194は、ハードウェア設計に関連するWeaknessを、ハードウェア設計者が利用しやすい観点で整理したViewです。

CWE-1194：Hardware Design

さらに、次のCWE-1399はCategoryタイプのエントリです。Categoryは、特定のテーマや共通点に基づいてWeaknessをまとめるための組織化エントリです。

CWE-1399：Comprehensive Categorization: Memory Safety

ただし、CategoryはPillar → Class→ Base → Variantという抽象度の階層の一段ではありません。たとえば、CWE-1006「Bad Coding Practices」というCategoryは、Class、Base、Variantなど、異なる抽象度のWeaknessを直接まとめています。

つまりCategoryは、「Viewより抽象度が低く、Pillarより高い」という階層上の一段ではなく、抽象度の階層とは別軸でWeaknessを整理するためのものです。イメージとしてはタグやフォルダーに近いものですが、CWE上では独立したID、説明、メンバーシップを持つ正式な組織化エントリです。また、Category自体はWeaknessではないため、個別の脆弱性の根本原因を表すCWEとして直接マッピングする対象ではありません。

以上のことから、CWE IDは大別すると、以下のような構造になります。件数はCWE v4.20時点です。

Weaknessは、さらにAbstraction属性によって以下のように分類されます。

これらは、それぞれユニークなCWE IDを持っています。

CWE IDはすべてが同じ種類の項目を表しているわけではありません。ViewやCategoryのような整理・ナビゲーション用のエントリと、Weaknessを表すエントリが同じCWE ID形式で採番されています。さらに、WeaknessにもPillar、Class、Base、Variant、Compoundという抽象度や性質の違いがあります。

備考

すべてのPillarは、CWE-1000の子要素として配置されています。この関係をグラフ化したものが以下の図です。

CWE-1000

下図の枠内をドラッグするとスクロールします。同様に枠内でマウスホイールを回転すると図が拡大・縮小します。

5. CWEの利用

CRA、IEC 62443-4-1、JIS T 81001-5-1は、対象製品や適用範囲、要求事項の表現がそれぞれ異なりますが、いずれも製品ライフサイクルを通じたセキュリティ上のリスク管理や脆弱性管理を重視しています。

このような活動において、CWEは、想定すべき弱点を整理し、設計・実装・検証の観点を共有するための有効な手段となります。ただし、CWEを利用すること自体が、既知の脆弱性が存在しないことの証明になるわけではありません。

セキュリティを考慮した開発では、脅威分析の段階で、想定される攻撃手法、悪用シナリオ、セキュリティ上の失敗状態などを整理します。その際、関連するViewや上位レベルのWeaknessを、探索の起点として利用できます。

開発工程が仕様策定、設計、実装へと進む中で、想定する欠陥メカニズムや利用技術が明確になった場合は、可能であればBaseまたはVariantレベルのWeaknessまで絞り込みます。ただし、すべての上位CWEに適切な下位CWEが存在するとは限りません。また、Pillar→Class→Base→Variantの順に必ず一本道で具体化できるわけでもありません。対象となる技術や分析目的に応じて、適切なWeaknessを選択する必要があります。

静的解析ツールでは、各チェッカーが検出するコード上の問題にCWE IDが対応付けられていることがあります。そのため、対象とするCWEに関連するチェッカーを選定することで、実装レベルの弱点を検査できます。しかし、チェッカーとCWEの対応は、以下のように必ずしも1対1ではありません。

• 1つのチェッカーが複数のCWEに関連する場合がある
• 同じCWEでも、静的解析ツールごとに検出対象や検出条件が異なる場合がある
• 抽象度の高いCWEが、複数の具体的なチェッカーに対応付けられている場合がある
• CWEに関連する弱点であっても、静的解析だけでは検出できない場合がある

したがって、CWE対応表だけを見て検査の十分性を判断するのではなく、各チェッカーの検出条件、対象言語、解析方式、制約などを確認する必要があります。また、静的解析には限界があります。動的解析、ファジング、ペネトレーションテスト、設計レビュー、ソフトウェア構成分析、手動レビューなども組み合わせ、脆弱性につながり得る弱点を多面的に検出・評価することが重要です。

CWE IDを読む際には、番号や名称だけで判断せず、そのエントリがView、Category、Weaknessのどれであるかを確認してください。Weaknessの場合は、どのAbstractionに属するかも確認する必要があります。

これが、静的解析ツールの検出内容とCWEの説明を正しく対応付け、CWEを開発・検証活動で有効に活用するための第一歩となります。

より詳しく技術や​関連製品について​知りたい方へ

本コラムに関係する技術や関連する製品について知りたい方は、お気軽にご相談ください。

お問い合わせはこちらから