脆弱性
Vulnerability ・ ぜいじゃくせい
攻撃者に悪用されうる欠陥。CVE で番号を付け、CVSS で深刻度を評価して管理する。
✦ 30秒で試す — 航海動作に何の問題もない欠陥が、会社を傾かせることがある今日のうちに先に直すべきなのは？予想してみる概要
脆弱性（vulnerability）は、ソフトウェアやシステムの欠陥のうち、攻撃者に悪用されうるものを指します。画面のレイアウトが崩れる不具合は利用者を困らせるだけですが、入力チェックの漏れが SQL インジェクションにつながるなら、それは脆弱性です。分かれ目は「攻撃者がその欠陥を使って、本来できないはずのこと（データを盗む、権限を奪う、サービスを止める）を実現できるか」にあります。
脆弱性はコードの書き間違いだけから生まれるわけではありません。設計上の見落とし（認可のチェックがそもそも設計にない）、設定の誤り（管理画面がインターネットに公開されたまま）、古いライブラリの放置、さらには仕様そのものの欠陥も脆弱性になります。そしていまの開発では、自分が書いたコードより、依存しているライブラリやフレームワークに見つかる脆弱性への対応のほうが、日常の仕事としてずっと多く発生します。CI/CD に組み込んだ Dependabot が更新のプルリクエストを出してきた、「CVE-2021-44228（Log4Shell）の影響を調べてほしい」と頼まれた、といった場面で、CVE 番号や CVSS スコアを読み解く力が求められます。
なぜ生まれたか
脆弱性そのものは、ソフトウェアがある限り避けられない副産物です。しかし「脆弱性を識別し、管理する仕組み」は、必要に迫られて作られました。1990年代、同じ欠陥がベンダーごと、ツールごとに別の名前で呼ばれていました。「うちのスキャナが見つけたこの問題は、あのアドバイザリの問題と同じものか」を突き合わせることすら大変だったのです。この混乱を解くために、1999年に MITRE が CVE（Common Vulnerabilities and Exposures）を始め、公開された脆弱性の一つひとつに世界共通の識別番号を付ける体制ができました。
もう一つの課題は、深刻さの伝え方でした。「重大」「注意」といったベンダー独自の表現では、横に並べて比べられません。そこで生まれたのが CVSS（Common Vulnerability Scoring System）です。攻撃のしやすさと影響の大きさを共通の基準で採点し、0.0〜10.0 のスコアにします。2005年の初版から改訂が続き、いまは v3.1 が広く使われ、2023年に FIRST が v4.0 を公開しました。番号で「どの脆弱性か」を特定し、スコアで「どれくらい急ぐべきか」を判断する。この2つの共通言語が、世界中の組織が同じ脆弱性情報をもとに動くための土台になっています。
詳細
欠陥と脆弱性 — 悪用できるかが分かれ目
脆弱性は「欠陥」の一部です。ここでいう欠陥は、狭い意味のバグ（コードの書き間違い）だけではありません。設計の見落とし、設定の誤りも含みます。そのうち、悪用する具体的な道筋（エクスプロイトと呼びます）が成り立つものが脆弱性です。
たとえば境界チェックの漏れは、単にプログラムが落ちるだけなら品質の問題ですが、細工した入力でメモリ上の任意のコードを実行できるなら深刻な脆弱性です。防御する側にとって大事なのは、「動作に影響がないから放っておいてよい」とは限らない、という視点です。一見無害な情報の漏れ（エラーメッセージに内部のパスが出るなど）も、ほかの欠陥と組み合わされると攻撃の足がかりになります。
CVE と CVSS — 識別と深刻度の共通言語
CVE 番号は CVE-2021-44228 のように「CVE-西暦-連番」の形で、公開された脆弱性を一意に識別します。採番は MITRE と、その権限を委ねられた CNA（ベンダーやセキュリティ企業）が行い、米国 NIST の NVD などのデータベースに詳しい情報が蓄積されます。番号があるので、スキャナの検出結果、ベンダーのアドバイザリ、社内の対応チケットを、同じ脆弱性として結びつけられます。
CVSS のスコアを読むときは、数字を鵜呑みにしないことが大切です。CVSS は、性質の違う3種類の指標を分けて持っています（v4.0 の名前で書きます）。
基本（Base）の指標は、「ネットワーク越しに攻撃できるか」「攻撃に特別な条件が要るか」「認証は必要か」「利用者の操作が要るか」といった攻撃の条件と、機密性・完全性・可用性への影響から計算される、脆弱性そのものの性質です。NVD やベンダーが公開する 9.8 のような数字は、ほとんどがこの基本スコアです。脅威（Threat）の指標は、実際に悪用が観測されているか、攻撃コードが出回っているかを加味します（v3.1 では「現状値（Temporal）」と呼ばれていました）。環境（Environmental）の指標は、あなたの環境での重みです。
9.8 の脆弱性でも、該当する機能を無効にしていれば、自社への影響はゼロかもしれません。逆に 5.0 台でも、インターネットに面した基幹システムにあるなら、最優先で対応すべきかもしれません。スコアはトリアージ（対応の優先順位付け）の出発点で、自社の環境で到達できるか、何が影響を受けるかを重ねて優先度を決めるのが実務です。「いま実際に悪用されているか」の手がかりとして、米国 CISA の KEV カタログ（悪用が確認された脆弱性の一覧）や、FIRST の EPSS（今後30日に悪用される確率の推定）を併用する方法も広まっています。
脆弱性情報のライフサイクル — 発見から公開まで
脆弱性は「発見された瞬間」ではなく、「修正が行き渡る前に攻撃者に知られた瞬間」が最も危険です。そこで、発見者がベンダーに非公開で報告し、修正版が用意されてから詳細を公開する「協調的開示（coordinated disclosure）」が、業界の標準的な作法になっています。多くの組織は 90 日程度の猶予期間を設け、期限内に修正されない場合は利用者を守るために公開に踏み切る、というルールで運用しています。
この流れが崩れる場合が2つあります。一つは、修正が存在しないまま攻撃者が悪用を始める「ゼロデイ攻撃」です。防御側に対応の猶予が0日しかないことが名前の由来です。パッチでは防げないので、WAF による仮想パッチ、最小権限の原則による被害の局所化、監視による早期の検知といった、多層の備えだけが対抗手段になります。もう一つは、修正版の公開そのものが攻撃者へのヒントになる場合です。パッチの差分から脆弱性を逆算した「N デイ攻撃」は、公開から数日以内に始まることが多く、「パッチが出たら速やかに当てる」体制の有無が、そのまま防御力の差になります。悪用が確認されたら、影響の調査と封じ込めはインシデント対応の手順に乗せて進めます。
依存関係の脆弱性管理 — いまの主戦場
いまのアプリケーションはコードの大半を外部のライブラリに頼っていて、脆弱性対応の主戦場は「自分のコードの修正」から「依存関係の把握と更新」に移っています。GitHub の Dependabot や各種の SCA（Software Composition Analysis）ツールは、ロックファイルから依存ツリーを読み取り、既知の CVE と突き合わせて、警告と更新のプルリクエストを自動で作ります。これを CI/CD のパイプラインに組み込み、コードレビューを通して日常的に小さく更新し続けることが、Log4Shell のような大規模な事案のときに「自社のどこで使っているか分からない」という最悪の状態を避ける備えになります。依存そのものが改ざんされるサプライチェーン攻撃への警戒から、部品表（SBOM）を整えて依存を見える化する動きも広がっています。
脆弱性を「見つける」活動には、OWASP Top 10 を指針にした設計やコードのレビュー、自動スキャンによる脆弱性診断、そして攻撃者の視点で実際に侵入を試みるペネトレーションテストがあり、それぞれ守備範囲が違います。脆弱性は撲滅できるものではなく、発見・評価・修正のサイクルを回し続ける運用の対象である。この認識が、防御側のすべての活動の前提になっています。
試問
セキュリティの担当者が、社内のシステムで見つかった7つの脆弱性（悪用されうる欠陥）の対応を決めています。CVSS は、脆弱性そのものの深刻さを0〜10で表す、公開される点数です。それぞれに、点数と「自社でどう使っているか」「世の中で狙われているか」が書いてあります。
7つの脆弱性を、今週中に最優先で直すものと、計画的な更新に回してよいものに仕分けよ
項目を選んでから、入れる箱を選びます