脆弱性診断の基準とは、対象システムのリスクに基づき、診断の要否や手法、頻度を定めたルールのことです。基準が曖昧なままだと、重大な脆弱性を見逃すリスクや、都度判断による無駄な工数がかかるリスクもあります。
脆弱性診断の基準は、システムの「公開範囲」と「扱う情報の機密性」で決まります。すべてのシステムに最高レベルの対策を求めるのではなく、特性に応じてツールと手動診断を使い分けることが重要です。
本記事では、システム別の判断基準や公的ガイドラインが求める要件を解説します。自社サイトの脆弱性診断における基準策定に、ぜひお役立てください。
脆弱性診断の基準とは、対象システムのリスクに応じて「どこまで詳細に、どのくらいの頻度で検査を行うか」を定めたルールのことです。すべてのシステムに一律の検査を行うのではなく、過不足のないセキュリティ対策を実行するための指標となります。
具体的に基準を構成する要素は、主に以下の4つ。
・診断の要否と対象範囲
システム全体を網羅的に検査するのか、特定の機能（ログイン画面や決済機能など）に絞るのか、あるいは要件的に今回は診断不要とするかを決定します。
また、インターネットに公開されているか、社内限定かといった露出度によって、診断の優先順位を定義します。
・診断の手法
専用のソフトウェアによる「ツール（自動）診断」で済ませるか、専門エンジニアが疑似攻撃を行う「手動診断」まで必要かを定めます。
高リスクなシステムの場合は、両方の併用が推奨です。
・実施のタイミングと頻度
新規リリース前、システム改修時、または年1回といった定期的なサイクルなど、どのタイミングで検査を実施するかを規定します。
これらの要素を組み合わせ、システムごとに最適な検査要件を定義したものが脆弱性診断の基準となります。
・判定と改修の基準（CVSSなど）
発見された脆弱性の危険度をどう評価し、どのレベル（例：重要度「中」以上）までを期限内に改修すべきかという「合格基準」を定めます。
※CVSS：共通脆弱性評価システム。脆弱性の深刻度を0〜10の数値で評価する指標。
診断後の「見つかった脆弱性をどう評価し、どのレベルまで改修すべきか」という判断基準も、運用ルールとしては重要です。
脆弱性診断の基準を社内で明確にしておくべき最大の理由は、システムが抱えるリスクに対して過不足のないセキュリティ対策を安定して実行するためです。
基準が曖昧なままだと、担当者によって対策のレベルにばらつきが生じ、重大な脆弱性を見逃したり、逆に無駄なコストや工数をかけてしまったりする恐れがあります。
都度の判断による迷いをなくし、安全かつ効率的な運用体制を築くために、具体的には以下の3つの観点からルールを策定することが求められます。
・重大なインシデントの防止
担当者の裁量によってセキュリティレベルにばらつきが生じると、診断の実施有無や対象範囲がその都度揺らいでしまうでしょう。その結果、本来防げるはずのサイバー攻撃による情報漏えいやサービス停止といった、企業経営を揺るがす重大な事故を引き起こす要因となってしまうリスクもあります。
・セキュリティ投資の最適化
リスクを恐れるあまり、すべてのシステムに対して一律で最高レベルの診断を実施するのは、予算と期間の観点からも非常に非効率です。リスクの低い社内向けの非公開システムに高額な手動診断をかけるのではなく、守るべき情報資産の重要度に応じて診断レベルを調整し、最適化を図りましょう。
・開発スピードの維持
あらかじめ統一されたルールを設けておくことで、新規プロジェクトの立ち上げ時や既存システムの大規模アップデート時に、迷うことなく必要なセキュリティ要件を定義できます。開発部門とセキュリティ部門の合意形成がスムーズになり、手戻りを防げるため、短いサイクルでリリースを繰り返すDevSecOpsやアジャイル開発のスピードを落とさずにすみます。
全システムに一律の診断を義務付けるのではなく、システムが扱う情報や利用範囲に応じて基準を定めておくことが、コストの無駄や開発の遅延を防ぎ、安全なシステムを継続して運用するためには重要となります。
脆弱性診断の要否や対象範囲は、「インターネットへの公開範囲」と「扱うデータの機密性」の2つの軸を基準に判断することが大切です。
社内にあるすべてのシステムに対して一律の診断を実施するのは、コストと時間の観点から非効率。そのため、守るべき情報資産の価値と、想定される脅威のレベルに応じたメリハリのある対策が求められるのです。
具体的には、対象システムを以下の3つのパターンに分類し、それぞれに最適な診断レベルの目安を設定することをおすすめします。
それぞれの特性に合わせた具体的な判断基準を解説します。
ECサイトやSaaS型アプリケーションなど、誰でもアクセス可能な一般公開システムには、ツール診断と手動診断を組み合わせた「網羅的なチェック」が必須です。インターネット上に公開されているこれらのシステムは、常に世界中の攻撃者や脆弱性スキャナーによる探索に晒されているため、最もリスクが高いと判断します。
顧客のクレジットカード情報や個人情報、企業の機密データなどを取り扱うことが多いため、万が一脆弱性を突かれた場合の被害規模は計り知れません。ツールによる自動スキャンで既知の脆弱性を素早く発見するだけでなく、ツールでは検知できない「ユーザー権限に応じたアクセス制御の欠陥」や「複雑な決済処理のバグ」を見つけ出すために、専門エンジニアによる精度の高い手動診断が欠かせません。
新規リリース前はもちろんのこと、大規模な機能追加や改修を行うメジャーアップデートの際にも、都度厳密な診断を実施することが求められます。
BtoBの受発注システムや会員向けポータルサイトといった限定公開システムでは、ツール診断を中心としつつ、扱う情報の重要度に応じて部分的に手動診断を取り入れるのが適切といえます。
特定のIPアドレスや事前に登録されたユーザーしかアクセスできないため、一般公開システムに比べると攻撃の入り口は限定されますが、ひとたび認証情報を突破された場合の被害は甚大です。
基本的には、定期的なツール診断によってシステム全体のセキュリティレベルを効率よく担保し、コストを抑えるアプローチが有効です。しかし、取引先の財務情報や未公開の設計データなど、漏えい時の影響が大きい機密情報を含む場合は注意が必要です。
パスワードの総当たり攻撃やセッションハイジャックのリスクを防ぐため、ログインやパスワードリセットなどの「認証周り」に限定して手動診断を組み込むなど、メリハリを効かせた柔軟な対応が求められます。
社内のイントラネットからのみアクセス可能な勤怠システムや、公開サービスの裏側にある管理画面などは、定期的な「ツール診断」を中心とした対策が基本となります。
外部のインターネットから直接アクセスすることができないため、サイバー攻撃を受ける確率が他のパターンと比較して低いためです。
これらの社内限定システムに対しては、開発工程や日々の運用の中で自動化ツールを利用し、OSやミドルウェアの既知の脆弱性を潰しておく運用が一般的で、高額な手動診断を毎回実施する必要はありません。
ただし、マルウェアに感染した従業員の端末を踏み台にした内部攻撃のリスクがあるため、まったく対策をしないのは危険です。また、一般公開システムのコンテンツを直接書き換えられる「特権IDを扱う管理画面」など、権限昇格による影響が大きい特定の箇所については、例外として専門家による注意深いチェックを検討する必要があります。
自社の脆弱性診断基準を策定する際は、デジタル庁やIPA（情報処理推進機構）などの公的機関や、国際的なセキュリティ組織が発行するガイドラインをベースにするのが確実といえます。
なぜなら、ゼロから独自の基準を作るのは難易度が高く、対策に抜け漏れが発生しやすいうえ、客観的な妥当性を社内外に説明しにくいためです。
取引先から適切なセキュリティ対策が施されているかと問われた際にも、公的ガイドラインに準拠していれば、明確な根拠を持って安全性を証明できます。
ここでは、実務でよく参照される代表的なガイドラインが定める「実施頻度」と「必須の診断項目」の考え方を紹介します。
デジタル庁の脆弱性診断導入ガイドライン※1やIPAの脆弱性対策関連ガイドライン※2は、脆弱性診断はシステムの新規稼働前だけでなく、稼働後も「システムの変更時」や「定期的なサイクル」で継続的に実施することが推奨されています。
サイバー攻撃の手口は日々巧妙化しており、稼働開始時には安全だったシステムであっても、時間の経過とともに新たな脆弱性が発見されるリスクが常にあるためです。
具体的には、以下の3つのタイミングでの実施が基準となります。
・システムの新規稼働前
インターネットに公開する前や本番環境への移行前に、網羅的な診断を行って潜在的なリスクを排除します。
・大きな機能追加や改修時
OSやミドルウェアのバージョンアップ、アプリケーションの大規模な仕様変更が行われた際は、その変更箇所が新たなセキュリティホールを生んでいないかを確認するために再診断が必要です。
・定期的なサイクル（年1回など）
システムに変更を加えていない期間であっても、日々新しい攻撃手法が生み出されています。扱う情報の機密性に応じて、年1回から半年に1回程度の定期診断を運用計画に組み込むことが求められます。
このように、一度診断して終わりにするのではなく、システムのライフサイクル全体を通して継続的にリスクを監視し、対処する体制の構築が重要です。
※1 デジタル庁｜政府情報システムにおける脆弱性診断導入ガイドライン（参照 2026-04-07）Webアプリケーションの診断において、検査項目が十分に網羅されているかどうかの最低限のボーダーラインとなるのが、国際的なデファクトスタンダードである「OWASP Top 10」への準拠です。
OWASP（Open Worldwide Application Security Project）※が発表するこのリストには、世界中で実際に悪用され、深刻な被害をもたらしている「最も危険なWebアプリケーションの脆弱性トップ10」がまとめられているためです。
自社で診断ツールを導入する場合も、外部のセキュリティベンダーに委託する場合も、以下の10項目が検査対象に含まれているかを必ず確認してください。
| 順位 | 脆弱性項目 | 概要・リスク |
|---|---|---|
| A01 | アクセス制御の不備 | ユーザーに許可されていないデータや機能へのアクセスを許してしまう権限管理の欠陥。権限昇格、他ユーザーのレコードの閲覧・改ざん、CORS設定の不備などが含まれる。 |
| A02 | セキュリティ設定の不備 | クラウドやサーバーの初期設定ミス、不要な機能の有効化、不適切なデフォルト値など、システム管理上の不備を突かれるリスク。 |
| A03 | ソフトウェアサプライチェーンの不備 | 開発で使用する外部ライブラリやフレームワークの脆弱性に加え、ビルドシステム・配信インフラ（CI/CD等）の侵害、悪意あるパッケージの混入など、ソフトウェアの構築・配布プロセス全体にわたるリスク。 |
| A04 | 暗号化の失敗 | 通信や保存データの保護不足。脆弱なアルゴリズムの使用や証明書管理の不備により、重要情報が第三者に露呈する状態。 |
| A05 | インジェクション | SQL、OSコマンド、LDAP等の命令注入や、クロスサイトスクリプティング（XSS）により、システムを意図しない形で操作されたり、情報を抜き取られたりする攻撃。 |
| A06 | 不安全な設計 | 開発の設計段階で悪用シナリオを想定した対策（脅威モデリング等）が組み込まれていないために発生する、システムの構造的・論理的な欠陥。 |
| A07 | 認証の失敗 | 多要素認証（MFA）の欠如やセッション管理の不備により、第三者による「なりすましログイン」やアカウント乗っ取りを許すリスク。 |
| A08 | ソフトウェアとデータの整合性の欠陥 | アップデートファイルの署名検証不足や、信頼できないデータの読み込みによる、不正なプログラムの実行やデータの改ざんリスク。 |
| A09 | セキュリティログとアラートの不備 | 攻撃の兆候を正しく記録できない、あるいは異常を即座に検知・通知できないため、事案発生時の初動対応が遅れるリスク。 |
| A10 | 例外条件の不適切な取り扱い | 異常な状況の発生を防止・検知・対処できず、システムのクラッシュや予期せぬ動作、セキュリティ保護の解除（フェイルオープン）を引き起こす不適切なエラー処理。論理エラーやリソース枯渇、エラーメッセージによる内部情報の露出なども含まれる。 |
OWASP Top 10の項目をカバーしているかをシステムの維持管理を依頼する企業選定の評価基準にすることで、致命的な見落としを防ぎ、実効性の高い対策を実施することができます。
※ Open Worldwide Application Security Project｜OWASP Top 10:2025脆弱性診断にかかるコストと精度のバランスを取るためには、ツール診断と手動診断の特徴を理解し、対象システムや開発フェーズに合わせて両者を使い分けるのがポイントです。すべてのシステムに対して高精度な手動診断を実施するのは、予算やスケジュールの観点から現実的ではないでしょう。
それぞれのメリットを把握し、日常的なチェックはツールで効率化し、リリース前などの重要なタイミングでは手動で確実に穴を塞ぐといった適材適所の基準を設けることが、セキュリティ対策の投資対効果を高める鍵となります。
ツール診断の最大のメリットは、検査スピードが速く、安価に実施できることです。
専用のソフトウェアは、あらかじめ設定された攻撃パターンに基づいて自動でスキャンを行うため、広範囲のシステムを短時間かつ低コストで検査可能です。
そのため、日々の開発プロセスに組み込む「日常の健康診断」として活用するのに向いています。
具体的には、OSやミドルウェアのパッチ未適用といった既知の脆弱性チェックや、単純な設定ミスの発見に威力を発揮します。アジャイル開発などにおいては、日々のCI/CDパイプラインにツール診断を組み込み、定期スキャンを実行することで、基本的な脆弱性を早期に発見・修正する運用が適しています。
自社で脆弱性ツール診断を導入・内製化し、日々のセキュリティレベルを維持・向上させる手段として、ユービーセキュアでも、Webアプリケーション脆弱性検査ツール「Vex」を提供しています。
国内シェアNo.1※の実績を持つVexは、IPA推奨の必須項目を網羅し、専門技術者も利用する高度なシナリオ作成機能やサポートを完備。現在Vexは、手軽な自動検査を可能にするTeamプランと、専門的なシナリオ診断・APIスキャンに対応するEnterpriseプランとして、お客様のニーズに合わせた機能を提供しています。
※ITR調べ「ITR Market View：サイバー・セキュリティ対策市場2025」Webアプリケーション脆弱性管理市場：ベンダー別売上金額シェア（2023年度実績）手動診断の最大のメリットは、ツールでは検知が難しい「ビジネスロジックの欠陥（権限や仕様の穴）」を高い精度で見つけ出せることです。
専門のセキュリティエンジニアが、実際の攻撃者と同じ視点に立ち、システムの仕様や複雑な画面遷移を読み解きながら検査を行うため、個人情報や決済を扱う重要システムにおける、リリース前の最終チェックに最も適しています。
たとえば、URLのパラメータを書き換えるだけで他人の個人情報が閲覧できてしまうといった仕様の抜け道などは、人間の目による検証でなければ発見が困難です。実施に時間とコストはかかりますが、インシデント発生時の影響が大きい機能に対しては、手動診断による確実な検証を行いましょう。
脆弱性診断を成功させるポイントは、すべてのシステムに最高レベルの対策を求めるのではなく、特性に応じたメリハリのある基準を策定することです。
現状のシステム資産を正しく把握し、客観的な基準に基づく診断計画を立てることで、手戻りや無駄なコストを防ぐことができます。明確なルールのもとでセキュリティ投資を最適化し、開発を止めずに安全なサービスを提供できる盤石な運用体制を築いていきましょう。