脆弱性とは？種類・CVE/CVSSの仕組みと発見から修正までの実務を解説

脆弱性（ぜいじゃくせい）とは、ソフトウェアやシステムの設計・実装・設定に潜む欠陥のうち、攻撃者に突かれると情報漏えいや不正操作といった被害につながりうる弱点のことです。単なる不具合（バグ）と違い、悪用されると実害が生じる点に脆弱性の本質があります。この記事では、脆弱性とバグ・脅威・攻撃の関係、SQLインジェクションやクロスサイトスクリプティングといった主要な種類、CWE・CVE・CVSSという世界共通の指標、発見から修正までのライフサイクル、そして脆弱性対応を自社で回すか外部診断に委ねるかの判断基準までを、開発と運用に関わる技術者の視点で整理します。

まとめ：脆弱性は種類の暗記より発見後の修正プロセスと運用体制で被害が決まる

脆弱性の名前や分類を覚えること自体には、あまり価値がありません。攻撃者は日々新しい欠陥を探し、既知の脆弱性でも修正が適用されていなければそこを突きます。被害の大小を分けるのは、公表された脆弱性を素早く検知し、影響範囲を特定し、修正（パッチ）を適用するまでの一連のプロセスを回せるかどうかです。

この循環を支える道具立ては揃っています。欠陥の型を分類するCWE、個別の脆弱性にIDを振るCVE、深刻度を数値化するCVSS。これらを使えば「どの製品のどの版に、どれくらい危ない欠陥があるか」を機械的に照合できます。あとは、その照合を継続的に回す体制があるかどうかです。診断で現状を把握し、部品構成を台帳化し、継続監視で追従する。自社にこの体制が無い段階では、AIを含むシステムのセキュリティ対策支援のように、脆弱性への継続対応の仕組みづくりから外部の手を借りる選択が現実的です。以下、定義から判断まで順に解説します。

脆弱性とは何か——ソフトウェアの欠陥とセキュリティリスクの関係

まず言葉の輪郭を押さえます。脆弱性は「欠陥そのもの」を指し、攻撃と結びついて初めてリスクになる——ここが出発点だ。混同されやすい周辺の用語と切り分けると、対処の考え方が見えてきます。

脆弱性・バグ・脅威・攻撃という4つの基本用語の違いを整理する

脆弱性はセキュリティ上の弱点、バグは仕様どおりに動かない不具合を指します。両者は重なる部分もありますが、画面表示が崩れるバグはセキュリティ被害を生まない一方、認証を回避できる欠陥は明確な脆弱性です。ここに「脅威（それを突こうとする存在や事象）」と「攻撃（実際に突く行為）」が加わります。攻撃者という脅威が、脆弱性という弱点を、攻撃という行為で突いたときに被害が発生する、という関係で捉えると整理しやすくなります。

この切り分けが対処の順番を決めます。脅威をなくすことはできませんが、脆弱性は塞げます。だからこそセキュリティ対策の中心は、弱点を見つけて修正する営みに置かれる。脆弱性を放置したまま攻撃だけを検知しようとしても、後追いになりがちです。

脆弱性が生まれる主な要因は設計・実装・設定・構成部品の4つに分かれる

脆弱性はコードのミスだけから生まれるわけではありません。発生源はおおむね4つに分かれます。第一に設計段階の考慮漏れ（認証や権限設計の甘さ）、第二に実装段階のミス（入力値の検証不足）、第三に運用段階の設定不備（初期パスワードの放置、不要ポートの開放）、第四に取り込んだ構成部品（OSSやライブラリ）に元から含まれる欠陥です。

現在のソフトウェアはコードの多くを外部部品が占めるため、第四の「他人が書いた部品の脆弱性」が被害の大きな入り口になっています。自社のコードが完璧でも、依存ライブラリの欠陥を経由して侵害される。この構造を踏まえると、自作コードの検査だけでなく、何を取り込んでいるかを把握するSBOM（ソフトウェア部品表）による構成管理が対処の前提になります。

主な脆弱性の種類——SQLインジェクション・XSS・バッファオーバーフローほか

脆弱性には無数の型がありますが、被害の多くは限られた定番の型に集中します。攻撃がどんな条件で成立するかを型ごとに理解しておくと、コードレビューや診断結果の読み解きが速くなります。

Webアプリケーションで頻出する脆弱性の型と攻撃が成立する条件

とくにWebアプリケーションで繰り返し登場する型を、成立条件とともに押さえます。共通するのは「外部からの入力を信頼したまま処理してしまう」という構図です。

これらは古くから知られる型でありながら、現在も攻撃の主要な経路であり続けています。理由は単純で、新しいコードが書かれるたびに同じミスが再生産されるためです。フレームワークの標準機能で入力を検証し、出力時にエスケープするといった定石を外さないことが、型ごとの個別対処より効きます。バッファオーバーフローのようにメモリを直接扱う言語で起きやすい型は、扱う言語やランタイムの特性ごとに勘所が変わります。

脆弱性を共通言語で扱う仕組み——CWE・CVE・CVSSの三本柱

脆弱性を組織や国をまたいで扱うには、共通の呼び名と物差しが要ります。世界で使われる基盤が、種類を分類するCWE、個別の欠陥を識別するCVE、深刻度を測るCVSSの三本柱です。役割が違うので、混同せず対応づけて理解します。

CWE・CVE・CVSSという3つの指標の役割の違いと相互関係

三者は上流から下流へ連なる関係にあります。CWEが「弱点の型」を分類し、その型に当てはまる具体的な欠陥が製品で見つかるとCVEというIDが振られ、そのCVEの危険度をCVSSが数値で表す、という流れです。たとえばSQLインジェクションという型はCWE-89に分類され、ある製品で見つかった個別の事例にはCVE番号が付き、その深刻度がCVSSスコアで示されます。

CVSSは版が併存している点に注意します。長く使われてきた3.1系に加え、評価の粒度を見直した4.0系が2023年に公表され、現時点では両者が混在します。スコアは攻撃のしやすさや影響範囲から算出され、9.0以上は緊急（Critical）と扱われるのが一般的な目安です。ただしCVSSはあくまで技術的な深刻度であり、その脆弱性が自社の環境で実際にどれだけ危ないかは、公開範囲や資産の重要度を掛け合わせて別途判断する必要があります。CVEやCVSSの詳細な読み解きは、脆弱性識別子に特化した解説記事で扱います。

脆弱性の発見から報告・修正・適用までのライフサイクルと管理の流れ

個々の脆弱性には、見つかってから塞がれるまでの一連の道のりがあります。この流れを知っておくと、自組織がどの段階に関わるべきかが見えてきます。攻撃者との時間差をめぐる勝負でもある。

脆弱性の発見・報告・CVE採番・パッチ公開・適用までの各段階

典型的な流れは次のとおりです。研究者やベンダーが脆弱性を発見し、開発元へ責任ある形で報告します。開発元は影響を確認し、CVE番号の採番と公開に合わせて修正版（パッチ）が提供される。利用者側は、そのパッチを自社環境へ適用します。この最後の「適用」が滞ると、修正が存在するのに塞がれていない期間が生まれ、攻撃者に狙われます。

とりわけ危険なのが、修正が出る前に攻撃が始まるゼロデイと、公開直後にパッチ適用が追いつかない期間です。すべての脆弱性へ即座に対応するのは非現実的なので、CVSSスコアと自社での露出度を掛け合わせ、直すべき対象に優先順位を付けて回すのが現実的だ。この優先順位づけを継続的な枠組みにしたのが、CTEM（継続的脅威エクスポージャー管理）の考え方です。

継続的に脆弱性を洗い出す脆弱性管理（診断・SBOM・CTEM）

脆弱性対応は一度きりのイベントではなく、回し続ける営みです。現状を深く調べる脆弱性診断で外部から見える弱点を洗い出し、SBOMで自社製品に含まれる部品を台帳化してCVEと突き合わせ、CTEMでこの循環を継続的に運用する。診断・部品管理・継続監視は競合ではなく、粒度の違う道具立てです。診断のなかでも、実際に侵入を試みて悪用可能性まで検証する手法はペネトレーションテストと脆弱性診断の違いで整理しています。

脆弱性対応を内製で回せる企業の条件と、診断を外部委託すべき場面の判断

ここは製品カタログ的な解説では触れられにくい論点です。脆弱性への向き合い方は「診断ツールを買えば済む」ものではなく、検知した欠陥を修正まで運ぶ体制が本体になります。玉虫色を避け、条件を切って結論を示します。

脆弱性対応を内製で回せる3条件と、診断・運用を外部に出すべき場面

脆弱性対応を自社で回せるのは、次の3つを満たす組織です。第一に、公表される脆弱性情報を継続的に追う担当を置けること。第二に、自社製品・システムの構成（どの部品のどの版を使っているか）を把握できていること。第三に、見つかった脆弱性を修正までつなぐ変更管理のフローが既にあること。とくに三番目の「直すところまで運ぶ体制」が欠けていると、脆弱性を見つけてもリストが積み上がるだけで塞がりません。

逆に外部委託や支援を選ぶべき場面もはっきりしています。開発を外部に委託していて自社に検査基盤が無い、担当が兼任で常時監視まで手が回らない、専門的な診断スキルが社内に無い、といった段階でフルスコープの内製を掲げるのは過剰です。この状態でまず要るのは、診断で現状を把握し、継続監視の土台を作ることで、AIを組み込んだ現代のシステムでは攻撃面も広がるため、AIを含むシステムのセキュリティ対策支援のように継続対応の仕組みづくりから外部の手を組み合わせる入り方が現実的です。

スモールスタート：重要資産を1つ選び継続診断から広げる進め方

脆弱性対策を全社一斉に構えると、対象範囲の合意だけで時間を溶かします。現実的な入り方は逆で、外部に公開している主力システムを1つ選び、そこを継続的に診断し、見つかった脆弱性を修正まで運ぶ循環を先に1周させることです。1資産で診断・優先順位づけ・修正のフローを回して型を作り、そこから対象を横に広げる。最初から全システム網羅を狙わない、この一点が形骸化を避ける最大のコツです。範囲を絞れば限られた人員でも循環を体験でき、経営や顧客への説明材料も揃います。

脆弱性に関するよくある質問——対策・診断・優先順位づけの疑問に回答

脆弱性への対応を検討する際によく挙がる疑問に、実務の観点から簡潔に答えます。

脆弱性とバグは何が違うのですか？

バグは仕様どおりに動かない不具合全般を指し、脆弱性はそのうち悪用されるとセキュリティ被害につながる欠陥を指します。画面が崩れるバグは脆弱性ではありませんが、認証を回避できる不具合は脆弱性です。すべての脆弱性は広い意味でのバグですが、逆は成り立ちません。

脆弱性はゼロにできますか？

できません。新しいコードや新しい部品が加わるたびに未知の欠陥が生まれ、既知の脆弱性も次々と公表されます。目指すのは根絶ではなく、見つけて優先度をつけ、修正まで運ぶ循環を継続的に回して、危険な脆弱性を放置しない状態を保つことです。

CVSSスコアが高い脆弱性から順に直せばよいですか？

スコアは出発点にすぎません。CVSSは技術的な深刻度を示す指標で、自社での実際の危険度は、その資産が外部公開されているか、扱うデータの機微さ、悪用が実際に観測されているか、を掛け合わせて判断します。スコアが高くても内部限定で到達不能なら優先度は下がり、逆にスコアが中程度でも公開資産なら急ぐ場合があります。

脆弱性診断を受ければ安全になりますか？

診断はある時点の弱点を可視化する手段で、それ自体が防御ではありません。診断で見つかった脆弱性を修正し、その後も継続的に診断と監視を回して初めて安全性が保たれます。一度の診断結果は健康診断と同じで、受けた時点の状態を示すものだと捉えると誤解が減ります。

OSSの脆弱性にはどう対応すればよいですか？

まず自社が何を使っているかを把握することが起点です。SBOMで依存する部品とその版を台帳化し、CVEデータベースと突き合わせれば、影響する既知の脆弱性を機械的に洗い出せます。あとは影響の大きい順にパッチ適用や版の更新を進めます。手作業での把握には限界があるため、構成管理の自動化とセットで進めるのが現実的です。

関連記事

• 脆弱性診断とは？種類・費用相場・進め方と外注時の判断基準を解説：脆弱性を実地で洗い出す診断の種類・費用感・外注時の選び方を整理しています。
• CTEMとは？脆弱性管理との違い・5つの段階と企業の導入判断を解説：脆弱性対応を継続的に回す枠組みとしてのCTEMの全体像を解説しています。
• SBOMとは？ソフトウェア部品表の目的・フォーマットと作成・運用の判断を解説：構成部品の脆弱性を追うための部品表の作り方と運用を扱っています。
• ペネトレーションテストと脆弱性診断の違い：悪用可能性まで検証する診断手法と通常の脆弱性診断の使い分けを整理しています。
• ゼロトラストとは？境界型防御との違い・NIST7原則と導入判断を解説：脆弱性を突かれる前提で被害を抑える設計思想としてのゼロトラストを解説しています。