政府情報システムにおける脆弱性診断導入ガイドライン

2022（令和 4）年 6 月 30 日
デジタル庁

〔標準ガイドライン群ＩＤ〕
DS-221〔キーワード〕
セキュリティ、脆弱性、脆弱性診断〔概要〕
政府情報システムの関係者が脆弱性診断を効果的に導入するための基準及びガイダンスを提供する。

改定履歴
改定年月日
2022年6月30日

改定箇所
-

改定内容
初版決定

目次
１ はじめに ......................................................... 2
１.１ 目的とスコープ .............................................. 2
１.２ 適用対象 .................................................... 3
１.３ 位置づけ .................................................... 3
１.４ 本書の構成 .................................................. 3
２ 脆弱性診断の概要 ................................................. 4
２.１ 脆弱性対策における脆弱性診断の位置付け ...................... 4
２.２ 一般的な脆弱性診断の種別 .................................... 6
1) プラットフォーム診断 ......................................... 72) Web アプリ診断 ................................................ 83) スマートフォンアプリ診断 ..................................... 94) その他の脆弱性診断 .......................................... 12
２.３ 脆弱性診断を行うにあたっての留意事項 ....................... 121) 脆弱性診断サービスの選定 .................................... 122) 検出された脆弱性の深刻度評価 ................................ 123) 脆弱性診断に伴うリスク ...................................... 13３ 政府情報システムにおける脆弱性診断の実施基準 .................... 15
３.１ 脆弱性診断の対象システム ................................... 151) 構築時診断 .................................................. 152) 定期診断 .................................................... 16
３.２ 脆弱性診断の実施範囲 ....................................... 161) 構築時診断 .................................................. 162) 定期診断 .................................................... 18
３.３ 脆弱性診断の実施要件 ....................................... 181) 全ての脆弱性診断に共通する要件 .............................. 192) プラットフォーム診断に関する要件 ............................ 213) Web アプリ診断に関する要件 ................................... 224) スマートフォンアプリ診断に関する要件 ........................ 23
３.４ 検出された脆弱性の対応方針 ................................. 23
４ 付録 ............................................................ 24
付録 A. 各種診断で検出対象とする脆弱性種別 ........................ 24
1) プラットフォーム診断 ........................................ 24
2) Web アプリ診断 ............................................... 243) スマートフォンアプリ診断 .................................... 26
付録 B. 参考資料 .................................................. 26

1

１ はじめに
社会全体のデジタルトランスフォーメーションが加速し、我々を取り巻く様々な分野において ICT の利活用が進んでいる。他方、サイバー攻撃はその発生頻度の増加と高度化が続く状況下にあり、サイバーセキュリティ対策のさらなる強化が不可欠となってきている。こうした中で、政府情報システムに対しても、今後、サイバー攻撃の脅威は高まっていくことが予想される。
政府情報システムは国民生活や行政の活動の根幹を支える基盤であり、これらのシステムにおけるインシデントは社会基盤の機能停止に直結するリスクがある。このため、令和 3 年度に閣議決定されたサイバーセキュリティ戦略1に基づき、任務及び機能の自律性の毀損に繋がるおそれのあるサイバー空間の脆弱性を把握し、その信頼性確保に向けた取り組みが必要となる。
多くの政府情報システムでは、これまでにも脆弱性やセキュリティリスクの特定を目的として脆弱性診断を導入してきているが、その診断対象や診断サー
ビスの選定に明確な基準や指針があるとは言えない状況にある。
脆弱性診断の実施においては、診断に対する正しい理解を持ち、高度な専門性に加え、安全性確保のための体制を有する適切なセキュリティベンダーから診断サービスを調達する必要がある。また、診断の手法は多岐に渡り、一つの手法
でシステムのセキュリティリスクの全体像を把握することは困難であることか
ら、適切な診断手法を組み合わせて行う必要がある。さらに、脆弱性診断は実施するだけでなく、検出されたセキュリティリスクを基点としてシステムや組織の弱点を見直し、セキュリティの実施計画の改善や強化につなげることが重要となる。このような観点を踏まえ、本書では、政府情報システムの関係者が脆弱性診断を円滑かつ効果的に進めるための基準及びガイダンスを提供する。
１.１ 目的とスコープ
本書は、政府情報システムに対する脆弱性診断を効果的に実施することを目的として、政府情報システムの管理責任や各機関のセキュリティ管理を担う職員に対して、脆弱性診断を実施する際の基準及びガイダンスを提供するものである。各機関では、本書を参考に脆弱性診断の実施計画の立案、調達を行うことが望ましい。また、既に脆弱性診断を実施している機関では、実施してきた診断
内容を見直す際の参考にすることが望ましい。
本書で述べる基準は令和 3 年度版の「政府機関等のサイバーセキュリティ対策のための統一基準群2」（以下、「統一基準群」という。）における「脆弱性検査

1

https://www.nisc.go.jp/pdf/policy/kihon-s/cs-senryaku2021.pdf

2

https://www.nisc.go.jp/policy/group/general/kijun.html

2

を含む情報セキュリティの観点での試験を実施」（基本対策事項 5.2.2(2)-1 e））
及びソフトウェアの脆弱性対策を目的とした「脆弱性診断を実施」（基本対策事項 6.2.1(1)-3 b)）を行う際の実施基準としての活用を想定する。また、「自己点検の実施」（遵守事項 2.3.1(2)(a)）を背景に点検の手段として脆弱性診断を行う際や、情報セキュリティ監査における「実際の運用が情報セキュリティ関連規定に準拠していること」（遵守事項 2.3.2(2)(a)(ウ)）の確認手段として脆弱性診断を取り入れる際の実施基準としての活用も想定に含む。
１.２ 適用対象
本書は、政府情報システムにおいて広く導入されている以下の 3 種類の脆弱性診断を適用対象とする。
・プラットフォーム脆弱性診断（以下、「プラットフォーム診断」という。）
サーバやネットワーク機器等に対して行う脆弱性診断を示す。
・Web アプリケーション脆弱性診断（以下、「Web アプリ診断」という。）
Web アプリケーション（以下、「Web アプリ」という。）に対して行う脆弱性診断を示す。
・スマートフォンアプリケーション脆弱性診断（以下、「スマートフォン
アプリ診断」という。）
Google Android や Apple iOS/iPadOS 端末上で動作するスマートフォン
アプリケーション（以下、「スマートフォンアプリ」または「アプリ」という。）に対して行う脆弱性診断を示す。
なお、本書は脆弱性診断の導入に対する理解を深めるための参考文書であり、適用の遵守を求めるものではない。
１.３ 位置づけ
本書は、標準ガイドライン群の一つとして位置づけられる。
１.４ 本書の構成
２章では、脆弱性診断を推進する上で必要となる基本的な事項を概説する。はじめにシステムの脆弱性対策における脆弱性診断の位置付けを示し、次に脆弱性診断の手法の違いや診断サービスを選定し実施する上での留意事項を示す。
３章では、２章を踏まえ、政府情報システムにおける脆弱性診断の実施基準を示す。この中では、システム開発段階で実施する診断に加え、自己点検や情報セ
キュリティ監査を目的として定期的に脆弱性診断を行う際の実施要件も示す。

3

２ 脆弱性診断の概要
本章では、脆弱性診断を効果的に推進する上で必要となる基本的な事項を解説する。脆弱性診断はシステムにおけるセキュリティ上の弱点を特定するものであるが、診断のみでシステムのセキュリティリスクを防ぐことはできない。また、脆弱性診断は既に作り込まれた脆弱性を検出するものであるが、それ以前に脆弱性の発生を未然に防ぐことが肝要である。こうした背景から、脆弱性診断は他のセキュリティプロセス（パッチマネジメントやセキュアコーディング、セキュリティレビュー等）と組み合わせて実施することが望ましい。さらに、脆弱性診断の検出結果をセキュリティプロセスそのものの改善に役立てていくことが
望ましい。
２.１

脆弱性対策における脆弱性診断の位置付け

本節では、はじめにシステムの脆弱性対策全体を俯瞰し、その中における脆弱性診断の位置付けを明らかにする。図 ２-１は、システムにおける脆弱性を集合として表したものである。

図 ２-１

システムにおける脆弱性の分類

図 ２-１では、次の集合を定義している。
・システムにおける脆弱性全体 (U)当該のシステムにおいて本来対処すべき脆弱性の母集団と定義する。サイバー攻撃の高度化や新しい攻撃手法の発見、システム構成の複雑化等の複合的な要因により、(U)は時間とともに増えていく構造にある。

4

・発生の想定される脆弱性 ( )脆弱性の母集団( )のうち、システム開発に関わるステークホルダーが発生を予期できる脆弱性の集合を( )と定義する。( )には、過去に検出されたことのある脆弱性や一般的によく知られている脆弱性等が含まれる。往々にして、( )の集合の大きさはシステムに携わる者の知見に左右される。政府機関においては、外部有識者の知見を活用し、組織や開発プロセスを通じて( )を補強していく必要がある。また、母集団( )が拡大を続けていく中、最新の脅威情報に基づき、常に( )を最新化していくことが必要である。
・仕様や要件としてカバーしている脆弱性 ( )集合( )は発生の想定される脆弱性( )の部分集合にあたり、各機関の情報セキュリティポリシーや開発の要件定義等において発生を防ぐための対策が求められるものである。対策内容が明示的であることから、仕様や実装に適切に反映されていること（トレーサビリティ）の確認や、対策状況について第三者による確認や検証が可能である。理想的には( )を( )に近づけていくことが望ましいが、( )には有識者ならではの暗黙的な知見や、汎化や明文化の難しい各システム固有の脅威も含まれることから、部分的とならざるを得ない状況にある。
・想定外の脆弱性( ̅)
集合( ̅)は、システム開発に関わるステークホルダーでは発生の予期できない脆弱性である。システムを運用していく中では、予期しない脆弱性が常に発生しうることを認識しておくことが重要である。サイバー攻撃に悪用される脆弱性は母集団( )であることから、攻撃を防ぐためには、発生を予期できる脆弱性( )を( )に近づけて行くための取り組み
や、攻撃者の目線から( ̅)の存在をテストするといった取り組みが必要となる。
上記の構造を踏まえた上で、脆弱性診断は発生の想定される脆弱性( )の確認を目的として実施することが望ましい。これには、仕様や要件としてカバーすべき脆弱性( )として本来対処すべきであったものの漏れを検出することや、発生が想定される脆弱性( )のうち政府機関内の知見ではカバーできていなかったものを検出することが含まれる。
脆弱性診断そのものは既に発生してしまった脆弱性を検出するものであることから、セキュリティ・バイ・デザイン等の取り組みを強化し、脆弱性が作り込まれない状態を目指していくことが重要である。また、脆弱性診断は対象システ
ムにおける将来の脆弱性の発生を防ぐものではないことから、診断で検出され5

た脆弱性はシステム開発の要件定義や組織のセキュリティプロセスに反映し、( )の対策の強化につなげていくことが望ましい。
想定外の脆弱性( ̅ )の対策には脆弱性報奨金制度により未知の脆弱性の検出を試みること等が挙げられるが、本書のスコープからは除外するものとする。
( ̅)の対策は際限なく実施できるため、システムが侵害された際のリスクや費用対効果を鑑み、対策の実施内容を決めることが望ましい。
２.２

一般的な脆弱性診断の種別

図 ２-２は、システムに脆弱性が混入しうる箇所を部位ごとにまとめたもの
である。
aa

e
ache

/

e

/

/

図 ２-２

情報システムにおける脆弱性の発生部位

図 ２-２が示すとおり、脆弱性の発生箇所はシステムの広範に渡る。攻撃のア
クターはこれら全体の中から脆弱性を見つけ出し悪用しうることから、その対策もまたシステム全体を網羅的に行う必要がある。セキュリティベンダーが提供する診断サービスもまた、診断対象の部位に応じてサービスが分かれている。
本書が対象とする 3 種類の脆弱性診断は、図 ２-２の次の部位を対象とする。
上記の脆弱性診断は、脆弱性の発生部位に応じて組み合わせて行う必要がある。
・プラットフォーム診断
FW（ファイアウォール）、LB（ロードバランサ）、リバースプロキシ、仮想化インフラ、サーバ OS（ゲスト OS）、サーバミドルウェア、VPN
・Web アプリ診断
Web アプリ、アプリミドルウェア
・スマートフォンアプリ診断
スマートフォンアプリ

6

昨今は VPN 機器や外部ネットワークに接続されている複合機等が攻撃の起点として狙われていることから、これらも診断対象とする必要がある。また、連携する外部システムも侵入の糸口となるおそれがあることから、脆弱性診断の実施状況等を確認することが望ましい。
1)プラットフォーム診断
プラットフォーム診断は、対象のサーバやネットワーク機器等に対して疑似的な攻撃の通信を行うことにより、脆弱性やセキュリティリスクの有無を確認するものである。一般的には自動化されたツールを用いて診断を行い、誤検出（偽陽性）の精査やツールでは検出できない脆弱性の診断を人手で補う。
プラットフォーム診断では、主に表 ２-１のようなセキュリティ上の問題が検出される。
表 ２-１

プラットフォーム診断で検出される脆弱性

脆弱性の種別概要

不要ポートの ポートスキャンにより通信可能なポートを確認する。結果
開放として、外部からの接続を意図していないオープンポート
や、第三者に仕掛けられたバックドア等の不審なサービスが検出される。
脆弱なソフト 上記で検知したオープンポートに接続を試み、サーバからウェアの利用 取得したバナー情報に基づき、ポートを待ち受けている OSやミドルウェアの情報を推定する。結果として、既知の脆弱性を含むバージョンのソフトウェアの利用等が検出され
る。
設定の不備

主にツールに搭載されたシグネチャに基づき、サーバの設定不備を確認する。結果として、推測可能なパスワード（システムの初期パスワード等）や意図しない情報の公開等の問題が検出される。

プロトコル固 主にツールに搭載されたシグネチャに基づき、プロトコル
有の脆弱性
固有の脆弱性を確認する。結果として、DNS、FTP、SSH、POP、
SMTP、TELNET、SSL/TLS 等のプロトコルを扱うソフトウェアの脆弱性や、脆弱なアルゴリズムの利用等が検出される。
プラットフォーム診断には、外部診断（リモート診断）と内部診断（オンサイト診断）が存在する。外部診断は、グローバル IP アドレスを通じてインターネ
ットからアクセス可能な装置を対象とし、セキュリティ境界の外側より攻撃者

7

が悪用可能な脆弱性を明らかにすることを目的とする。一方の内部診断は、シス
テム内のネットワークや拠点の LAN 内等における主にプライベート IP アドレスを有する装置を対象とし、セキュリティ境界の内側で、内部犯や境界防御を超えて侵入した外部の攻撃者により悪用されうる脆弱性を明らかにする。
過去に診断を実施していない場合、優先して実施すべきは外部診断である。外部診断の場合、診断対象はグローバル IP アドレス単位となり、診断の費用は IP
アドレス数に応じて変動する。内部診断もまた、診断対象の IP アドレス数に応じて費用が変動する。また、現地に出向いて診断を行うことに対する追加費用が生じることがある。
新しい脆弱性や攻撃手法は日々公表されるため、診断サービスの選定においては、最新の脆弱性情報を収集し診断項目に反映させていることの確認が必要である。また、ツールの検出結果には誤検出や実際には攻撃の困難な指摘事項が含まれうるため、診断対象のシステムに対する現実的な攻撃の発生可能性に基づいて対応要否を判断する必要がある。
2)Web アプリ診断
Web アプリ診断は、対象の Web アプリ（Web API を含む）に対して疑似的な攻撃のリクエストを行うことにより、情報漏えいやサイト改ざん等につながる脆
弱性の有無を確認するものである。診断手法には、ツールによる自動診断、専門家による手動診断、両者を併用するものの 3 種類が存在する。情報処理推進機
構（IPA）の「安全なウェブサイトの作り方3」等のセキュリティ標準への準拠を謳う診断サービスも存在する。
Web アプリ診断では、主に表 ２-２のような脆弱性が検出される。
表 ２-２
大分類

3

Web アプリ診断で検出される脆弱性

分類

脆弱性の例

(A)Web ア(A-1)固有のビジネ ID 連携の不備により他のユーザになりす

プリの仕
様に起因
する脆弱
性

スロジックに依存 ましができる等
するもの(B)Web ア
プリの実
装に起因(B-1)実装のメカニ レースコンディションによるデータの不ズムに対する高度 整合、Office ファイルの投稿機能におけな理解が要求され る XML 外部エンティティ参照（XXE）、電(A-2)一般的な仕様 他人のデータを読み書きできる、管理者
上の不具合
権限の機能を誰でも利用できる、パスワ
ードリセット機能の悪用、認証の回避等

https://www.ipa.go.jp/security/vuln/we security.html

8

大分類
する脆弱
性

分類
るもの

脆弱性の例
子署名の迂回等(B-2)一般的な実装 SQL インジェクション、ディレクトリトラの不備
バーサル、クロスサイトスクリプティン
グ等(C)利用する Web アプリミドル ログ出力や画像変換ライブラリ等におけウェア固有の脆弱性
る既知の脆弱性 の悪用 、CMS （Content
Management System）や Web アプリケーションフレームワークの誤用に起因する脆弱性等
ツールによる自動診断は効率の観点では有用であるが、仕様に起因する脆弱性(A)全般の検出が難しい。また、実装上の問題(B)の中でも、対象の Web アプリの内部実装に対する深い洞察を要する脆弱性(B-1)や、一般的な実装の不備による脆弱性(B-2)においても一定の制限を迂回しなければ攻撃できないものが見落とされやすいため、専門家の人手による診断で補強する必要がある。
セキュリティ標準に基づく診断サービスも、テストのカバレッジを確認する
用途では有用であるが、これらの標準がカバーするのは多くの Web サイトに見られる一般的な脆弱性(A-2)(B-2)に留まることから、専門家の知見に基づき、対象の Web アプリに固有の脆弱性(A-1)(B-1)を診断する必要がある。
情報システムの開発では、Web アプリケーションフレームワークや CMS 等の様々なサードパーティのミドルウェアが利用されるため、これらに固有の脆弱性(C)が検出できることも重要である。この中には、個々のミドルウェアが提供する機能の誤用や設定の誤りにより発現するものが含まれるため、システムの利用するミドルウェアの内部構造に精通した専門家による診断が必要となる。
過去に診断を実施していない場合、優先して実施すべきはインターネットからアクセス可能な箇所である。この場合の診断は、対象の外部公開機能に対してインターネットを通じて行われる。診断対象は主に画面数や API 等のリクエス
ト数単位となり、診断の費用もこれらの数によって変動する。
3)スマートフォンアプリ診断
スマートフォンアプリ診断は、Android や iOS/iPadOS 端末上で動作するアプリの脆弱性の有無を確認するものである。診断対象にはアプリ本体に加え、アプ
リとサーバとの間の通信等も含まれる。診断手法にはアプリ本体をツールで自動解析するものや、リバースエンジニアリングを用いるもの、アプリとサーバ間の通信内容に着目し脆弱性を探索するもの等がある。

9

スマートフォンアプリ診断で検出される脆弱性の発生箇所を図 ２-３に示す。

本

デ

e

グ

デ

e
e

図 ２-３

スマートフォンアプリにおける脆弱性の発生箇所4

図 ２-３の(A)〜(C)において検出される脆弱性の代表例は以下の通りである。
表 ２-３

スマートフォンアプリ診断で検出される脆弱性

脆弱性の発生部位

脆弱性の例

アプリ本体(A)・他のアプリから機密情報を参照される・カスタム URL スキーム等のアプリ間連携機能により意図しない機能が実行される・WebView（アプリ上に Web ページを表示する機能）上で悪意のある Web ページを開かされる通信路(B）

・サーバ証明書の検証不備
・平文による機密情報の送受信

外部サービス(C)・アプリにハードコードされた認証情報を用いて外部サービスに不正アクセスされる・アプリにハードコードされた URL を通じて、脆弱な設定のクラウドストレージや MBaaS（Mobile Backend asa Service）の存在が特定される診断サービスを選定する際は、上記の(A)〜(C)に述べた発生部位の脆弱性が4

一般社団法人日本セュ

ィ協会「 ndroid

https://www.jssec.org/dl/android_securecoding/を基10セ ュ 設計・セ ュ
筆者作成

ディ グガ

」

網羅されることを確認する必要がある。また、ツールによる自動解析では実際には悪用できないものが脆弱性として指摘される場合があるため、攻撃の実証までを行う診断サービスを選定することが重要である。さらに、昨今 JVN5等で公表されている脆弱性にはアプリに認証情報がハードコードされている等のリバースエンジニアリングにより発見されるものが見られることから、脆弱性を未然に防ぐためには、ソースコードレビューやリバースエンジニアリング等の手法が含まれる診断サービスを選定する必要がある。
スマートフォンアプリは各利用者の端末上で実行されることや、アプリ本体
を容易に解析可能であることから、セキュリティを確保することが難しい。様々な脅威を全て対策することは不可能であり、また対策にかかる費用も高額となることから、費用対効果に応じて対策を行う必要がある。こうした背景から、
OWASP の「モバイルアプリケーションセキュリティ検証標準（MASVS: Mobile
Application Security Verification Standard）6」では、以下の 3 段階の対策
レベルを定め、各々のレベルの対策内容を定義している。
・MASVS-L1
標準セキュリティレベルであり、スマートフォンアプリにおけるセキュ
リティのベストプラクティスに準拠する。全てのスマートフォンアプリ
に適している。
・MASVS-L2
多層防御に位置付けられ、標準的な要件を超える高度なセキュリティコ
ントロールを導入する。モバイルバンキングアプリ等の機密性の高いデータを処理するアプリに適している。
・MASVS-R
リバースエンジニアリングと改ざんへの耐性を有するレベルであり、アプリに対する様々な攻撃に対して耐性を有する。モバイルゲーム等のように知的財産の保護やアプリの改ざんを防止する必要のあるアプリに適している。
MASVS では、MASVS-L1 は全てのアプリにおいて準拠を求める一方で、MASVS-L2
以上のプラクティスは費用対効果に応じて取捨選択することを推奨している。
脆弱性診断においても、多くの情報システムにおいては、MASVS-L1 相当の水準
で診断を行うことが望ましい。

5

https://jvn.jp/

6https://owasp.org/www-project-mo ile-security-testing-guide/114)その他の脆弱性診断
これまでに述べた脆弱性診断の他にも、様々な種類の診断サービスが存在する。情報システムではなく制御システムや IoT 機器を対象とするもの、システ
ムではなく物理環境、組織とその従業員を対象とするもの等が登場してきている。これらの診断については、政府情報システムにおける導入の必要性が高まってきた際に、適宜、本書のスコープに加えるものとする。
２.３

脆弱性診断を行うにあたっての留意事項

1)脆弱性診断サービスの選定高度化するサイバー攻撃の脅威を未然に防ぐためには、十分な経験と能力を有したセキュリティベンダーの選定を要することから、選定に際しては経済産
業省の定義する「情報セキュリティサービスに関する審査登録機関基準7」を満たすことの確認に加えて、脆弱性を検出する能力を測るため、ペネトレーション
テストの国際資格の保有状況や CTF（Capture The Flag）等のセキュリティコン
テストにおける上位入賞実績、CVE（Common Vulnerabilities and Exposures）の付与された脆弱性の発見数等を問い合わせること等が有効である。また、診断サービスの調達においては、上記の基準に沿った有識者や有資格者が、診断の実施の中で、どのような役割として、何名、どの期間に関わる予定であるかを確認することが望ましい。
診断サービスの選定においては、ツールによる自動的な診断のみでは不十分
であり、専門家による手動による診断との併用が不可欠である。また、手動の診断においても、事前に定義された脆弱性を網羅的に検出することに加え、専門家の知見に基づきリスクベースで追加の脆弱性検出を試みるサービスを併用することが必要である。
脆弱性診断の推進においては、システムの非公開情報や検出した脆弱性をはじめとする機密性の高い情報を取り扱うこととなるため、統一基準群に基づき、情報管理体制を有することの確認が必要となる。また、診断におけるシステムへの影響を最小化するための仕組みやルールの有無に加え、診断を行う要員にルールを遵守させるための取り組みを備えていることを確認することが望ましい。
2)検出された脆弱性の深刻度評価
診断により検出された脆弱性は、保有するシステムに対するリスク評価に基づき、優先度を定め対応する必要がある。こうした脆弱性の評価において世界的7

https://www.meti.go.jp/policy/netsecurity/shinsatouroku/zyouhoukizyun.pdf

12に活用されているのは FIRST（Forum of Incident Response and Security Teams）
が公開する CVSS v3.18である。CVSS v3.1 では、脆弱性そのものの技術的な深刻度を評価する基本評価基準（Base Metrics）と攻撃コードの出現状況等の現状のリスクを算定する現状評価基準（Temporal Metrics）、そして対象のシステム環
境において想定される脅威に応じて最終的なリスクを算定する環境評価基準（Environmental Metrics）の 3 軸に基づき、0.0〜10.0 までのスコアで脆弱性の深刻度を評価する。また、このスコアに応じて、深刻度を以下の 5 段階で表現
している。
表 ２-４

CVSS v3.1 のスコアと深刻度

CVSS v3.1 スコア

深刻度

9.0〜10.0

緊急（Critical）

7.0〜8.9

重要（High）

4.0〜6.9

警告（Medium）

0.1〜3.9

注意（Low）

0.0

なし（None）

脆弱性診断では、検出された脆弱性の深刻度を CVSS v3.1 の基本評価基準で評価することが多い。しかし、基本評価基準はあくまでもその脆弱性の技術的特性を示すものであり、それ単体で対応の優先度を決めるべきものではない。基本
評価基準を参考に自身のシステム環境において想定される具体的なリスクに基づいて対応の優先度を定めることが望ましい。セキュリティベンダーによっては、独自基準で脆弱性の深刻度を評価する場合がある。こうした場合も、CVSS
v3.1 の基本評価基準と同等のものとして扱い、自身のシステムにおけるリスク評価を行う必要がある。
3)脆弱性診断に伴うリスク
脆弱性診断は対象のシステムに対して疑似的な攻撃を仕掛けるため、システ
ムに影響を与えるおそれがある。診断の実施においては、システムに発生しうるリスクを認識し、事前に関係者との間でリスクの低減に向けた取り組みを行う必要がある。生じうるリスクには以下のようなものが挙げられるが、他にも予期しない問題が生じる可能性がある。
・診断の通信によるネットワーク通信帯域の圧迫・システムのクラッシュ等に伴うサービス停止
8

https://www.first.org/cvss/v3-1/

13

・疑似攻撃のペイロードを含むダミーデータのデータベースへの残存・大量のメール送信の発生
・データの破損や損失
・脆弱性の検証に伴う個人情報や機密情報の意図せぬ閲覧・攻撃の検知やエラーの大量発生等に伴う監視アラートの発生
これらのリスクを低減するため、本番環境ではなく検証環境で診断することや、本番環境で行う場合は事前のデータバックアップ等を検討する。また、業務への影響を避けるため、休日や夜間、メンテナンス時間帯等に診断を行うことも考慮し、その旨を発注時にも明記する。診断の開始前には、異常発生時のエスカ
レーションルールや事業継続計画（BCP: Business Continuity Plan）を確認しておくことで、万が一障害が発生した際、迅速な対応が可能となる。
テストを行う際は、影響を受けるおそれのある全ての関係者に対して、事前に周知と診断可否の確認を行う。この際の関係者には主に以下を含むが、対象のシステムによって異なる。
・対象システムの責任者（システムオーナー）
・対象システムの開発や運用者
・対象システムの負荷や異常監視を行う者
・インフラ提供者（クラウドサービスプロバイダー等）
特にインフラ提供者によって禁止されている診断項目や、関係者がリスクを許容できない診断内容は実施を避ける必要がある。プラットフォーム診断等においてサービス妨害（DoS: Denial of Service）の脆弱性を診断する必要がある場合は、明示的に確認を行い、関係者の許可を得る必要がある。診断を行うセキュリティベンダーにも、安全管理の指針を組織として有することの確認や、安全対策に関する項目を盛り込んだ契約を締結する。

14

３ 政府情報システムにおける脆弱性診断の実施基準
本章では、政府情報システムに対して脆弱性診断を行う際の実施基準を示す。
ここでは診断を実施する目的の違いに着目し、以下 2 種類の診断施策を定義する。これらの診断は目的に応じて組み合わせて実施することを想定しており、一方の診断を代替するものではない。
・構築時診断各システムの構築時に行う診断で、脆弱性対策の実施内容の確認やセキ
ュリティ品質の確保を目的として実施するものを示す。各システムの情
報セキュリティ責任者や PJMO 等が、統一基準群の求めるソフトウェア
に関する脆弱性対策に従い、自身の管理するシステムにおける脆弱性対策の一環として実施することを想定する。各システムの開発にあたる者
は、システムの構築や更改時に適切な診断が行われるようにするため、本章の基準に従い、調達仕様書等に脆弱性診断要件を明記するものとする。
・定期診断
各機関で定期的に実施する診断で、各システムの脆弱性対策が適切に実施されていることの点検や監査を目的として実施するものを示す。統一
基準群の求める情報セキュリティ対策における自己点検や情報セキュリ
ティ監査の一環として自組織のシステム全体を視野に実施することを想定する。各機関で定期点検や監査にあたる者は、適切な脆弱性診断が行われるようにするため、本章の基準を参考に、脆弱性診断の実施方針を定義するものとする。
３.１

脆弱性診断の対象システム

1)構築時診断
新規構築または機能追加等の改修を行ったシステムを対象とする。ただし、Web アプリとスマートフォンアプリに対する脆弱性診断は、変更が軽微である場
合の実施を任意とする。実施要否の判断の目安として、以下の変更が行われた場
合には診断を行うことが望ましい。
ア Web アプリ診断
・外部から入力されたデータの処理（フォームや API 等）に追加や変更が
ある場合

15

・動的な画面生成処理に追加や変更がある場合
・認証、暗号化、ファイルアップロード等、実装に注意を要する処理に追加や変更がある場合・開発を担当するベンダーに変更がある場合
イ スマートフォンアプリ診断
・ネットワーク通信に関する処理に追加や変更がある場合
・認証、暗号化等のセキュリティ機能に追加や変更がある場合
・アプリ間連携機能（カスタム URL スキーム等）に追加や変更がある場合・開発を担当するベンダーに変更がある場合
2)定期診断定期診断の対象システムは各機関の自己点検や監査計画に準ずるものとし、本書では選定の基準を設けないものとする。保有するシステムが多く、全てのシステムの診断を行うことが難しい場合は、最高情報セキュリティアドバイザー
等の有識者に相談の上、各システムのセキュリティリスクの大きさや過去の脆弱性診断の実施状況等を踏まえた総合的な判断を行うことが望ましい。
３.２

脆弱性診断の実施範囲

1)構築時診断
当該のシステムに対する外部攻撃のリスク低減を行う目的から、外部から攻撃を受ける可能性のある箇所（アタックサーフェス）の全てを診断の対象とする。
外部との接続点を持たない箇所に対する診断は、システムの脅威環境に応じて任意で実施とする。また、実際の脅威への耐性の確認を目的として、診断対象は本番環境を前提とする。システムに対する影響を許容できない場合は検証環境等での実施も可能とするが、この場合、当該環境のシステム構成が本番環境と同等であることとする。ただし、侵入防止システム（IPS: Intrusion Prevention
System）や WAF（Web Application Firewall）については、脆弱性の存在を隠蔽してしまうおそれがあることから、診断時は無効化しておくことが望ましい。これらの前提を踏まえ、各診断の対象を以下に定義する。実際の診断範囲は、以下の基準に基づき、対象システムの内部構成を把握する開発担当者を交えて検討の上、決定するものとする。

16

ア プラットフォーム診断(1) 追加や構成の変更が生じた全ての外部公開 IP アドレス（グローバル IP アドレス）を診断の対象とする（必須）(2) 診断対象は本番環境とする。システム構成が本番環境と同等である場合に限り、検証環境等での診断を可能とする（必須）(3) IPS や WAF は脆弱性の存在を隠蔽するおそれがあるため、無効化した上で診断を行う（推奨）(4) グローバル IP アドレスを持たない装置に対する診断は、システム内部のネットワークの脅威環境に基づき、必要に応じて実施とする。実施を推奨する例としては、複数の異なるサブシステムが相乗りして利用するマルチ
テナント型のシステムが挙げられる。この場合は、システムを利用する一つのテナントが侵害を受けた際、他のテナントに対して侵害が及ぶ可能性を確認することを目的として、内部診断を行うこととなる（任意）イ Web アプリ診断(1) 新規追加や変更の生じた全ての外部公開インタフェース（動的画面や API等）を診断の対象とする。外部公開とは、ネットワーク層での送信元 IP ア
ドレス制限やクライアント証明書等によるアクセス制限等が施されておらず、インターネットから HTTP（WebSocket を含む）による何らかの通信が可能であるものを示す（必須）(2) 他のシステムと連携する場合は、その外接箇所も診断の対象とする（推奨）(3) IPS や WAF は脆弱性の存在を隠蔽するおそれがあるため、無効化した上で診断を行う（推奨）(4) ネットワーク層での十分なアクセス制限等が施された内部機能（管理者向け画面等）の診断は必要に応じて実施とする（任意）(5) 診断対象は本番環境を前提とする。検証環境等での診断を行う場合は、全ての外部公開インタフェースが本番と同等に診断できるように、診断用のアカウント設定やデータの投入、外部システム連携等の準備を行うものとする（必須）
ウ スマートフォンアプリ診断(1) アプリストアに公開する全ての Android と iOS/iPadOS 向けのアプリを診断の対象とする（必須）(2) 診断対象のアプリは本番用を前提とする。検証用のアプリを対象とする場
合は、サーバとの接続等を含めた全ての機能が本番用と同等に診断できるように準備を行うものとする（必須）172)定期診断
各機関が保有するシステムのインベントリ情報（構成情報）に基づき、構築時診断と同様に外部から攻撃を受ける可能性のある箇所（アタックサーフェス）を対象に診断を行う。
ア インベントリ情報の管理
診断に際して、各機関が保有するインベントリは常に最新化されていることが重要である。インベントリの把握が難しい場合や、把握の抜け漏れが生じうる
場合には、各システム担当者へのヒアリング等に加えて、セキュリティベンダー
の提供する OSINT（Open Source Intelligence）9等のサービスを活用し、定期的なインベントリの見直しを行うことが望ましい。
インベントリ情報の管理対象としては、利用しているグローバル IP アドレスとドメイン名、OS とミドルウェア、サーバや PC 端末、セキュリティ製品(ファイアウォール、WAF、IPS/IDS)、ネットワーク機器(VPN、ネットワーク複合機等のインターネットに接続されるもの)等が例として挙げられる。
イ 脆弱性診断の実施規模
診断の実施範囲はシステムごとに異なり、事前の把握が難しい。このため、定期診断の調達に際しては、上限となる IP アドレス数や画面数を定めた上で調達を行うことが望ましい。この場合、実際の診断時には上限の実施数までの範囲で、優先度を付けて診断対象を選定する形となる。実施規模の目安として、プラット
フォーム診断は 10〜30IP アドレス程度、Web アプリ診断は 50〜100 リクエスト
程度、スマートフォンアプリ診断は 10〜20 画面程度の間で定めると良い。また、実際に各システムの診断対象を決める際は、サイトのトップページから辿れる範囲で行うことや、同様の作りの画面が複数ある場合は代表する 1 画面のみを診断対象とすること等の選定方針を決めておくと良い。また、同じシステムを再度診断する場合は、過去に行った診断とは異なる画面や API を対象とすることが望ましい。いずれにせよ、最終的な診断対象は、対象システムの内部構成を把握する運用担当者を交えて決定するものとする。
３.３ 脆弱性診断の実施要件
それぞれの診断の実施要件を以下に述べる。要件には、全ての診断に共通する
ものと、診断の種別ごとに異なるものがある。実際に要件を策定する際は、これらの要件を組み合わせるものとする。

9

ネ

一般公

情報を収集及び分析 、

18

セ

ュ

ィ上

目

役立

こ

1)全ての脆弱性診断に共通する要件
全ての診断に共通する要件は、診断の品質に関わる実務要件、診断を円滑に進めるための管理要件、そして診断の成果物に関する要件に大別される。特記すべき点として、実務者のスキルに関する要件（以下(5)）は必須ではなく推奨に留めている。これは、国内では高度な専門性を有する人材が限られており調達が困難であるという現状に鑑みたものである。しかしながら、脆弱性診断の品質は実務者の知見や経験に大きく左右されるため、リスクの高いシステム等においては、(5)を必須とすることが望ましい。
脆弱性診断では検出した脆弱性等の機微な情報を扱うことから、以下の要件に加え、各機関の定める情報管理や秘密保持等に関する要件を併せて求める必要がある。
(1) 経済産業省の「情報セキュリティサービスに関する審査登録機関基準 10」における「脆弱性診断サービス」の認定を取得したセキュリティベンダー
であること（必須）(2) 上記(1)の認定基準における「技術要件」と「品質管理要件」を満たす人員
が 1 名以上診断に参画すること（必須）(3) 作業従事者のうち少なくとも１名は、当該の種別の診断において 2 年以上の経験を有すること（必須）(4) 業務に関連する外部ステークホルダーとのコミュニケーションや調整業
務について、2 年以上の実務経験を有する者が診断に参画すること（必須）(5) 以下を満たす者が１名以上診断に参画すること。条件を満たさない場合は、経験を満たすことと同等以上の技術を保持していることを政府機関の職員が判断できる理由が具体的に提示されること（推奨）(5-1) OSCP11、OSWA12、GWAPT13、GPEN14、GMOB15またはその上位資格の保有(5-2) CTF 等のセキュリティコンテストにおける上位入賞実績(5-3) CVE の報告実績(6) ツールを用いる場合は、診断対象の見落とし、診断のエラーや誤検出が含まれないように手動で精査すること（必須）10https://www.meti.go.jp/policy/netsecurity/shinsatouroku/zyouhoukizyun2.pdf

11https://www.offensive-security.com/pwk-oscp/

12

https://www.offensive-security.com/we 200-oswa/

13

https://www.giac.org/certifications/we -application-penetration-tester-gwapt/

14

https://www.giac.org/certifications/penetration-tester-gpen/15

https://www.giac.org/certifications/mo ile-device-security-analyst-gmo /19

(7) 要請に応じて、休日夜間における診断業務が実施可能であること（任意）(8) 要請に応じて、使用するネットワーク通信帯域を制限可能であること（任意）(9) 診断の実施前に実施計画書を提出すること。実施計画書には以下を含むものとする（必須）(9-1) 診断の実施方針及び実施内容(9-2) スケジュール(9-3) 実施体制
(9-4) 情報セキュリティ管理体制(9-5) 実施上の留意事項や準備事項(10) 診断の実施前に、対象システムの責任者及び担当者に対して説明会を実施すること。説明会の内容は上記(9)で作成した実施計画書に準ずるものとし、診断を円滑に進められるよう、双方の役割やコミュニケーション体
制を確認するものとする（推奨）(11) 診断結果の報告書には、以下の項目を記載すること。フォーマットは機関からの指定の無い限り、PDF（Portable Document Format）形式で作成するものとする。これ以外の形式を使用する場合は、事前に機関へ相談すること（必須）(11-1) 検出された脆弱性の概要(11-2) 検出された脆弱性の深刻度(11-3) 検出された脆弱性による影響(11-4) 検出された脆弱性の対策方法(11-5) 脆弱性を検出した全てのパラメータ(11-6) 脆弱性を検出した際の入力文字列(12) 上記(11-2)は、実際の攻撃可能性に基づき、深刻度を評価すること。評価方法は CVSS v3.1 基本評価基準に基づく 5 段階評価（None, Low, Medium,
High, Critical）とし、その算定方法も明記すること（推奨）(13) 上記(11-3)は、その脆弱性が悪用できることを可能な範囲で実証し、対象システムにおける現実的な攻撃の発生可能性や想定される脅威のシナリオに基づき記述すること。また、可能なものについては、実証した攻撃のスクリーンショット等の証跡を含めること（必須）(14) 上記(11-1)(11-3)(11-4)は政府職員が読解可能な平易な文章で記述されていること。目安として、サイバーセキュリティに 1 年程度従事した職員が読解可能であるものとする（推奨）(15) 診断結果の報告会を実施すること。報告会には診断の作業従事者が同席し、質疑に応じられるようにすること（推奨）20(16) 検出された脆弱性の改修後、改修した脆弱性に対する再診断を行うこと。
再診断は報告書の納品から最低 1 カ月以内の期間、1 回以上の実施ができるようにすること（必須）ア 総合評価の実施
上記の要件は、履行証明書等の提出を通じて入札の参加資格の確認時に利用することを想定するが、総合評価落札方式での調達が可能である場合は、上記の要件を満たすことに加えて、最高情報セキュリティアドバイザー等の有識者を交えた加点評価を行うことが望ましい。この際の主な評価観点を以下に示す。
・診断に採用する手法やツールについて、診断の品質を高めるための優れた工夫がなされているか
・報告書は具体的かつ政府職員が読解可能な平易な文章で記述されているか・高度な知識や経験を有する人員による体制が組まれているか
2)プラットフォーム診断に関する要件
プラットフォーム診断に固有の要件を以下に示す。
(1) 表 ２-１に示す全ての脆弱性種別（以下、(1-1)〜(1-4)）を診断対象とすること（必須）(1-1) 不要ポートの開放(1-2) 脆弱なソフトウェアの利用(1-3) 設定の不備(1-4) プロトコル固有の脆弱性(2) 上記(1-1)では、TCP、UDP に対してオープンポートの確認と稼働しているサービスの推定を行うこと。TCP の確認は 1〜65535 番ポートの全てを対象とすること。UDP の確認には多くの時間を要することから、利用するツールが確認を推奨するポート（一般的に利用頻度の高いポート）の上位 100
位相当を確認対象に含めること（必須）(3) 上記(1-2)(1-3)(1-4)に関する診断は、表 ４-１に示す脆弱性種別を全て網羅すること（必須）(4) ツールによる診断には、最新の攻撃手法を反映した実績ある商用ツールを活用すること。フリーツールや自社製ツールのみによる診断は行わないこ
と（必須）

21

3)Web アプリ診断に関する要件
Web アプリ診断に固有の要件を以下に示す。Web アプリの脆弱性には人手でなければ検出の難しいものが多数存在し、また、その検出能力は実務者の知識や経験に大きく左右される。このため、攻撃されることによる社会的影響の大きいシステムや、実装に注意を要する機能（ファイルアップロード、ID 連携、マイナ
ンバーカードによる署名や認証等）を有するシステムは、上述の共通要件(5)に該当する熟練者による手動の診断を必須とすべきである。
(1) 表 ２-２に示す全ての脆弱性種別（以下、(1-1)〜(1-5)）を診断対象とすること（必須）(1-1) 固有のビジネスロジックに依存するもの(1-2) 一般的な仕様上の不具合(1-3) 実装のメカニズムに対する高度な理解が要求されるもの(1-4) 一般的な実装の不備(1-5) 利用する Web アプリミドルウェア固有の脆弱性(2) 上記(1-1)〜(1-3)の診断は全て人手で行うこと。ツールの誤検出の除去ではなく、診断そのものを人手で行うものとする（必須）(3) 上記(1-2)(1-4)の診断は以下の基準に準ずること。具体的には、表 ４-２に示す脆弱性種別を診断対象として網羅すること。他の基準を用いる場合
は、表 ４-２に対する充足性を説明すること（必須）(3-1) NISC「政府機関等の対策基準策定のためのガイドライン（令和３
年度版）16」(3-2) IPA「安全なウェブサイトの作り方 改訂第 7 版17」(3-3) 脆弱性診断士スキルマッププロジェクト「Web アプリケーション脆弱性診断ガイドライン 第 1.2 版18」
(4) 上記(1-1)〜(1-4)の診断は、(3)の基準に加え、熟練者の経験に基づく手動の診断を行うこと（推奨）(5) 上記(1-4)(1-5)においてツールを用いる場合は、サイトを手動巡回すること（必須）(6) 機能の確認に十分な権限を有するアカウントを用いて診断を行うこと（必須）

16

https://www.nisc.go.jp/pdf/policy/general/guider3.pdf

17https://www.ipa.go.jp/security/vuln/we security.html

18

https://githu .com/ e

pp entestGuidelines/ e

pp entestGuidelines

224)スマートフォンアプリ診断に関する要件
スマートフォンアプリ診断に固有の要件を以下に示す。
(1) 表 ２-３に示す全ての脆弱性発生部位（以下、(1-1)〜(1-3)）を診断対象とすること（必須）(1-1) アプリ本体(1-2) 通信路
(1-3) 外部サービス(2) 上記(1-1)(1-3)の診断には、対象アプリのソースコードレビューまたはリ
バースエンジニアリングを用いること（必須）(3) 上記(1-1)(1-2)の診断は OWASP の「Mobile Security Testing Guide(MSTG)19」における L1 の実施項目（MASVS-L1 相当）を網羅するものとする。その他の基準を用いる場合は、MSTG の L1 の診断項目に対する充足性を説明すること（必須）３.４ 検出された脆弱性の対応方針
検出された脆弱性は、各機関の対応基準に従い、改修や防御策の適用を行うものとする。構築時診断ではシステムの納品前に、定期診断ではシステムの運用保守において適切に対応が行われるように契約内容等を定める必要がある。この際の対応基準は脆弱性の深刻度に基づいて策定されることが望ましい。また、既に当該の脆弱性を悪用する攻撃が国内外で観測されている場合には、対応基準に関わらず、迅速な対応を行うものとする。

19

https://githu .com//owasp-mstg

23

４付録
付録A. 各種診断で検出対象とする脆弱性種別
各種診断において検出対象とすることを求める脆弱性の種別を下表に示す。
各表の出典列は、付録 B の文献番号に対応している。
1)プラットフォーム診断
表 ４-１
No.

プラットフォーム診断で対象とする脆弱性種別
脆弱性種別

備考

出典

1

脆弱なソフトウェアの利用

既知脆弱性の有無を確 (7)(8)(9)認2

不要なポート、サービス、アカ
ウントの存在3

公開ディレクトリ、ストレー 公開不要なファイルの (8)(9)
ジへの非公開情報の保存
存在等を確認4

DNS の設定不備(7)(8)

オープンリゾルバ、ゾ (7)ーン転送の設定不備等を確認

5

暗号化されていない、または脆弱な暗号による通信(8)6

サーバ証明書の不備(7)

7

サーバソフトウェアの設定不 初 期 パ ス ワ ー ド の 利 (9)備用、ディレクトリリス
ティング等を確認

2)Web アプリ診断
表 ４-２
No.

Web アプリ診断で対象とする脆弱性種別

脆弱性種別

備考

出典

1

SQL インジェクション

(7)(8)(9)2

OS コマンドインジェクション

(7)(8)(9)3

クロスサイトスクリプティン HTML イ ン ジ ェ ク シ ョ (7)(8)(9)グ（XSS）
ン、CSS インジェクショ
ン、DOM based XSS 等を
含む

24

No.

脆弱性種別

備考

出典

4

メールヘッダインジェクショ
ン(7)(8)

5

HTTP ヘッダインジェクション
（CRLF インジェクション）(7)(8)(9)6eval インジェクション

(7)

7

その他のインジェクション

サーバサイドテンプレ (9)ートインジェクション（SSTI）、相対パスによる 上 書 き （ Relative
Path Overwrite）等を含む

8デ ィ レ ク ト リ ト ラ バ ー サ ル ローカルファイルイン (7)(8)(9)（パストラバーサル）
クルージョン（LFI）を含む

9

セッション管理の不備

推 測 可 能 な セ ッ シ ョ (7)(8)(9)ン、セッションの盗用、セッションの固定化（セッションフィクセーション）、Cookie の管理不備等を含む

10

アクセス制御（認証制御）と認 認証回避、ログアウト (7)(8)(9)
可処理の不備機能の不備、脆弱なパ
スワードポリシー、パスワードリセットの不備、復元可能なパスワ
ード保存等を含む

11

クロスサイトリクエストフォージェリ（CSRF）(7)(8)(9)12クリックジャッキング

(7)(8)(9)13

レースコンディション

(7)

14

バッファオーバーフロー

15

ファイルアップロードに関す 圧縮ファイルの取り扱 (9)る不備
い（ZIP Bombs 等）を含
む

整数オーバーフローを (7)(8)
含む

25

No.

脆弱性種別

備考

出典

16

セキュリティの設定ミス

(9)

17

オープンリダイレクト

(9)

18

安全でないデシリアライゼー
ション

(9)

19

サーバサイドリクエストフォージェリ（SSRF）

(9)

20

クロスサイトウェブソケット(9)

ハイジャッキング（CSWSH）
21

XML 外 部 エ ン テ ィ テ ィ 参 照
（XXE）

(9)

22

その他の情報漏えいにつなが エラーメッセージやキ (9)る脆弱性
ャッシュからの情報漏
えい等を含む3)スマートフォンアプリ診断
スマートフォンアプリ診断で対象とする脆弱性は、OWASP の「Mobile Security
Testing Guide (MSTG)20」における L1 の実施項目を網羅するものとする。具体
的には、「OWASP Mobile App Security Checklists v1.4.021」における L1 の診断項目を網羅するものとする。
付録B. 参考資料(1) U.S. General Services Administration - IT Security Procedural
Guide: Conducting Penetration Test Exercises CIO-IT Security-11-51
https://www.gsa.gov/cdnstatic/Conducting_Penetration_Test_Exercis
es_[CIO_IT_Security_11-51_Rev_5]_07-24-2020docx.pdf(2) U.S. General Services Administration - IT Security Procedural
Guide: Vulnerability Management Process CIO-IT Security-17-80
https://www.gsa.gov/cdnstatic/Vulnerability_Management_Process_%5
BCIO-IT_17-80_Rev_1%5D_08-21-2019.pdf(3) National Institute of Standards and Technology - SP 800-115
Technical Guide to Information Security Testing and Assessment
https://csrc.nist.gov/publications/detail/sp/800-115/final

20

https://githu .com//owasp-mstg

21

https://githu .com//owasp-mstg/releases/tag/v1.4.0

26

(4) Carnegie Mellon University - Prioritizing Vulnerability Response:
A Stakeholder-Specific Vulnerability Categorization (Version 2.0)
https://resources.sei.cmu.edu/library/assetview.cfm?assetid=653459(5) 金融情報システムセンター（FISC） - 金融機関等における TLPT 実施にあたっての手引書https://www.fisc.or.jp/publication/book/004197.php(6) 経済産業省 - 我が国産業の情報セキュリティ向上に向けた情報セキュリ
ティサービスの高度化方策に関する調査報告書
https://www.meti.go.jp/policy/netsecurity/shinsatouroku/report_20
18fy.pdf(7) NISC - 政府機関等の対策基準策定のためのガイドライン（令和３年度版）
https://www.nisc.go.jp/pdf/policy/general/guider3.pdf(8) IPA - 安全なウェブサイトの作り方 改訂第 7 版
https://www.ipa.go.jp/security/vuln/websecurity.html(9) 脆弱性診断士スキルマッププロジェクト - Web アプリケーション脆弱性診断ガイドライン 第 1.2 版
https://github.com/WebAppPentestGuidelines/WebAppPentestGuidelines(10) OWASP - Mobile Application Security Verification Standard (MASVS)
https://github.com/OWASP/owasp-masvs(11) OWASP - Mobile Security Testing Guide (MSTG)
https://github.com/OWASP/owasp-mstg

27