最終更新日：2026年5月19日
sg sg-security-overview threat_vulnerability sg-security-measures unauthorized_access
まず結論
- セキュリティテストとは、システムやアプリケーションに脆弱性や設定不備がないかを確認する活動です。
- SG試験では、個々の手法名を丸暗記するより、「何を対象に、どのタイミングで、何を確認するのか」で切り分けることが重要です。
直感的な説明
セキュリティテストは、ソフトウェアやシステムの安全点検です。
ただし、安全点検といっても、確認方法はいろいろあります。
たとえば、建物の安全確認にたとえると、次のように分けられます。
- 設計図を見て危ない作りがないか確認する
- 完成した建物に入って動きを確認する
- ドアや窓から侵入できないか試す
- いろいろな異常操作をして壊れないか確認する
- 点検表に沿って弱点を洗い出す
ソフトウェアでも同じです。
セキュリティテストには、ソースコードを見るもの、実行中のアプリを外から見るもの、攻撃者視点で確認するものなどがあります。
SG試験では、名前よりも、検査の目的と方法を見て判断します。
定義・仕組み
セキュリティテストは、システムやアプリケーションに脆弱性、設定不備、設計上の問題、運用上の弱点がないかを確認する活動です。
代表的な種類を整理すると、次のようになります。
| 種類 | 何をするか | 判断ポイント |
|---|---|---|
| ソースコードレビュー | 人がコードを読み、安全性や保守性を確認する | 人が確認する |
| SAST | ソースコードを実行せず、ツールで危険な実装を検出する | 静的・コード・ツール |
| DAST | 実行中のアプリを外部から検査する | 動的・外部アクセス・応答確認 |
| ファジング | 問題を起こしそうなデータを大量に入力する | 入力データ・異常動作 |
| 脆弱性診断 | 既知の脆弱性や設定不備を広く洗い出す | 一覧化・危険度・修正案 |
| ペネトレーションテスト | 攻撃者視点で侵入や被害拡大を検証する | 攻撃シナリオ・侵入可能性 |
IPAでは、Webアプリケーションの脆弱性対策や安全な実装に関する資料が公開されています。セキュリティテストの前提となる脆弱性対策を確認する場合は、IPAの安全なウェブサイトの作り方やセキュア・プログラミング講座が参考になります。
大切なのは、これらの手法は競合するものではなく、目的に応じて組み合わせるものだという点です。
たとえば、開発中はSASTやソースコードレビューで早めに問題を見つけ、リリース前にはDASTや脆弱性診断で実行時の問題を確認します。
重要システムでは、さらにペネトレーションテストで攻撃シナリオとして成立するかを確認することもあります。
どんな場面で使う？
セキュリティテストは、開発中、リリース前、運用中など、さまざまな場面で使われます。
開発中に使うもの
開発中は、問題を早く見つけて修正することが重要です。
この段階では、次のような手法が向いています。
- ソースコードレビュー
- SAST
- セキュアコーディングの確認
開発中に見つけた問題は、リリース直前に見つけるより修正しやすいです。
テスト・リリース前に使うもの
アプリケーションが動く状態になったら、実際の挙動を確認します。
この段階では、次のような手法が向いています。
- DAST
- ファジング
- 脆弱性診断
実行中のアプリケーションに外部からアクセスし、入力に対する応答やエラー処理を確認します。
重要システムで使うもの
重要情報を扱うシステムや、攻撃されたときの影響が大きいシステムでは、より実践的な確認が必要です。
この場合は、ペネトレーションテストが使われることがあります。
ペネトレーションテストでは、攻撃者視点で侵入経路や権限昇格の可能性を確認します。
ただし、攻撃に近い操作を行うため、実施範囲や手順を事前に合意して行うことが重要です。
よくある誤解・混同
セキュリティテストでは、名前が似ている手法が多いため、SG試験でも混同しやすいです。
| 迷いやすい組合せ | 切り分けポイント |
|---|---|
| SAST と DAST | 実行しないならSAST、実行中のアプリを見るならDAST |
| ソースコードレビュー と SAST | 人が読むならレビュー、ツールで解析するならSAST |
| DAST と ファジング | 外部から応答を見るのがDAST、大量の入力で異常動作を見るのがファジング |
| 脆弱性診断 と ペネトレーションテスト | 広く洗い出すなら診断、攻撃成立性を見るならペネトレーションテスト |
| セキュアコーディング と セキュリティテスト | 作る段階で防ぐのがセキュアコーディング、作ったものを確認するのがテスト |
SG試験では、次の表現に注意します。
-
「ソースコードを実行せずに解析する」
→ SASTを疑います。 -
「実行中のWebアプリケーションに外部からアクセスする」
→ DASTを疑います。 -
「問題を起こしそうなデータを大量に入力する」
→ ファジングです。 -
「既知の脆弱性や設定不備を広く洗い出す」
→ 脆弱性診断です。 -
「攻撃者の視点で侵入できるか確認する」
→ ペネトレーションテストです。
よくあるひっかけは、全部をまとめて“脆弱性を調べるもの”として覚えてしまうことです。
たしかに大きく見ると、どれも弱点を見つける活動です。
しかし、SG試験では、次の3点で切り分けると選択肢を判断しやすくなります。
- 実行するか、実行しないか
- 人が見るか、ツールで見るか
- 弱点を洗い出すか、攻撃として成立するかを見るか
判断軸の再確認（試験直前）
- 目的を基準に切る：何を防ぐ／何を見つけるための手法か。
- 実施タイミングを切る：開発中に行うか、稼働中の環境で行うか。
- 言い過ぎ表現に注意：「完全に防げる」「これだけで十分」は誤りになりやすい。
まとめ（試験直前用）
- 「ソースコードを実行せずに欠陥を探す」 → SAST（作り込み段階の欠陥検出）。
- 「動作中のWebアプリに外部から入力して挙動を見る」 → DAST（実行環境での挙動確認）。
- 「大量・異常な入力でクラッシュや例外を探す」 → ファジング（入力耐性の確認）。
- 「弱点の洗い出し」は脆弱性診断、 「侵入できるかの実証」はペネトレーションテスト。
- 迷ったら、開発中に欠陥を減らす活動か／運用環境で攻撃成立を確かめる活動かで切る。
確認問題
セキュリティテストの種類と説明の組合せとして、最も適切なものはどれか。
ア. SASTは、実行中のWebアプリケーションに外部からアクセスし、応答や挙動を確認する手法である。
イ. DASTは、ソースコードを実行せずに解析し、危険な実装を検出する手法である。
ウ. 脆弱性診断は、既知の脆弱性や設定不備を広く洗い出し、危険度や修正案を整理する活動である。
エ. ペネトレーションテストは、端末のセキュリティ状態を確認し、社内ネットワークへの接続可否を判定する仕組みである。