こんにちは、アプリケーションサービス部、DevOps担当の兼安です。
今回は、私なりに、日々開発を進めていく中で知っておいた方がいいなと思うセキュリティ用語を集めてみました。
本記事では、Webサイト開発を想定し、関連するセキュリティ用語を中心に解説します。
- 脅威・脆弱性・インシデント
- シフトレフト
- 脅威分析
- リスクアセスメント
- OWASP Top 10
- 安全なウェブサイトの作り方
- ゼロトラスト
- DevSecOps
- 静的コード解析（SAST）、動的解析（DAST）、依存関係チェック（SCA）
- (2025/04/03 追記)Fuzzテスト
- SBOM（Software Bill of Materials）
- 脆弱性データベース
- セキュリティ診断とペネトレーションテスト
- WAF（Web Application Firewall）
- [宣伝]サバソック
脅威・脆弱性・インシデント
脅威・脆弱性・インシデント、この3つの用語は意味が似ているようで異なるものです。
- 脅威（Threat）: 情報資産に損害を与える可能性のある存在や行為
- 脆弱性（Vulnerability）: システムの弱点や設定ミスなど、脅威にさらされる要素
- インシデント（Incident）: 実際に問題が発生した状態
攻撃者による不正アクセスで情報が漏えいしたケースを例にすると、それぞれの用語は以下のようになります。
- 脅威: 攻撃者が不正アクセスを試みる
- 脆弱性: 未適用のセキュリティパッチ
- インシデント: 顧客情報の漏えい
サーバーに未適用のパッチがあり（脆弱性）、攻撃者により不正アクセスを試みられ（脅威）、結果として顧客情報が漏えい（インシデント）という流れです。
シフトレフト
ガントチャート上の左側にあたる工程＝上流工程からセキュリティ対策を始めるという考え方のことを指します。
オンプレミス環境にある情報システムをクラウドに移行する手法である、リフトアンドシフトと微妙に語感が似ていますが全くの別物の概念です。
総合試験などでセキュリティテストを行うだけでは不十分という考え方ですね。
ただし、上流工程からいきなりセキュリティテストを行えるわけではないので、リスクアセスメントや脅威分析などから始めていくことになります。
脅威分析
脅威分析は脅威モデリングとも呼ばれ攻撃者視点で潜在的な脅威と攻撃パターンを特定・評価することを指します。
具体的な手法としては、STRIDE、PASTA、LINDDUNなどのフレームワークを活用することがあります。
個人的にSTRIDEという手法が前面に出ている印象ですが、あくまでSTRIDEは脅威分析の手法の一つであると認識しています。
リスクアセスメント
脅威の影響と発生確率を評価、リスクコストの算出などを行いどこまで許容できるかを分析するプロセスです。
この分析結果をもとに、セキュリティ対策の優先順位を決定します。
脅威分析とは相互補完関係にある概念で、脅威分析の結果をもとにリスクアセスメントを行うとも言えます。
主観ですが、脅威の意味を正しく理解していないと、この時点で困惑すると思います。
改めて、脅威・脆弱性・インシデントの違いを理解しておくと良いでしょう。
OWASP Top 10
Webアプリケーションの代表的な脆弱性トップ10をまとめたリストです。
以前は数年おきに更新されていましたが、最近は毎年更新されています。
SQLインジェクションやセキュリティ設定ミスがよく上位にランクインしています。
基本的に挙がっているものは、仕組みで防げるものばかりです。
OWASP Top 10に挙がっているような項目は、要件として挙がっていなくてもWebの常識として対策しておく必要があるので、プロジェクトの早期で設計に盛り込んでおくのがよいと思います。
安全なウェブサイトの作り方
IPA（情報処理推進機構）が公開しているウェブサイトの開発者向けにセキュリティ対策の手法を解説した資料です。
Web開発に関わるなら必読の資料です。
ゼロトラスト
これは、すべてを「信用できない領域」として全ての通信を検査し認証を行うという考え方です。 建物でいうと、鍵がかかっていても重要書類は机に置きっぱなしにしない、というイメージです。
サーバーで言うと、ポートは開けていないが、セキュリティパッチは必ず適用する。
アプリケーションで言うと、WAFは設けているが、プログラム側はしっかりSQLインジェクション対策をする。
このように、ネットワークの境界を問わず、各々の領域でセキュリティ対策を行っていきます。
これにより、万が一、他の領域のセキュリティ対策が破られた場合でも、被害を最小限に抑えることができます。
個人的に、この考え方自体は昔から存在していたものだと思います。
ベテランエンジニアの暗黙知を、改めて言語化したものだと捉えています。
DevSecOps
開発（Dev）・運用（Ops）を組み合わせた開発プロセス全体にセキュリティ（Sec）への対策を組み込む手法です。
そもそもDevOpsは開発と運用が連携して効率的にシステムを運用・改善するための手法であり、DevSecOpsはその中でセキュリティを組み込んで継続的にセキュリティを意識していくと言う概念なのですが、私の経験上人同士の会話においてはセキュリティチェックをCI/CDパイプラインに組み込み自動化する文脈を指すことが多いです。
要件定義の打ち合わせなどでこの言葉が出てきたら、セキュリティの自動化をしたいという意図の可能性が高いです。
一般的にCI/CDパイプラインに組み込むセキュリティチェックは、静的コード解析（SAST）、動的解析（DAST）、依存関係チェック（SCA）などがあります。
静的コード解析（SAST）、動的解析（DAST）、依存関係チェック（SCA）
これらは自動でセキュリティに関するチェックを行うツールです。
それぞれ、役割が違うので表にまとめてみました。
| 項目 | 静的コード解析（SAST） | 動的解析（DAST） | 依存関係チェック（SCA） |
|---|---|---|---|
| 対象 | ソースコード | 稼働中のアプリケーション | ライブラリ・フレームワーク・依存モジュール |
| 検出できる脆弱性 | コーディングミス | 設定ミス、認証・認可の不備、動作中の脆弱性 | 既知の脆弱性（CVE）、ライセンス違反 |
| 検出方法 | ソースコードの静的解析 | 疑似攻撃を実施 | 使用中のライブラリや依存関係のチェック |
| ツールの例 | CodeQL | OWASP ZAP | Amazon Inspector, Trivy, GitHub Dependabot, OWASP Dependency-Check |
(2025/04/03 追記)Fuzzテスト
Fuzz（ファズ）テストは、プログラムに対して「ランダムで予期しない入力値」を大量に送り込み、不具合や脆弱性が起きるかを調べるテスト手法です。
ファジング（Fuzzing）とも呼ばれ、専用のファジングツールを使って、異常データを自動的に生成・送信することで、予測しづらい問題を発見することができます。
テストケースを手動で設計する従来型のテストに比べて、想定外の入力に対する耐性やセキュリティリスクの検出に効果的です。
ペネトレーションテストがネットワーク中心なのに対し、Fuzzテストはソフトウェアそのものに焦点を当てたテストという違いがあります。
SBOM（Software Bill of Materials）
SBOMとは
SBOMは、使用しているライブラリや依存関係を明確化し、脆弱性管理を行うための国際標準です。
依存関係チェック（SCA）のツール・サービスで出力できます。
SBOMを出力できるツール・サービスのとしては、Amazon Inspector、Trivy、GitHub Dependabotなどがあります。
SBOMは規格が複数存在します。
- SPDX（Software Package Data Exchange）
- CycloneDX
- SWID タグ（Software Identification タグ）
これらの規格の中で一番メジャーなのは、SPDXでメジャーなツールであれば概ねこの形式で出力することができます。
AWSであれば、Amazon InspectorでSBOMの出力が可能です。
SBOMの現状
SBOMは、すでに一部の業界・国ではいつでも提出可能であることが求められています。
日本においては、医療分野で2024年の春に薬事法が改正、医療に関するシステムはSBOMが必要であると追記されています。
(4) JIS T 81001―5―1の箇条8のソフトウェア構成管理プロセスについて
構成管理プロセスは、当該医療機器のソフトウェア部品表(SBOM)を適切に作成することによって確認すること。
SBOMはそれ単体だと使用ライブラリや依存関係を示す表に過ぎません。
SBOMは国際標準であるためツールで読み取ることが可能です。
これを利用して、脆弱性データベースと照合し、使用中のライブラリに脆弱性がないかを確認することで真価を発揮します。
脆弱性データベース
脆弱性データベースとは
脆弱性データベースは、ソフトウェアやシステムの脆弱性情報を体系的に収集・整理し、一般に公開するための情報プラットフォームです。
OSSのツールやライブラリなどの脆弱性と発生するバージョン、対策の状況が記載されています。
記載されている情報には以下のものがあります。
- 脆弱性の詳細情報（脆弱性の内容や影響範囲）
- 影響を受ける製品・バージョン（OSSや商用ソフトウェア）
- 脆弱性の深刻度（CVSSスコアなどで評価）
- 脆弱性識別番号（例：CVE-ID）
- 対策情報（パッチや回避策、アップデート情報）
- 公開日・更新日（脆弱性が発見・公開された日付）
依存性チェック（SCA）ツール・サービスで出力したSBOMは、ツールで脆弱性データベースと突き合わせることができます。
私が知っている限りのツール・サービスとしては、Amazon Inspector、Trivy、GitHub Dependabotなどがあります。
これらのツール・サービスは、SBOMに記載されているライブラリとそのバージョンを脆弱性データベースと照合し、脆弱性があるかどうかを調べることができます。
脆弱性データベースの種類
脆弱性データベースには、以下のような種類があります。
| データベース名 | 概要 | 主な対象範囲 |
|---|---|---|
| NVD（National Vulnerability Database） | アメリカ国立標準技術研究所（NIST）が運営。 CVE情報の詳細版。 | OSS・商用ソフト全般 |
| JVN（Japan Vulnerability Notes） | IPAとJPCERT/CCが運営する日本の脆弱性情報サイト。 | OSS・商用ソフト全般（日本寄り） |
| CVE（Common Vulnerabilities and Exposures） | MITREが管理。 脆弱性を一意に識別するための識別子（CVE-ID）を提供。 | OSS・商用ソフト全般 |
| GitHub Advisory Database | GitHubが提供。 OSSライブラリの脆弱性情報と修正情報を掲載。 | OSSライブラリ・商用ソフト全般 |
この中で日本においてメジャーなのはJVNだと思います。
一方で依存性チェック（SCA）ツール・サービスが見ている脆弱性データベースは、そのツール・サービスによって異なります。
例えばOSSのTrivyは、NVDを使ってSBOMと照合します。
脆弱性データベース同士の関係
ツールによって見ている脆弱性データベースが異なることもあるでしょう。
こうなると、NVDなどは普段聞かないけどそれで突き合わせて大丈夫か？という疑問が出てきます。
これに関しては、脆弱性データベース同士はCVEを中心として連携しているので、どれを見ていたとしても問題ないと言えます。
例えば、GitHub Advisory Databaseに関しては、以下のようにCVEと連携しているという説明の記述があります。
Security vulnerability database inclusive of CVEs and GitHub originated security advisories from the world of open source software.
セキュリティ診断とペネトレーションテスト
セキュリティ診断とは、システムに潜在的な脆弱性を見つけるための診断作業です。
ペネトレーションテストは、侵入テストとも呼ばれ、システムに擬似攻撃を行い、脆弱性を洗い出す作業です。
Webサイトの開発においては、リリース前にペネトレーションテストも含めたセキュリティのチェックをすることをセキュリティ診断と呼ばれるのをよく見られます。
セキュリティ診断のやり方は様々ですが、DAST（動的解析）ツールを使えば自動でチェックすることができます。
DASTは、Webサイトの挙動を確認するため、任意のページにアクセスし、ページを解析して多種多様なリクエストを行ったりして診断します。
その過程で新たなページが見つかれば、更にそのページにアクセスして診断を行うことを膨大な回数で繰り返します。
従って、DASTによるセキュリティ診断をやり切るには、かなりの時間がかかることがあります。
私の経験では数日要したことがあります。
セキュリティ診断は、専門の機関に依頼することも可能です。
機関が使用するツールを知ることはできませんが、経験上こちらも数日から数週間かかることがあります。
自身でDASTを使うにしても、機関に依頼するにしても、セキュリティ診断は余裕を持って計画する必要があると言えます。
なお、セキュリティ診断を行なう場合は、必ずサーバー管理者やクラウドベンダーに実施する旨を連絡し確認を取っておいてください。
不要と言われることもありますが、都度確認した方が安全だと考えます。
WAF（Web Application Firewall）
WAFは、Webサイトの前段に設置し、Webサイトを保護するためのセキュリティツールです。
AWSにおいては、AWS WAFというサービスが提供されています。
AWS WAFはどのような攻撃を防ぐかに応じたルールが用意されており、これらを組み合わせて使用します。
注意点としては、WAFが弾くリクエストが実はWebサイトにとっては必要なリクエストである可能性があることです。
ルールの設定は最小から始めた方がよいでしょう。
また、機能のテストが終わりきっていない状態でWAFを設定すると、原因がWAFにあるのかプログラムにあるのかがわかりにくくなるので、設定のタイミングには注意が必要です。
以上、改めて知っておきたいWebサイト開発に関わるセキュリテイの基礎用語でした。
本記事をきっかけに、よりセキュリティの知識を深めていただければ幸いです。
[宣伝]サバソック
サーバーワークスはセキュリティ運用を24時間365日自動化するサービスを提供しています。
兼安 聡(執筆記事の一覧)
アプリケーションサービス部 DS3課所属
2025 Japan AWS Top Engineers (AI/ML Data Engineer)
2025 Japan AWS All Certifications Engineers
2025 AWS Community Builders
Certified ScrumMaster
PMP
広島在住です。今日も明日も修行中です。
X(旧Twitter)
