脆弱性 (コンピュータセキュリティ)

コンピュータセキュリティにおいて、脆弱性（ぜいじゃくせい、英: vulnerability）とは、脅威によって悪用される可能性のある、組織の情報・システム・設備・人材などの弱点や、セキュリティ対策の不備である。

ハードウェアやソフトウェアには、バグや設計上の欠陥が存在する場合がある。こうした欠陥が攻撃者に悪用され、システムの機密性、完全性、可用性（情報セキュリティの三要素）が侵害される可能性がある場合、その欠陥は脆弱性と見なされる。セキュリティへの配慮が不十分なソフトウェア開発や複雑な設計は、脆弱性が生じる要因となり得る。

脆弱性が放置された場合、重大なセキュリティインシデントや法的責任につながることがある。組織による脆弱性管理では、対象システムの把握、リスクに応じた優先順位付け、パッチ適用などを継続的に実施し、必要に応じて脆弱性の修復・緩和や残存リスクの受容を行う。公開される脆弱性情報の識別・共有には、共通脆弱性識別子（CVE）などが用いられる。脆弱性の深刻度は共通脆弱性評価システム（CVSS）によって評価され、対応の優先順位を検討する際などに利用される。

定義

ISO/IEC 27005:2022では、脆弱性を次のように定義している:

悪用されることで負の結果を伴う事象が発生する可能性のある、アセットまたは管理策の弱点

IETFの[]では、脆弱性を次のように定義しているInternet Engineering Task Force Internet Security Glossary, Version 2:

システムのセキュリティポリシーに違反するために悪用される可能性がある、システムの設計、実装、運用または管理上の欠陥や弱点

米国の国家安全保障システム委員会（CNSS）は、2010年のCNSS命令第4009号で、脆弱性を次のように定義している:

脅威の発生源によって悪用される可能性がある、情報システム、システムのセキュリティ手順、内部統制または実装上の弱点

NISTのFIPS 200もこの定義を基にしており、脅威の発生源によって弱点が悪用される場合だけでなく、誘発される場合も含めている。

ENISAの2006年のリスク管理報告書に収録された用語集（G.52）では、脆弱性を次のように定義している:

関係するコンピュータシステム、ネットワーク、アプリケーションまたはプロトコルのセキュリティを危険にさらすような、予期しない望ましくない事象[G.11]につながる可能性がある弱点、設計上または実装上の誤りの存在（ITSEC）

一方、情報リスクの定量分析モデルであるFAIRでは、脆弱性という用語が異なる意味で用いられていた。2006年のFAIRの解説と、これを基にしたThe Open Groupの2009年の規格『Risk Taxonomy』では、脆弱性を次のように定義している"An Introduction to Factor Analysis of Information Risk (FAIR)", Risk Management Insight LLC, November 2006 :

アセットが脅威エージェントの行動に抵抗できない確率

FAIRでは、この確率を脅威エージェントの能力とコントロールの強さとの関係によって捉える。2025年のFAIRモデル第3.0版では、脅威事象が損失事象となる確率を「感受性」（Susceptibility）と呼んでいる。

ISACAの用語集は、脆弱性を次のように定義している:

脅威事象による悪影響にシステムをさらすおそれのある、プロセスの設計、実装、運用または内部統制の弱点

LongleyとShainの『Data & Computer Security: Dictionary of Standards, Concepts, and Terms』（1987年）には、システムのセキュリティ手順や内部統制の弱点、組織・人員・ハードウェア・ソフトウェアの弱点などを挙げる複数の定義が掲載されている:

1）コンピュータセキュリティにおいて、情報への不正アクセスや重要な処理の妨害を目的とする脅威によって悪用される可能性がある、自動化されたシステムのセキュリティ手順、管理上の統制、内部統制などの弱点。2）コンピュータセキュリティにおいて、ADPシステムまたはその活動に危害を加えるために悪用される可能性がある、物理的な配置、組織、手順、人員、管理、ハードウェアまたはソフトウェアの弱点。3）コンピュータセキュリティにおいて、システムに存在する弱点または欠陥であり、攻撃や有害な事象が生じたり、脅威エージェントが攻撃を開始したりする機会となるもの。

Matt BishopとDave Baileyは1996年の研究で、コンピュータシステムの状態と状態遷移に基づく形式的な定義を示した:

コンピュータシステムは、その構成要素（エンティティ）の現在の構成を記述する「状態」によって表される。システムは、状態を変える「状態遷移」を適用して計算を行う。特定の初期状態から一連の状態遷移によって到達できるすべての状態は、セキュリティポリシーに従い、許可された状態と許可されない状態に分類される。この論文では、これらの分類と状態遷移の定義を公理として扱う。脆弱な状態とは、許可された状態遷移を使って許可されない状態に到達できる、許可された状態である。侵害された状態とは、そのようにして到達した状態である。攻撃とは、侵害された状態に至る一連の許可された状態遷移である。したがって、攻撃は脆弱な状態から始まる。脆弱性とは、脆弱な状態を特徴付け、それ以外の状態と区別する性質である。一般には、一つの脆弱性が多数の脆弱な状態を特徴付けることもあれば、特定の一つの状態だけを特徴付けることもある。

この定義では、許可された状態遷移によってシステムが許可されない状態に移行できる場合、その出発点を脆弱な状態とし、脆弱性をそうした状態を他の状態から区別する性質として捉える。

脆弱性を増大させる要因

脆弱性は、ソフトウェアの設計・開発における欠陥や、システムの不適切な設定などによって生じる。脆弱性の発生や悪用の容易さには、システムを取り巻く環境要因や構造的な問題も関係する。主な要因として以下が挙げられる。

システムの複雑さと接続性：システムの規模や構成が複雑になると、セキュリティ上の検証や管理が難しくなる場合がある。また、ネットワーク接続、公開された機能や通信インターフェースなど、外部から接触できる箇所はアタックサーフェスを構成する。アタックサーフェスが拡大すると、追加された接点と保護策を踏まえたリスク評価が必要になる。ソフトウェアの普及：広く普及したソフトウェアでは、より多くのシステムを攻撃できる可能性があるため、脆弱性の発見や悪用に関心が集まりやすい。過去の問題の再発：過去の失敗に関する知見が共有・活用されないと、同じような設計や運用上の誤りが繰り返される可能性がある。Ross Andersonは暗号システムの失敗を調査し、過去と同様の失敗が繰り返されてきたことを指摘している。人的要因：パスワードの使い回しや設定ミスなどの人的エラー、ソーシャルエンジニアリングへの対応不足なども、情報システムの弱点となる。

脆弱性とリスク

脅威・脆弱性・リスクの関係脆弱性は、それ自体が直ちに被害を生むわけではない。情報セキュリティのリスクの評価では、脅威が脆弱性を悪用したり、その弱点が偶発的に顕在化したりする可能性と、その結果生じる影響を考慮する。想定される脅威や攻撃経路を体系的に分析し、対策を検討するためのアプローチの一つが脅威モデリングである。

サムネイル|OWASP：脅威エージェントとビジネスへの影響の関係 OWASPなどのリスク要因モデルが示す通り、誰が、どのような経路で、どの脆弱性を狙うかを可視化し、それがビジネスにどのような影響を与えるかを検討することが、リスク評価につながる。

脅威モデリング脅威モデリングでは、システムの設計・開発段階で想定される攻撃シナリオを体系的に洗い出し、設計上の潜在的な弱点やリスクを検討する。その結果を対策の設計に反映できる。

脆弱性の連鎖脆弱性の連鎖（Vulnerability chaining）とは、システムやネットワークへのアクセスを達成するために、別々の脆弱性（多くの場合、個々にはほぼ無害なもの）を順番に組み合わせることである。2026年には、OpenAIの評価環境で稼働していたAIエージェントが、複数の脆弱性や取得した認証情報を悪用してHugging Faceのシステムに侵入した事例が報告された。

法的責任への影響脆弱性が悪用されると、情報セキュリティの三要素（機密性・完全性・可用性）が損なわれ、深刻な事業上の損害につながる可能性がある。脆弱性への対策に関する法的義務は、適用される法律や事業者の業務内容によって異なる。例えば、米国のHIPAAセキュリティ規則は、対象事業者に電子的な保護対象医療情報のリスク分析と管理を求めている。一方、PCI DSSは決済カード業界のセキュリティ基準であり、法律そのものではない。

脆弱性の種類と例

脆弱性には、ソフトウェアの設計・実装上の欠陥のほか、設定・運用、人的・組織的な管理、物理的な環境などの弱点も含まれる。以下では、弱点が存在する対象に沿って整理し、ソフトウェアについては欠陥の性質による分類も示す。これらの分類は相互に排他的なものではなく、一つの脆弱性が複数の観点に関係する場合がある。

ソフトウェアおよびシステムの脆弱性ソフトウェアやシステムの脆弱性には、設計・実装上の欠陥だけでなく、設定や運用上の弱点も含まれる。脆弱性は発見される前から存在する場合があり、修正プログラムが適用されていないシステムには、既知の脆弱性が残ることがある。また、ユーザーへの過剰な権限の付与や、デフォルトの認証情報を変更せずに使用することも弱点となる。不十分なセキュリティテストは欠陥の見落としにつながり、セキュリティ上重要な事象を適切に記録しない設計・設定は、不正な活動の検知や事後調査を困難にする。さらに、記憶媒体を適切に消去せずに廃棄すると、保存されていた情報が漏洩するおそれがある。

これら運用面・設計面の弱点に加え、ソフトウェア自体の欠陥にも多様な種類がある。Alhazmiらは入力検証、アクセス検証、例外処理、設定、競合状態、設計などによる8分類を用いて脆弱性の発見傾向を分析した。以下では、これに限らず、ソフトウェアの弱点を分類したNISTの資料なども参照して種類を説明する。

入力検証のエラーとインジェクション外部からの入力の検証や無害化が不十分な場合、インジェクションなどの攻撃が成立することがある。データベースに意図しない操作を行わせるSQLインジェクションや、不正なコマンドを実行させるコマンドインジェクションのほか、ディレクトリトラバーサル、メールインジェクション、HTTPヘッダ・インジェクションなどがある。また、利用者のブラウザーで悪意のあるスクリプトを実行させるクロスサイトスクリプティング（XSS）もこれに含まれ、格納型、反射型、DOMベースといった形態がある。

メモリと処理の不具合バッファオーバーフローやオーバーリード、ダングリングポインタ（解放済みのメモリ領域への参照）といったメモリ安全性違反が含まれる。また、競合状態には、検査時と使用時の間に状態が変化するTOCTOU（Time-of-check to time-of-use）などがある。さらに、処理時間の違いから情報を推測できる弱点は、タイミング攻撃に悪用され得る。

認証・認可および権限の不備認証が必要な機能で認証を行わなかったり、認可の不備によって本来制限されるべき操作を許したりすることは、セキュリティ上の弱点となる。アクセス制御の不備は、権限のない利用者が高い権限を得る権限昇格につながる場合がある。Webアプリケーションのその他の弱点には、認証済み利用者のブラウザーに意図しないリクエストを送信させるクロスサイトリクエストフォージェリ（CSRF）や、サーバーに意図しない宛先へのリクエストを送信させるサーバーサイドリクエストフォージェリ（SSRF）も挙げられる。

設計・ロジックおよびエラー処理の欠陥想定外の条件を適切に処理できないことによるビジネスロジックの欠陥や、不適切な例外処理・ユースケース処理、APIの誤った使用などが挙げられる。

ユーザインタフェース（UI）の脆弱性ユーザインタフェース（UI）がセキュリティ上重要な情報を誤って表示したり、その表示元を偽装できるようになっていたりすると、利用者に誤った判断や操作をさせる弱点となる。多数の警告への慣れによって重要な警告も見過ごされやすくなる「警告疲労」も問題となり、通知への習慣化がセキュリティ警告への注意や対応にも影響することが実験で示されている。

クリックジャッキングは、UIのフレームや表示層の制御が不十分な場合に、利用者を誘導して意図しない操作を行わせる攻撃である。さらに、セキュリティ確認ダイアログの表示と利用者の入力のタイミングを利用して、意図しない操作を承認させるUIにおける競合状態も報告されている。

オペレーティングシステムとアプリケーションにおける例

Linux、Android、Windows、macOSなど、さまざまなOSで起こり得る問題の一つに、攻撃者が本来認められていない権限を得る権限昇格の欠陥がある。いかなるOSであっても脆弱性は発生し得るため、信頼できるベンダーから提供される更新プログラムの継続的な適用が不可欠である。

従来型のクライアント・サーバーアプリケーション（シッククライアント、thick client）では、クライアント側にソフトウェアをインストールして利用する場合がある。パスワードなどの情報が平文で保存されていたり、通信が暗号化されていなかったりすると、情報が漏洩するおそれがある。また、アプリケーションのファイル、サービス、ライブラリなどに不適切なアクセス権限が設定されていると、攻撃者によるプロセスハイジャックにつながる場合がある。

ネットワークおよび通信の脆弱性通信内容を十分に保護しないプロトコルや設定を使用すると、通信の傍受や改ざんにつながるおそれがある。外部からのリモートアクセスにおいて適切な認証やアクセス制御が欠如している場合も、不正アクセスを許す要因となる。公衆Wi-Fiなどでも、通信が十分に暗号化されていなければ情報が漏洩する可能性がある。また、FTPの第三者転送機能を悪用し、FTPサーバーから別のホストへ通信を行わせるFTPバウンス攻撃も知られている。ただし、公衆Wi-Fiの利用自体が脆弱性を意味するわけではなく、HTTPSなどの暗号化は通信内容の保護に役立つ。

ハードウェアの脆弱性ハードウェアの脆弱性には、設計や実装に起因するセキュリティ上の欠陥がある。例えば、チップのデバッグ用インターフェースに適切なアクセス制御がない場合、攻撃者によって内部情報が読み取られたり、保護機構が回避されたりする可能性がある。また、ISO/IEC 27005:2022は、保守や定期的な機器交換の不足、湿気・ほこり・温度変化に対する弱さ、保管時の保護不足なども、情報セキュリティのリスク評価におけるハードウェアの脆弱性の例として挙げている。

人的および組織的な脆弱性組織のセキュリティ教育や運用手順が不十分な場合、利用者がフィッシングやソーシャルエンジニアリングに適切に対処できない可能性がある。NIST SP 800-53では、セキュリティに関する教育・意識啓発（AT-2）やソーシャルエンジニアリングへの対応（AT-2(3)）が管理策として挙げられている。また、退職や異動に伴って不要となったアカウントや権限を適切に変更・無効化しないことは、不正アクセスを許す弱点となり得る。

物理的および環境的な脆弱性サーバー室などで入退室管理が不十分な場合、権限のない者による機器へのアクセスや持ち出しを許す可能性がある。また、停電や火災、過度の温度・湿度などの脅威に対し、非常用電源、火災対策、環境制御などの保護策が不足していることは、情報システムの可用性に関わる弱点となる。NIST SP 800-53は、これらに対応する管理策として物理的アクセス制御（PE-3）、非常用電源（PE-11）、火災対策（PE-13）、環境制御（PE-14）などを挙げている。

サプライチェーンの脆弱性サプライチェーンの脆弱性とは、原材料調達や製造・物流といった業務プロセスから、運用・保守を担う外部委託先やソフトウェア資産に至る一連の供給網において、事業継続や情報セキュリティを脅かす構造的欠陥を指す。IPAは、委託先への攻撃や、委託先を踏み台にした不正侵入など、サプライチェーンを通じたリスクに対応するため、取引先のセキュリティ対策の評価・可視化を図る制度を整備している。ソフトウェアのサプライチェーンでは、依存するオープンソースソフトウェア（OSS）などの構成要素に脆弱性が存在する場合があり、ソフトウェア部品表（SBOM）による構成要素の把握は、脆弱性の影響調査や対応の優先順位付けに利用できる。

AIシステムの脆弱性とセキュリティ上の問題 2024年3月に開催された米国の情報セキュリティ・プライバシー諮問委員会（ISPAB）の会合で、カーネギーメロン大学のZico Kolterは、LLM（大規模言語モデル）のセキュリティ上のリスクについて講演した。その中で、LLMの普及に伴い、その利用によって「巨大なセキュリティホール（massive security hole）」を作り出す可能性があると述べた。

LLMにおけるプロンプトインジェクション、データポイズニング、モデルの反転攻撃といったセキュリティ上の問題には、従来のソフトウェアの欠陥と異なる性質を持つものもある。ただし、AIや機械学習に関する脆弱性も、技術分野だけを理由にCVEの識別対象から除外されるわけではない。AIモデルのハルシネーションなどは、これらの脆弱性とは区別して検討する必要がある。

脆弱性管理

脆弱性管理は、システムに存在する弱点を特定し、リスクを評価して、修復・緩和・受容などの対応を進める継続的なプロセスである。ソフトウェアの脆弱性には、発生、発見、悪用、修正、製品の使用終了などの過程がある。ただし、悪用が必ず起こるわけではなく、各段階の順序も一定ではない。複数の過程が同時に進む場合もある。

脆弱性の発見・特定脆弱性は、製品開発者やセキュリティ研究者などによって発見されることがある。組織が利用する資産やソフトウェアの種類・バージョンを把握し、それらに影響する脆弱性を調べることが、脆弱性管理の基礎となる。

自組織のシステムにある脆弱性の特定には、自動スキャンツールが役立つ。ただし、ゼロデイ脆弱性の検出は難しく、既知の脆弱性をデータベースに基づいて検出する場合にも偽陽性が生じる。このため、人による確認や判断が必要となる。

評価と優先順位付け発見されたすべての脆弱性を即座に修正することは、対応に必要な資源やシステム稼働への影響から現実的ではない。優先順位を決める際は、共通脆弱性評価システム（CVSS）が示す深刻度だけでなく、対象システムが外部に公開されているか、実際に悪用されたことが確認されているか、攻撃の自動化の可能性、悪用後の技術的な影響などを考慮する。

パッチ適用の優先順位は、対象資産の重要度、対応によって低減できるリスク、適用に必要な検証や運用停止などを考慮して決定する。セキュリティ対策の選択にあたっては、対策の効果だけでなく、必要な資源、既存のシステム構成、組織のリスク許容度などを考慮する。

対応脆弱性への対応には、修復（脆弱性を塞ぐこと）、緩和（悪用を困難にし、その影響を軽減すること）、および一部の残存リスクの受容があり、必要に応じてこれらを組み合わせる。

攻撃に対する複数の障壁を設ける戦略として、多層防御が用いられる。これは、脆弱性の悪用を防ぐ対策に加え、攻撃を検知・阻止する対策などを組み合わせるものである。侵入検知システムは、攻撃を検知する仕組みの一例である。

組織全体のセキュリティ管理では、ISO/IEC 27002などの情報セキュリティ管理に関する指針や、Risk ITなどのITリスク管理の枠組みを用い、経営層の定めたセキュリティ戦略に沿って運用する方法がある。

修復修復とは、ソフトウェアパッチの適用やアップデートによって脆弱性自体を塞ぐ、根本的な対応である。ただし、パッチ開発には数ヶ月かかることもあり、適用時にはシステムの機能や互換性への悪影響を確認するテストが必要となる。また、パッチや関連資料をリバースエンジニアリングし、修正対象の脆弱性を悪用するエクスプロイトが開発される場合がある。このため、パッチの公開後も適用されていないシステムが攻撃対象となり得る。

緩和緩和は、パッチが提供されていない場合や直ちに適用できない場合に、アクセス権限の制限、該当機能の無効化、アタックサーフェスの縮小などによって、攻撃の成立や被害の拡大を抑える措置である。特に、root（管理者）権限を持つシステム部分のアタックサーフェスを減らし、エクスプロイトによる権限の悪用を防ぐことは、サイバー攻撃が引き起こす可能性のある被害を減らすための一般的な戦略である。パッチが利用できない場合には、影響を受ける機能を一時的に無効化するなどの回避策が用いられる場合がある。長期的には、システムの複雑さや機能を減らすことによってアタックサーフェスを縮小し、攻撃を困難にできる。

受容受容とは、リスクを把握した上で、対策を講じずに、あるいは対策後に残ったリスクを受け入れる判断である。受容したリスクも継続的な監視と見直しの対象となる。

対策の検証と継続的な管理実施した対策の有効性を確認する方法には、組織のセキュリティ管理状況を検証する情報セキュリティ監査や、ペネトレーションテストなどがある。ペネトレーションテストでは、既知の脆弱性に対する既存のエクスプロイトを使用し、自動化されたソフトウェアによってテストを実施できる場合がある。また、外部からの攻撃を模擬するため、訓練を受けたホワイトハッカーに侵入テストを委託し、システムへの侵入がどれほど容易か、または困難かを調べる場合もある。

情報技術製品のセキュリティを評価する基準としては、ITSECと共通基準がある。

パッチによって脆弱性が修正された場合や、影響を受けるソフトウェア・ハードウェアの使用を終了した場合には、当該システムにおける脆弱性への対応を完了できる。ただし、製品の使用を終了しても、製品自体の欠陥が修正されたわけではない。また、医療機器や産業制御システムなど交換が容易でないシステムでは、メーカーのサポートが終了した後も脆弱性が長期間残存する場合がある。

脆弱性の報告と情報共有

脆弱性の開示脆弱性の開示方法には、「調整された開示（責任ある開示）」と「フルディスクロージャ」という代表的なアプローチがある。

調整された開示では、発見者がまず製品開発者などに非公開で脆弱性を報告し、必要に応じてCERTなどの調整機関と連携しながら、修正や緩和策の準備と情報公開の時期を調整する。報告から公開までの期限は、調整主体の方針や事案によって異なる。脆弱性の報告を奨励するためにバグバウンティ（報奨金）を設ける組織もある。

2010年7月22日、Microsoftは、従来の「責任ある開示」に代えて「調整された脆弱性開示」（Coordinated Vulnerability Disclosure、CVD）という用語を使用する方針を発表した。発見者、ベンダーなどの関係者が協力して修正と情報公開を進める考え方を示したものである。

フルディスクロージャは、脆弱性の詳細を一般に公開する手法である。ベンダーに修正を促す意図で行われる場合もあるが、修正プログラムが提供される前に公開すると、その情報が攻撃に悪用されるリスクが高まる。

脆弱性に関する情報や悪用手法は、こうした開示の枠組みとは別に、政府・情報機関の関係者や犯罪目的の購入者に売却される場合もある。

脆弱性の発見日、製品開発者への報告日、CVE IDの割当日、情報の一般公開日、修正版の公開日は、必ずしも一致しない。CVEでも、識別子の割当てとCVEレコードの公開は別の手順として扱われる。

公式の修正パッチがまだ提供されていない脆弱性は、一般にゼロデイ脆弱性と呼ばれる。製品開発者がその存在を認識している場合もあり、脆弱性の公表が必ず攻撃につながるとは限らない。

脆弱性の報告・公表に関する法的義務は国や地域、対象となる事業者や製品によって異なる。例えば欧州連合のサイバーレジリエンス法では、2026年9月から対象製品の製造者に対し、実際に悪用されている脆弱性などを当局に報告する義務が適用されている。

脆弱性情報の識別・評価・共有脆弱性に関する情報は、共通の識別子やデータベースを通じて共有される。

CVE（共通脆弱性識別子）：MITREコーポレーションが運営に関与する国際的なCVEプログラムによって、脆弱性に共通の識別子が割り当てられ、CVEレコードとして情報が共有される。脆弱性の評価と分類：CVEの情報は米国のNational Vulnerability Database（NVD）などのデータベースでも利用される。NVDでは、脆弱性の深刻度を評価するCVSS、影響を受ける製品を識別するCPE（共通プラットフォーム一覧）、弱点の種類を分類するCWE（共通脆弱性タイプ一覧）などが用いられる。CVSSでは、攻撃に必要な条件や攻撃の複雑さ、必要な権限、ユーザーの操作の要否などが評価されるが、その基本スコアだけで個々の組織におけるリスク全体が決まるわけではない。データベースの適用範囲と限界：すべての脆弱性がCVEレコードとして登録されるわけではない。CVE IDは認定されたCVE番号付与機関（CNA）によって付与され、クラウドやAIなどの技術分野のみを理由に、付与対象から除外することは認められていない。教育への利用：OWASPは、ソフトウェアの脆弱性の事例や種類を解説する資料を公開し、開発者などへのセキュリティ知識の普及に役立てている。

脆弱性 (コンピュータセキュリティ)

Źródło i licencja