CWEとは
（原因分類：設計改善に効く）

CVEとの違い

ここは最初に分けて理解すると楽です。

NVDの脆弱性詳細ページでは、Weakness Enumeration としてCWEが表示され、NVDはCWE-1003（公開脆弱性の簡易マッピング向けの見方）を使ってCWEを関連付けていると説明しています。
つまり実務では、「CVEで案件を追い、CWEで原因傾向を見る」と整理すると分かりやすいです。

なぜ「設計改善に効く」のか

MITREの Root Cause Mapping Guidance は、CWEを使う価値として、脆弱性の根本原因を見える化し、投資・ポリシー・開発実務を原因レベルで改善できること を挙げています。

たとえば、毎回別のCVE（CVE-A、CVE-B、CVE-C...）に見えても、CWEで見るとすべて「CWE-79（クロスサイトスクリプティング）」や「CWE-20（不適切な入力確認）」といった同じ原因に集約されることがあります。

サプライヤー実務では、OEM照会への回答だけで終わらせず、再発防止の設計改善につなげるための分類として使うのが本筋です。

CWEの“粒度”は4段階ある

CWEには抽象度の違いがあります。MITREのFAQや用語集では、主に次の4段階で説明されています。

実務上は、Base や Variant の方が再発防止に使いやすいです。

MITREの root cause mapping guidance でも、公開脆弱性の根本原因マッピングでは、可能なら Base / Variant を優先し、Class は必要時に使うのが望ましいと説明しています。

よくある誤解

• 1. CWEは深刻度スコアではない

  CWEは「原因分類」であって、CVSSのような点数ではありません。優先順位付けは、CWE単独ではなく CVSS、対象版数、到達性、VEX と合わせて考えます。

• 2. CWEが分かればトリアージが完了するわけではない

  CWEは「どう直すか」「何が再発しやすいか」のヒントにはなりますが、その製品に影響するか は別問題です。影響評価には対象版数や構成確認が必要です。

• 3. Category と Weakness を混同しない

  MITREの用語集では、Category は関連項目をまとめる“箱”であり、Pillar/Class/Base/Variant のような Weakness そのもの とは違うと整理されています。

サプライヤー実務での使いどころ

CWEは、次のような場面で特に役立ちます。

• OEMから「なぜ起きたのか（根本原因）」を聞かれた時
• 同系統の不具合が繰り返されている時（再発防止策を練る時）
• 設計レビューやセキュアコーディングのチェックリストを改善したい時
• 脆弱性対応を“その場しのぎ”で終わらせたくない時

つまり、CWEは 説明責任の言葉であると同時に、設計改善の言葉 でもあります。
CVE対応を毎回の火消しで終わらせず、原因の型に寄せて改善する時に効きます。

---

FAQ：CWEとは