脆弱性診断って、何をしているの？ 〜弱点を見つけて、会社の改善につなげるまで〜

2026年10月9日 情報セキュリティワークショップ in 越後湯沢 車座会議資料

脆弱性診断をこれから学ぶ方だけでなく、診断を依頼する方や、診断結果を受け取って対応を検討する方にも参考になれば幸いです。なお、技術的な内容にはあまり踏み込んでいないため、本資料だけで脆弱性診断の技術が身につくわけではありません。脆弱性診断がどのようなものなのか、雰囲気をつかんでいただければと思います。

1. ２０２６年10月９日（金） しろおびセキュリティ 越後湯沢出張編 脆弱性診断って、 何をしているの？ 弱点を見つけて、会社の改善につなげるまで KeeG／しろおびセキュリティ
2. 自己紹介 KeeG キーグ しがないセキュリティアーキテクト 妻が最推し はるか昔、脆弱性診断員だったはず・・・ Microsoft Defender が好き 診断する側 × 結果を使う側の視点で話します
3. お願い事項 本資料は、内容の正確性には配慮していますが、作成者の理解不足や表現の不十分 さが含まれる可能性があります。 お気づきの点がありましたら、ご指摘いただけますと幸いです。
4. 脆弱性診断サービスから、報告書が届きました IDOR：Insecure Direct Object Reference（権限確認の不備）／URL：Uniform Resource Locator（アドレス） CWE：Common Weakness Enumeration（弱点の種類の分類）。639は分類番号。請求書の問題は第3章で確認します。
5. この報告を受け取ったら この報告を受け取ったとき、 何を確認し、どう対応を決めますか？ この後の説明で、確認することと判断の進め方を考えます。
6. お話しすること 本資料のタイトル ： 脆弱性診断って、何をしているの？ 〜弱点を見つけて、会社の改善につなげるまで〜 1 ２ 脆弱性診断員は、何を確かめているのか 本日のゴール 脆弱性の種類：対象・原因・具体例 診断の範囲と、確認すること ツール・手動で探しやすい例 何を確認した診断した 結果なのか理解できる 診断の品質を決めるもの 必要な材料と診断環境の準備 未確認の範囲と条件の把握 診断員による検証・報告 ３ 診断結果を判断に使うための 条件を確認できる 診断結果から、対応と運用を判断する 本来許してよい動作かを確認 分かること・分からないこと ベンダーの危険度と、自社の対応順位 対応方針・担当・期限、停止・再開 修正確認と再発防止 指摘の後に何を確認し、 どう対応を決めるか整理できる
7. 第１章 脆弱性診断員は、何を確かめているのか
8. 脆弱性とは （広い意味からセキュリティへ） 診断を 知る 品質を 決める 脆弱性（vulnerability）という言葉は、 「弱さ・傷つきやすさ」という広い概念です。 例えば、次のように使われます。 vulnerability to earthquakes urban vulnerability to disasters 地震に対する脆弱性 災害に対する都市の脆弱性 情報セキュリティの分野では、 「攻撃や事故によって、セキュリティ上の問題につながる弱点」 という意味で使われます。 改善へ つなぐ
9. 脆弱性とは （セキュリティにおける） 診断を 知る 品質を 決める 脆弱性とは、セキュリティ上の問題につながる「弱点」 システム、ソフトウェア、機器、設定、運用手順などに存在する弱点のうち、 機密性・完全性・可用性に影響を及ぼす可能性があるものを「脆弱性」と呼びます。 機密性 見てはいけない人に情報が見られないこと 完全性 情報や処理結果が不正に変更されないこと 可用性 必要なときに業務やサービスを使えること 脆弱性が悪用されると、 情報漏えい・改ざん・なりすまし・業務停止・システムの不正利用などに つながる可能性があります。 改善へ つなぐ
10. どこの「脆弱性」の話をしている？ 診断を 知る 品質を 決める 改善へ つなぐ 組織の脆弱性 人に関わる弱点 システムの弱点 プロセスの弱点 例：なりすましの依頼を 見抜けず、秘密の情報を 渡してしまう 例：退職・異動のあとも 不要な権限が残る 運用になっている 例：権限確認の抜け、 公開設定や製品の不具合 知られている弱点 （既知） まだ知られていない弱点 （未知） 今回は、主に「システムの弱点」の話。次に、対象と原因で種類を整理します。 参考：kokumoto氏の投稿（2026/8/16）を基に再構成。例は本資料で追加。
11. 脆弱性の種類｜対象・原因・具体例 対象 原因の例 診断を 知る 品質を 決める 改善へ つなぐ 具体例 Webアプリ （画面・APIなど） 設計の不備 誰が請求書を見てよいか、 必要なルールが決まっていない。 Webアプリ （画面・APIなど） 実装の不備 決めた権限確認の処理を、 一部で書き忘れた。 プラットフォーム （アプリの動作基盤） 設定の不備 管理画面を、 意図せず外部へ公開している。 プラットフォーム （アプリの動作基盤） 製品の既知の脆弱性 使用中の製品に、公表された弱点がある。 例：Log4jでは、攻撃者にシステムを遠隔操作される可能性のある重大な脆弱性が 見つかり、世界中の企業で影響確認や緊急アップデートが必要になった。 代表例による整理です。アプリにも設定や製品の弱点があり、分類は重なります。 API：Application Programming Interface（プログラム用の窓口） OS：Operating System（機器を動かす基本ソフト） 用語の出典：米国標準技術研究所
12. 脆弱性を見つけるには？ 診断を 知る 脆弱性は、専門家だけが見つけるものではありません。 たとえば、自分が担当しているシステムや製品でも、 • • • • パッチ（修正プログラム）が適用されているか確認する 製品のバージョンが古くなっていないか確認する 設計書どおりに設定されているか確認する 不要な機能や設定が有効になっていないか確認する といったことができます。 日々の確認に加えて、専門的に弱点を確かめる方法もあります。 この資料では、その一つである「脆弱性診断」を取り上げます。 品質を 決める 改善へ つなぐ
13. 脆弱性診断の範囲を、2つの軸で整理 診断を 知る 品質を 決める では、脆弱性診断では何を確認するのでしょうか。 まず「どこから接続するか」と「何を調べるか」で範囲を整理します。 どこから診断するか インターネットから 何 を 診 断 す る か 社内ネットワークから 外部 × Web 内部 × Web 公開Web・API ログイン後の機能も含む 社内Web・認証後の業務機能 （内部から確認する場合） 外部 × 基盤 内部 × 基盤 公開サーバーやネットワーク機器 社内サーバー、 OS、ミドルウェア 例：公開された請求書サイトの機能を調べるなら「外部 × Web」。 改善へ つなぐ
14. 診断員は何を確かめるか 診断を 知る 品質を 決める 改善へ つなぐ ① 診断は「決めた範囲」を確かめる 対象 × 期間 × 権限 × 方法を合意して確認 1 実施許可 2 → 安全な準備 3 → 探す・確かめる 4 → 評価・報告 ② 正常な使い方を少しずつ変え、想定外でも本来のルールどおり動作するか 本人確認 なりすませないか 権限 他人の情報を見られないか 入力と出力 入力を命令として扱わないか 手順と状態 手順を飛ばせないか 設定と公開情報 不要な機能が公開されていないか 参考：OWASP「Webセキュリティテストガイド」／具体例・説明：本資料
15. ツール・手動で探しやすい例 診断を 知る 品質を 決める 改善へ つなぐ 繰り返しを広く試すツールと、操作を組み立てる手動診断を組み合わせます。 1 ツールで探しやすい例：入力に対する異常な反応 多くの入力欄へ検証用の入力を送り、応答の変化を比較する。 同じパターンの検査を、広い範囲へ繰り返すのが得意です。 2 手動で探しやすい例：利用者を切り替えた権限の確認 AさんとBさんのアカウントで、互いの請求書にアクセスしてみる。 画面の遷移やログイン状態を変えながら、届く範囲を確かめます。 3 手動で探しやすい例：業務の手順を変える確認 承認前に確定できないか、承認後のデータを変更できないかを試す。 機能や状態を組み合わせ、想定外の操作を組み立てて確認します。 得意分野の違いです。ツールの候補も人が検証し、権限の検査も条件次第で自動化できます。 参考：OWASP「Webセキュリティテストガイド」／具体例・説明：本資料
16. 第1章のまとめ 診断を 知る 品質を 決める 診断は、決めた範囲で、本来のルールに反する動作が できないかを確かめます。 1 脆弱性は、悪用されると被害につながる弱点 アプリと基盤、設計・実装・設定・製品の弱点など、切り口を分けて見る。 CVEのある問題だけが、診断対象になるわけではありません。 2 正常な操作を理解し、使い方を変えて確かめる 本人確認・権限・入力・手順など、本来のルールどおりに動作するか。 許可された対象・方法の範囲で、結果と再現条件を記録する。 3 ツールと手動診断を組み合わせる 広い範囲への繰り返しはツールで、操作や状態の組合せは手動で確認する。 どちらか一方で十分とは限らず、目的に合わせて組み合わせます。 次の章へ：診断結果を、判断に使える材料にする条件を考えます。 改善へ つなぐ
17. 第２章 診断の品質を決めるもの
18. 品質の前提：何を、どこまで確認したか 診断を 知る 品質を 決める 改善へ つなぐ 同じ「問題なし」でも、確認できた範囲は異なる 対象 × 期間 問題が見つからなかった × ≠ 権限 × 脆弱性が存在しない システム全体が安全である 例：Aさんのアカウントだけなら、 Bさんの請求書へのアクセスは未確認になり得る 方法
19. 準備不足は、何の見落としにつながる？ 必要な材料・環境 診断を 知る 品質を 決める 改善へ つなぐ 足りないと、何が起きる？ 仕様・権限のルール 代理閲覧など、正しい動作を誤って指摘する 画面・APIの一覧 一覧にない請求書APIを診断から漏らす Aさん・Bさんと権限別アカウント 他人のデータ・管理者機能へのアクセスを試せない 状態別のテストデータ 承認済みデータがなく、承認後の改ざんを見落とす 本番との差分・到達経路 設定差や防御の遮断で、本番の弱点を確認できない 診断対象への接続方法 専用の接続や接続元の許可がなく、対象を確認できない 未確認の範囲を記録し、追加確認・再診断の要否を合意します。 診断自体の業務への影響に備え、実施条件・中止条件も事前に合意します。
20. 同じ請求書サイトでも、準備で結果が変わる 診断を 知る 品質を 決める 改善へ つなぐ 例えば 「他人の請求書が見えないか」を調べたい場合 材料が足りないと 必要な材料が揃うと Aさんのアカウントだけを用意。 Bさんの請求書は特定できない。 2人の間の権限確認ができず、 弱点を見落とす可能性が残る。 2人のアカウントと請求書を用意。 互いの請求書は見られないと合意。 AさんからBさん、BさんからAさんへ。 確認した再現手順と根拠を報告する。 品質を決めるのは、検査の数だけでなく「必要な条件を確かめられたか」 参考：OWASP「Webセキュリティテストガイド」／具体例・説明：本資料
21. 診断経路で、確認できる範囲が変わる クラウド上に作るネットワーク Azure DNS 名前解決 外部から診断 Internet経由 品質を 決める 改善へ つなぐ 仮想ネットワーク（ Azure） DNS 1 診断を 知る Web用の区画 （サブネット） 診断対象：Webサーバー Internet 外部：利用者・攻撃者に近い経路で、 対象への到達と操作の成立を確認。 WAF FW WAF Azure Firewall 公開経路：防御による遮断も確認 内部：防御機器の内側から、 Webアプリや基盤自体の弱点を確認。 Web 直接診断 2 内部から診断 仮想ネットワーク内 DNS：サイト名から接続先を調べる Domain Name System WAF：Webへの攻撃を検知・遮断 Web Application Firewall FW：条件に従い通信を通す・止める Firewall（ファイアウォール） 構成例：実際の診断経路は、ルーティングと許可設定によります。 何を確認したいかによって、診断経路を選びます。 ①外部からの攻撃の成立 ②対象そのものの弱点 参考：Microsoft Learn（通信・防御の役割）／構成図：本資料の例
22. 診断の品質は、検証と報告でも変わる 診断を 知る 品質を 決める 改善へ つなぐ 診断結果の信頼性は、検証の正確さと報告の明確さが大切 検証の品質 報告の品質 検出した事象が本当に脆弱性であることを正しく確 認できているか。再現性や影響を確かめることで、 信頼できる結果につながります。 検証で確認した内容を受け手が正しく判断 できるように伝えられているか。再現手順や 根拠、影響範囲、確認できたこと/できな かったことを明確に示すことで、適切な対応 判断につなげることができます。 例、他ユーザーの請求書を見てもよいアカウント だった。 「問題なし」と「確認できなかった」を、正しく分けて報告 参考：OWASP「Webセキュリティテストガイド」／具体例・説明：本資料
23. 第2章のまとめ 診断を 知る 品質を 決める 必要な確認ができ、結果の根拠と未確認の範囲が分かること。 それが、判断に使える診断につながります。 1 確認する範囲と、確認できない条件を明らかにする 対象・期間・権限・方法を合意し、未確認の範囲と理由を残す。 同じ「問題なし」でも、確認できた範囲は異なる 2 本来の動作を確かめられる材料と環境を揃える 仕様、画面・API一覧、Aさん・Bさんと権限別アカウント、データを用意する。 目的に合う接続経路を揃え、本番との差分や遮断の影響を記録する。 3 再現と影響を確かめ、根拠の分かる報告につなげる 再現性や影響を確かめることで、信頼できる結果につながり、 再現手順・証拠・評価根拠を残し、判断と修正に使える形で渡す。 次の章へ：事実・権限・影響を確認し、対応方針・期限・役割を決めます。 改善へ つなぐ
24. 第３章 診断結果から、対応と運用を判断する
25. まず、操作と結果を確かめる Step 1 何が起きたか確認する 確認した範囲と、 再現できる条件も確認する。 前提 Aさんのアカウントで ログインした。 操作 URLの請求書IDを、 Bさんのものに変えた。 結果 Bさんの請求書が 表示された。 誰が・何をして・どうなったかを、報告書から読み取る。
26. Aさんが閲覧してよい請求書はどれか 診断を 知る 品質を 決める Step 2 本来許される動作か確認する 誰が、どの請求書を見てよいか 本人分だけか、経理担当も代理で見てよいか。 業務ルールと仕様を確認し、そのルール自体が適切かも確かめる。 本来の権限と、実際の動作を照らし合わせる ログインで「誰か」を確かめるのが認証。 その請求書を「見てよいか」を確かめるのが認可。 Aさんの権限と、実際の動作を照らし合わせる。 参考：OWASP「Webセキュリティテストガイド」／具体例・説明：本資料 改善へ つなぐ
27. 同じ危険度「高」でも、対応は変わる 診断を 知る 品質を 決める 改善へ つなぐ Step 3 自社への影響と緊急性を判断する まだ不正に閲覧できる 情報の重要性や影響範囲を確認する。被害が続くおそれがあるため、原因調査 と並行して、まず閲覧できない状態にする。 すでに閲覧できないよう止めている 停止した状態を維持し、原因を修正して、安全を確認してから再開する 同じ「High」の脆弱性でも、今も悪用できるのか、閲覧できないように止めているかによって、初動の緊急 性は変わる。 想定例：いずれも報告時はHigh（高）。危険度の区分・定義は診断ベンダーによります。
28. 対応の担当・期限・完了条件を決める Step 4 対応方針・期限・役割を決める 当面の運用 被害を抑える効果と業務への影響から、 継続・機能制限・一時停止を選ぶ。 修正の担当と期限 原因を直す担当者と、修正の期限を決める。 完了・再開の条件と判断者 修正後の確認方法・担当者と、完了・再開の条件を決める。 残る危険を受け入れるかは、権限を持つ責任者が判断する。 判断の根拠と、状況を見直す日も記録する。 診断を 知る 品質を 決める 改善へ つなぐ
29. 修正の完了は、確認結果で判断する 診断を 知る Step 5 修正後の確認 修正の反映と、問題の解消 修正が反映された環境で、同じ操作や別の経路から確かめる。 権限のない閲覧は拒否され、正当な閲覧はできるか。 他の機能への影響 他の権限確認や通常の機能に、修正の悪影響がないか確かめる。 完了・再開の判断 確認結果・未確認の点・残る危険を記録し、責任者が判断する。 再発防止：似た機能も確認し、必要な修正を行う。 原因を踏まえて、要件・設計・レビュー・テストを見直す。 品質を 決める 改善へ つなぐ
30. 最初の報告書に戻って、振り返ってみます この報告を受け取ったとき、何を確認し、どう対応を決めますか？
31. 冒頭の問いへの回答 この報告を受け取ったとき、何を確認し、どう対応を決めますか？ 1. 何が起きたか確認する 使用したアカウント、変更した請求書ID、 閲覧できた請求書、同じ操作の再現性を確認する。 2. 本来許される動作か確認する AさんにBさんの請求書を閲覧する権限があるか。 業務・権限ルールと、そのルールの適切さを確認する。 3. 自社への影響と緊急性を判断する 対象の利用者、請求書の情報、外部からの操作の可否、 暫定的に閲覧を制限できるかを確認する。 4. 対応方針・期限・役割を決める 継続・機能制限・一時停止、修正箇所と期限、判断者と 担当者、修正後の再確認・再診断の範囲を決める。 危険度に、事実・本来の権限・自社への影響・暫定対策を合わせて対応を決めます。 漏えいが続くおそれがあれば、詳細な判断を待つだけでなく、暫定措置を優先します。
32. まとめ 診断を 知る 品質を 決める 脆弱性診断は、弱点を見つけて会社の改善につなげるためのものです。 1 決めた範囲で、弱点を確かめる 正常な使い方を変え、本来のルールどおり動作するか確認する。 診断で問題が見つからなくても、すべての安全を証明したことにはならない。 2 必要な準備を整え、確認したこと・できなかったことを残す 安全な実施条件を合意し、仕様・アカウント・接続方法を揃える。 再現と影響を確かめ、評価の根拠と未確認の範囲を残す。 3 自社への影響から対応を決め、直ったことまで確かめる 事実、本来の権限、自社への影響から、対応方針・期限・役割を決める。 修正後の確認を行い、似た問題の確認や開発・運用の改善につなげる。 報告書を受け取ったら、判断・対応・修正確認までつなげましょう！ 改善へ つなぐ
34. 参考資料 診断を理解するための補足 ここからは、さらに詳しく知りたい方向けの補足です。 必要なときに参照してください。
35. 参考情報(References) 本資料は、セキュリティ分野の有識者や各種ガイドラインなど、幅広く参考にしています。 1 OWASP：ソフトウェアの安全性向上に取り組む団体 Open Worldwide Application Security Project の略。 公開しているWebのセキュリティテストガイドを、診断の説明に参照。 ２ FIRST：セキュリティ対応チームの国際的な団体 Forum of Incident Response and Security Teams の略。 製品の脆弱性情報を読む共通の評価方法は、巻末の参考資料で補足します。 3 その他、参考になるなと思った情報 各ページの下部に参考にした情報源へのリンクを掲載しています。 参考：OWASP公式紹介／FIRST公式紹介（個別リンクは各項目）
36. 参考｜Webアプリの脆弱性の具体例 診断を 知る 品質を 決める 改善へ つなぐ まずは名称よりも、「どんな操作で、どんな被害が起こるか」を 押さえましょう。 XSS Cross-Site Scripting クロスサイト・スクリプティング SQLi SQL Injection SQLインジェクション IDOR Insecure Direct Object Reference 安全でない直接オブジェクト参照 投稿に紛れた不正なスクリプトが、閲覧者のブラウザで動く。 例：正規のページ内に偽の入力フォームを表示される。 検索などの入力が、データベースへの命令として扱われる。 例：本来は読めない顧客情報まで読み出される。 情報を指定する番号などを変えると、他人の情報に届く。 例：請求書1048を1049に変えると、Bさんの請求書が見える。 SQLは、データベースの検索・更新などに使う言語です。 「何を変えると、何が起きてしまうか」で考えます。 参考：OWASP「Webセキュリティテストガイド」／具体例・説明：本資料
37. 参考｜業務への影響を抑える準備 診断を 知る 品質を 決める 改善へ つなぐ 必要な確認ができる条件に加え、業務への影響を抑える条件も整えます。 診断で起こり得る影響 影響を抑えるための準備 攻撃に似た入力や操作により、 負荷・データ変更が起こり得る。 負荷の上限・禁止操作を決める。 テストデータを使い、実データを守る。 監視や防御が攻撃と判断し、 警報・通信遮断が起こり得る。 監視担当と実施日時・範囲を共有。 中止条件・緊急連絡・復旧を決める。 目的・許可・対象・期間を合意し、 証跡の保管・共有と診断後の片付けも決めます。
38. 参考｜実施の安全・品質・結果の判断 診断を 知る 同じ「安全」という言葉でも、何を確かめる話かを分けます。 1 診断実施時の安全性：診断で障害や被害を起こさない 実データを壊さない、負荷を抑える、中止条件や復旧手順を決める。 第2章では、診断前に整える実施条件として扱いました。 2 診断の品質：必要な確認を行い、根拠と限界を報告する Aさん・Bさんの権限を検証し、再現の証拠と未確認の範囲を残す。 第2章では、判断・修正に使える結果を得る条件として扱いました。 3 結果に基づく安全性の判断：対応と運用を決める 会社が影響と残るリスクを踏まえ、停止・再開や修正期限を判断する。 診断品質が高くても、対象が危険だと分かることがあります。 指摘の少なさだけでは、診断の品質も、対象の安全性も判断できません。 品質を 決める 改善へ つなぐ
39. 参考｜脆弱性診断以外にもある確認方法 診断を 知る 品質を 決める 日々の確認でも、多くの弱点を見つけることができます。 ただし、それだけですべての脆弱性を見つけられるわけではありません。 たとえば、 • • • • インターネットから自社がどう見えているのか 複数の設定や機能を組み合わせると攻撃できないか 実際に攻撃者の立場で操作すると何ができるのか 組織として攻撃を検知し、対応できるのか 専門的に確かめる方法の例です。 本編では、この中の「脆弱性診断」を扱いました。 ASM 外部から見える機器・サービスを継続して把握・評価 脆弱性診断 決めた対象に、どのような弱点があるか ペネトレーションテスト 想定した攻撃者が、決めた目的を達成できるか TLPT 自社を狙う攻撃の情報をもとに攻撃を再現し、 システムの防御と、組織の検知・対応を確かめる 改善へ つなぐ
40. 参考｜専門的な確認方法の名前と目的 診断を 知る 品質を 決める 前の参考ページで紹介した確認方法を、目的とともに補足します。 1 ASM：Attack Surface Management アタックサーフェス・マネジメント。外部から見える機器やサービスを 見つけ、攻撃の入口になり得る問題を継続して把握・評価する。 2 ペネトレーションテスト：Penetration Testing 侵入テスト。想定した攻撃者が、決めた目的を達成できるかを確かめる。 個々の弱点の発見に加え、組み合わせた攻撃の成立も見る。 3 TLPT：Threat-Led Penetration Testing 脅威ベースのペネトレーションテスト。現実の脅威の情報を基に、 攻撃を再現して、組織の防御・検知・対応が機能するかを確かめる。 診断・ASM・ペネトレーションテスト・TLPTは、調べる目的や範囲が異なります。 参考：経済産業省 ASM導入ガイダンス／金融庁 TLPT報告書（各項目から参照） 改善へ つなぐ
41. 参考｜CVEとは 診断を 知る CVE：Common Vulnerabilities and Exposures（共通脆弱性識別子） 1 公表された脆弱性を、共通の番号で識別する仕組みです。 2 製品の注意喚起や修正情報を、同じ番号で照合できます。 3 CVEが付いていない弱点もあるため、 番号の確認だけで診断は完結しません。 定義：CVE Program「Overview」／具体例・説明：本資料 品質を 決める 改善へ つなぐ
42. 参考｜製品の弱点を評価するCVSS 診断を 知る 品質を 決める 製品の脆弱性情報を読み、パッチ適用などを検討する材料の一つです。 1 CVSS：Common Vulnerability Scoring System 共通脆弱性評価システム。FIRSTが公開する、深刻さを伝える共通の基準。 攻撃の条件や影響などを評価し、0.0〜10.0の点数で表します。 2 目的：深刻さを、共通の観点と根拠で伝える 「危険そう」という感覚だけでなく、何を根拠に評価したかを共有する。 点数とともに、版・評価項目・算定条件を見て比較します。 3 使いどころ：利用製品の弱点への対応を検討 製品ベンダーや注意喚起の情報から、自社の対象製品・版を確認する。 評価を参考にしつつ、自社への影響や対策状況を加えて判断します。 本編の診断結果はベンダー評価が起点。ここは、製品の脆弱性情報を読む補足です。 定義・区分：FIRST「CVSS v4.0 Specification Document」 改善へ つなぐ
43. 参考｜CVSSに自社の環境を加味する 診断を 知る 品質を 決める CVSS v4.0では、基本・環境・脅威の評価を区別して読みます。 1 基本評価：脆弱性そのものの特性 攻撃に必要な条件や、悪用された場合の影響を評価します。 公表されている基本評価だけでは、自社の使い方までは分かりません。 2 環境評価：自社の構成・重要度を反映 機密性・完全性・可用性の重要度や、環境によって変わる攻撃条件を反映。 例：機密情報を扱うか、構成上どの経路から攻撃できるかを確かめます。 3 脅威評価：現時点の悪用状況を反映 実際に悪用されているかなど、時間とともに変わる情報を反映します。 環境評価と合わせ、評価の前提・根拠・確認日を残して利用します。 点数は判断材料の一つ。業務停止の影響や、修正作業の制約も合わせて判断します。 定義：FIRST CVSS v4.0 Specification／具体例・説明：本資料 改善へ つなぐ