こんにちは、エーピーコミュニケーションズ ACS事業部の福井です。
セキュリティって、「大事とは知っているけど、何から始めればいいかわからない」になりがちですよね。
前職でDX推進に関わっていた頃、まさにそれを何度も痛感しました。
今回は、私がOWASP（Open Web Application Security Project）というフレームワークを採用するに至った背景と、OWASPが提供するもの——特に Web アプリ開発者にとって最も身近な OWASP Top 10 の概要を紹介します。
「なぜOWASPなのか」という問いへの私なりの答えとして、読んでいただければ幸いです。
- 前職での体験：セキュリティ無関心の壁
- 求めていたもの：定量・定期・ドキュメント付き
- OWASPと出会った理由
- OWASPを採用した具体的な理由
- OWASP Top 10とは何か
- OWASP Top 10をどう使うか
- IPAとOWASPの使い分け
- OWASPの進化：Webを超えてAI/LLMまで
- まとめ
- お知らせ
- ACS 事業部のご紹介
前職での体験：セキュリティ無関心の壁
前職では、中小企業等のDX推進リーダーとして、複数の顧客と一緒にWebアプリ・業務システムの構築に携わっていました。
多くの顧客にとって、アプリ開発そのものが経験も少ないといった状況でした。
セキュリティ方針について確認すると、返ってくる言葉はだいたいこうでした。
「御社を信頼しているので、特に気にしていません」
あるいはこんなこともありました。
「一般的なものをとりあえず対応していただければいいです」
「一般的なもの」とは何か。どの基準の、どの項目のことを指しているのか——そこを掘り下げると、明確な答えは返ってきません。 悪意があるわけではなく、そもそも「一般的」の定義が共有されていないのです。
WorldWideにサービスを公開することのリスク、脆弱性が突かれたときの影響——そういった概念がそもそも共有されていない状態です。
攻撃される想定がなければ、対策の必要性も伝わりません。
社内も同様でした。
クラウドの有識者が少なく、セキュリティレビューをしても「へー、そんな攻撃あるんですね」程度の温度感。
レビューを依頼しても変わらないなら、自力で基準を持つしかない——そういう判断に至りました。
求めていたもの：定量・定期・ドキュメント付き
探していた条件はシンプルでした。
- 定量的に評価できる（チェックリスト形式で○×がつけられる）
- 定期的に更新されている（古い情報でないこと）
- ドキュメントが整備されている（実装と照らし合わせられる）
- 信頼性ある出典がある（顧客・上位への説明に使える）
IPAの「安全なウェブサイトの作り方」も参照しました。
概念整理や啓発資料としては有用ですが、実際の商談でセキュリティ要件を詰めていく粒度としては粗さが否めませんでした。
OWASPと出会った理由
いろいろ調べているうちに辿り着いたのが OWASP（Open Web Application Security Project） です。
非営利・コミュニティ主導・ベンダーニュートラルという立ち位置が、まず信頼感を与えました。
特定ベンダーの都合で書かれていないドキュメントは、顧客への説明材料としても使いやすい。
実際のアプリケーションと照らし合わせてみると、「ここはOWASP Top 10のA03（インジェクション）に該当する」「ここはA07（認証の失敗）で要対策」という形で、実装レベルまで落とし込んだ議論ができる粒度があることを確認できました。
IPAが「なぜ対策が必要か」の啓発寄りだとすると、OWASPは「何をどう確認するか」の実践寄りだと思っています。
OWASPを採用した具体的な理由
| 観点 | 内容 |
|---|---|
| 国際標準 | 世界中のセキュリティエンジニアが参照・貢献している |
| 継続更新 | Top 10は定期改訂。最新の脅威動向が反映される |
| 実装レベルの粒度 | コードレビュー・設計レビューに直接使えるチェック項目 |
| ベンダーニュートラル | 特定クラウド・フレームワークに依存しない |
| 顧客説明に使える | 第三者機関の基準として提示できる |
| 無料・オープン | ライセンス不要でドキュメント参照・引用が可能 |
OWASP Top 10とは何か
OWASPが公開するプロジェクトの中でも最も広く知られているのが OWASP Top 10 です。
Webアプリケーションにおける主要なセキュリティリスクをランキング形式でまとめたドキュメントで、数年おきに改訂されています。
現行の最新版は 2025年版 です。
前版の2021年版から比べると、A03にソフトウェアサプライチェーンの不具合（サプライチェーン攻撃の増加を受けた新設）、A10に例外的な状況の誤処理（エラー処理の不備を新カテゴリとして追加）という2つの新カテゴリが加わりました。
| # | リスク名 | 概要 |
|---|---|---|
| A01 | アクセス制御の不備 | 権限チェックの欠落。他ユーザーのデータ閲覧・変更が可能になる |
| A02 | セキュリティの設定ミス | デフォルト設定のまま放置、不要な機能の有効化 |
| A03 | ソフトウェアサプライチェーンの不具合 | ライブラリ・依存パッケージ・CI/CDパイプラインを通じた不正コード混入（新設） |
| A04 | 暗号化の失敗 | 機密データの平文保存・弱い暗号アルゴリズムの使用 |
| A05 | インジェクション | SQLインジェクション、OSコマンドインジェクションなど |
| A06 | 安全でない設計 | セキュリティを考慮しない設計・脅威モデリングの不足 |
| A07 | 認証の失敗 | セッション管理の不備、ブルートフォース攻撃への無防備 |
| A08 | ソフトウェアとデータの整合性の失敗 | データやコードの改ざん、不正な更新・署名未検証 |
| A09 | ログ記録と警告の失敗 | ログの不備・異常検知の欠落。インシデント対応が遅れる |
| A10 | 例外的な状況の誤処理 | エラー処理・異常系での脆弱性。障害時の安全性が考慮されていない（新設） |
この10項目はそれぞれ独立したリスクではなく、実際の脆弱性は複数が組み合わさって被害に発展するケースが多いです。
たとえばA07（認証の失敗）でセッションを奪われ、A01（アクセス制御の不備）を通じて他ユーザーのデータを引き抜く、というシナリオは現実によくあります。
OWASP Top 10をどう使うか
OWASP Top 10はドキュメントとして読むだけでなく、実務のさまざまな場面で使えます。
設計・要件定義フェーズでは、各カテゴリを確認リストとして使うことで「このデータはA04（暗号化の失敗）の観点で保護されているか」という議論ができます。
実装・レビューフェーズでは、コードレビューの指摘に根拠を持たせることができます。
「ここは入力値のバリデーションが不十分です」だけでなく、「A05（インジェクション）に該当するリスクがあります」と伝えると、相手の認識も変わります。
顧客・ステークホルダーへの説明では、国際的な第三者機関の基準として提示できるので、「うちが独自に定めたルール」という印象を与えずに済みます。
私が特に価値を感じたのは、この「共通言語」としての側面でした。
議論のベースラインが揃うだけで、セキュリティの話が格段にしやすくなります。
IPAとOWASPの使い分け
「IPAでは不十分なのか」というと、そういうわけではありません。
目的に応じた使い分けが重要だと思っています。
| 観点 | IPA（安全なウェブサイトの作り方など） | OWASP Top 10 |
|---|---|---|
| 目的 | 啓発・概念理解 | 実装・レビュー・評価 |
| 更新頻度 | 比較的少ない | 数年おきに改訂 |
| 粒度 | 概念レベル | 実装チェックリストレベル |
| 対象読者 | 開発者全般・マネジメント層 | 開発者・セキュリティエンジニア |
| 顧客説明への使いやすさ | 国内資料として説得力あり | 国際標準として説得力あり |
国内の顧客に「セキュリティ対策が必要」を説明する際はIPA資料が有効で、実装レビューの根拠にはOWASPが有効、という使い分けが現実的だと思います。
OWASPの進化：Webを超えてAI/LLMまで
前職でOWASPを採用した当時は、Webアプリケーションのセキュリティが主な関心領域でした。
現在、OWASPのカバー範囲はさらに広がっています。
OWASP Top 10 for LLM Applications では、プロンプトインジェクション・データ漏洩・過剰な権限委譲など、LLMアプリケーション特有のリスクが体系化されています。
OWASP ASVS（Application Security Verification Standard） は、要件定義・設計・テスト各フェーズで使えるVerification Standardです。
OWASP AI Security & Privacy Guide はAIシステム全般を対象にしたセキュリティガイドで、AIを組み込んだシステムの設計・評価に使えます。
Webアプリからクラウド、API、そしてAI/LLMエージェントまで、時代の変化に追いついているフレームワークはそう多くありません。
それがOWASPを使い続ける理由の一つだと感じています。
まとめ
「とりあえずお任せで」と言われたとき。
「うちは大丈夫でしょ」と言われたとき。
社内レビューが形骸化しているとき。
そういったセキュリティの議論が機能しない環境で、自分が拠り所にできる基準としてOWASPは機能します。
もちろん他にも様々な基準(ISOやCIS、NIST等)が存在しますので、また改めて触れたいと思います。
セキュリティの議論を始めるための、ベースラインを作る。それがOWASPを採用した理由でした。
汎用性・信頼性・更新頻度・ドキュメントの充実度、どの軸でも現時点で最も実用的なフレームワークだと考えています。
まだ触れたことがない方は、まず OWASP Top 10の公式ページ を眺めてみるだけでも、Webセキュリティの輪郭が掴めるはずです。
セキュリティの話に入り口を探していた方のヒントになれば幸いです。
お知らせ
ACS 事業部のご紹介
私の所属する ACS 事業部では、開発者ポータル Backstage、Azure AI Service などを活用し、Platform Engineering ＋ AI の推進・内製化を支援しています。
www.ap-com.co.jp www.ap-com.co.jp www.ap-com.co.jp
また、GitHub パートナーとしてお客様に GitHub ソリューションの導入支援を行っています。 GitHub Copilot などのトレーニングなども行っておりますので、ご興味を持っていただけましたらぜひお声がけいただけますと幸いです。
一緒に働いていただける仲間も募集中です！
ご興味持っていただけましたらぜひお声がけください。
※求人名の冒頭に【ACSD】と入っている求人が当事業部の求人です。
