LLMは脆弱性の根本原因からセキュア設計パターンを導けるか
公開日
セキュリティ
ソフトウェア開発におけるセキュリティ対策は、リリース後に発見された脆弱性を修正する対症療法的なアプローチに偏りがちです。しかし、多くの脆弱性は実装の些細な不具合ではなく、初期のアーキテクチャ設計における構造的な不備に起因しています。攻撃者の戦術や手法を踏まえ、設計段階で適切な防御構造を組み込む「セキュア・バイ・デザイン（Secure by Design）」の重要性が高まっています。
本記事では、ハダースフィールド大学のMariyam Zehra氏による研究「Secure Software by Design from an Adversary Perspective」をもとに、脅威インテリジェンスとセキュア設計パターンを体系的に結びつける枠組みと、大規模言語モデル（LLM）が設計段階のセキュリティ推論をどの程度再現できるかを評価した実験結果を解説します。
攻撃者視点と設計原則を統合する研究の背景と実験設計
本研究は、攻撃者の行動情報であるMITRE ATT&CK、攻撃パターンであるCAPEC、および脆弱性の分類であるCWE（Common Weakness Enumeration）を連携させ、SaltzerとSchroederの8つのセキュリティ原則やSEI CERTのセキュア設計パターンへと変換するフレームワークを提案しています。
実験では、脅威インテリジェンスに関連付けられたハードウェア関連の脆弱性23件（サンプルA）と、関連付けのないソフトウェア固有の脆弱性23件（サンプルB）の計46件のCWEを選定しました。専門家4名によるレビューを経て作成された基準データに対し、3つのLLM（NotebookLM、ChatGPT、Claude 3.5 Sonnet）に同一の脆弱性情報をゼロショットで与え、適切な原則違反と設計パターンを特定できるかを比較検証しています。
専門家検証で示された設計パターンの合意性と原則解釈の幅
研究者が作成したマッピング基準について、4名の独立したセキュリティ専門家による検証が行われました。その結果、緩和策となるセキュア設計パターンの選定については、46件すべてにおいて100％の合意が得られました。
一方で、違反している基本原則の特定については80.4％（37件/46件）の一致率となりました。見解が分かれた9件の要因を分析したところ、構造の粒度に関する解釈の違い（44.4％）や、ハードウェアにおける物理的制約と論理的アクセスの優先順位付けの違い（33.3％）などが挙げられています。
表1：専門家によるベースライン検証結果
| 評価指標 | サンプルA（ハードウェア） | サンプルB（ソフトウェア） | 全体データセット |
|---|---|---|---|
| 設計パターンの合意率 | 100%（23/23） | 100%（23/23） | 100%（46/46） |
| セキュリティ原則の合意率 | 82.6%（19/23） | 78.3%（18/23） | 80.4%（37/46） |
| 検証対象CWE数 | 23 | 23 | 46 |
LLMベンチマークで明らかになった設計推論の限界と偏り
3つのLLMに対して専門家が合意した設計パターンの特定精度を評価したところ、完全一致の割合はNotebookLMが32.6％、Claudeが23.9％、ChatGPTが19.6％にとどまりました。
表2：各LLMの設計パターン特定における一致度
| 一致度カテゴリ | LLM-1（NotebookLM） | LLM-2（ChatGPT） | LLM-3（Claude） |
|---|---|---|---|
| 完全一致 | 15（32.6%） | 9（19.6%） | 11（23.9%） |
| 部分一致 | 9（19.6%） | 9（19.6%） | 7（15.2%） |
| 弱い一致 | 6（13.0%） | 6（13.0%） | 10（21.7%） |
| 不一致 | 16（34.8%） | 22（47.8%） | 18（39.1%） |
ドメインによる推論精度の差異
モデル全体の傾向として、ソフトウェア中心のサンプルBに比べて、ハードウェアや低レイヤのアーキテクチャが関わるサンプルAにおいて不一致率が約45％と高くなりました。学習データ内に一般的なWebやアプリケーション層の事例が多い一方、物理層やファームウェアの境界設計に関する事例が不足している影響が推察されています。
入力検証と権限分離への過度な依存
誤分類の分析では、本来はRAII（Resource Acquisition Is Initialization）や正規化（Canonicalization）、コンポーネント分割（Distrustful Decomposition）を適用すべき構造的問題に対し、LLMが「入力検証」や「権限分離」を過剰に提案する傾向が確認されました。モデル全体で入力検証の誤提案は28回に達しています。
図1：モデル全体における不適切な設計パターンの提案分布
開発チームで本研究の結果をどう捉えるか
本研究の実験結果は、AIツールを活用したセキュア設計の導入やレビュー方針を検討するうえで、いくつかの判断材料を提供します。
- AI提案のスコープを見極める：LLMは個別の入力チェックやアクセス制限といったコードレベルの対策を提示することに長けていますが、リソースのライフサイクル管理や状態遷移の安全性といったアーキテクチャ全体の設計判断では見落としが生じる可能性があります。
- 設計パターンの明示的な定義：RAIIなどの状態管理パターンはAIが自律的に選択しにくいため、チーム内で利用すべき設計パターンのカタログやコード規約をあらかじめ言語化しておくことが有用です。
- ハードウェア・低レイヤ特有の境界確認：ファームウェアやハードウェアが絡む機能では、ソフトウェア的な分離アプローチが通用しない場合があるため、専門家によるレビュー重点項目として設定することが望まれます。
なお、本研究のサンプル数は46件のCWEに限定されており、プロンプトの構成やモデルのバージョンによって精度が変動する余地がある点には留意が必要です。
まとめ
本研究では、攻撃者の手法からCWE、そしてセキュア設計パターンへとつなぐフレームワークを構築し、LLMによる設計推論の再現性を検証しました。
実験の結果、専門家の間では設計パターンに対して100％の合意が形成されたのに対し、LLMによる特定精度は約20〜33％にとどまりました。特に、状態管理や構造的な分離を要する課題に対して、対症療法的な入力検証を過剰に選択する「実装バイアス」が観測されています。
AIによるセキュリティ支援を取り入れる際も、アーキテクチャの根本的な安全性を担保するためには、脅威モデルに基づく設計パターンの適用判断を人間が慎重に行う必要があります。
Webサービスや社内のセキュリティにお困りですか？ 弊社のサービス は、開発チームが抱える課題を解決し、生産性と幸福度を向上させるためのさまざまなソリューションを提供しています。ぜひお気軽にご相談ください！
参考資料：