Securityチーム オーナーの松田です。
2025年5月に、ついにOWASP ASVSの最新版である 5.0 がリリースされました。そこで、私も非常にお世話になっているこのドキュメントについて、本記事でご紹介したいと思います。
OWASP ASVSとは？
まず、「OWASP（オワスプ）」とは Open Worldwide Application Security Project の略で、世界中のセキュリティ専門家が参加し、ソフトウェアのセキュリティ向上を目的として活動するオープンコミュニティです。診断ツールの開発、セキュリティガイドラインや標準の策定など、多様なプロジェクトが進められています。
その中の一つが OWASP ASVS（Application Security Verification Standard） です。
OWASPにおいて特徴的なのは、そのすべての成果物がオープンに公開されており、誰でも自由に利用できることです。OWASP ASVSもその例外ではなく、世界中の開発組織やセキュリティ専門家に採用されている、“実質的なデファクトスタンダード”とも言えるセキュリティフレームワークです。
OWASP ASVSは、Application Security Verification Standard では、アプリケーションセキュリティ検証標準という通り、アプリケーションのセキュリティを検証するための項目を体系的にまとめた標準で、テスト時のチェックリストとして利用できます。さらに、それだけでなく、開発時に参照できるセキュリティ要件のリストとして活用できます。これを活用することで、セキュリティを「後付け」ではなく、「設計段階から組み込む」ことが可能になります。
参考：【 Application Security Verification Standard 】
https://github.com/owasp-ja/asvs-ja
ASVSはどのように活用できる？
ASVSの活用方法をもう少し具体的にご紹介します。
ユースケース
- セキュリティアーキテクチャガイダンス
設計時に設計者が、データ保護パターンや入力バリデーション戦略などの一般的な問題に対してより適切な方法を選択できるようにするなどガイドラインになります - セキュアコーディングリファレンス
アプリケーション開発時にセキュアコーディングリファレンスを作成するための基盤として使用できます。そのまま使ってもいいのですが、組織ごとに独自のガイダンスを作成する際のベースとして活用できます - 自動ユニットテストおよび自動結合テストのガイド
もちろん、検証標準なので、テスト項目としてそのまま採用できます - セキュアなソフトウェアの調達をガイドするためのフレームワーク
例えば、調達者は調達するソフトウェアを ASVS レベル X で開発しなければならないという要件を設定し、そのソフトウェアが ASVS レベル X を満たすことを開発元に証明するよう要求することで、安全なソフトウェアを調達することができます
主に、設計、開発時に参照するガイド、テスト時に利用するテスト項目などのガイダンスとして、利用することができます。
弊社におけるASVSの活用事例
弊社KDL（以降KDL）では、OWASP ASVSをセキュア開発トレーニングに使っています。特にASVSでは、してはいけないことの Top 10 のような否定的なことではなく、肯定的なメカニズムに重点を置かれているため、実装しやすいことがメリットです。
もちろん、トレーニングで学習した内容を実践するわけですから、実際の設計、開発、テストにもASVSを採用しています。問題点として、ASVSの各要件は抽象度が高いという点がありますので、KDLの開発チームがより具体的に取り組みやすいよう、トレーニングで伝えたうえで使うようにしています。
また、コードレビューの観点にも利用しています。最近では、AIを使ってコードレビューをする際の観点として利用しています。
レベル体系について
ASVSには、レベルというものがあります。検証の強度を表し、主にシステムが取り扱うデータの機密度合いによって、どのレベルの要件を採択するか決定することに利用しています。
ASVS では三つのセキュリティ検証レベルを定義されており、レベルが増えるごとに要求レベルが高くなります。なお、レベルは文書および要件テキストにおいて L1, L2, L3 と表記されることがあります。
各レベルにおける要件は？
各レベルの要件はざっくりと以下のように定義されています。
- レベル1：インターネットに公開されるすべてのアプリケーション向け（基本的なセキュリティ）
- レベル2：機密データを扱う業務アプリケーション向け（より強固なセキュリティ）
- レベル3：高度な攻撃対象となるシステムや重要インフラ向け（最高レベルのセキュリティ）
おススメは、レベル1から始め、ニーズや成熟度に応じて上位レベルへ移行することです。レベル 1 から始めてどのレベルに到達すべきか、それは、アプリケーションの機密性やユーザの期待によって決まります。
たとえば、限定的な機密データしか収集していないスタートアップ企業は初期のセキュリティ目標としてレベル 1 にするかもしれませんが、銀行のオンラインバンキングアプリケーションでは、レベル 3 相当にすべきと考えています。一般的な個人情報のような機密データを扱うWebアプリケーションであれば、レベル 2 相当の要件まで実装すべきと考えています。
バージョン5.0での主な変更点
2025年5月にOWASP ASVSの最新版である 5.0 がリリースされました。従来までのバージョン 4.0.3 の 286 の要件のうち、変更されていないのは 11 件のみと、バージョン5.0 は、大幅に変更されました。
主な変更点を見ていきましょう。
構造変更と新章
バージョン 4.0.3 とバージョン 5.0 の章立てを見比べてみます。
バージョン4.0.3
- V1 アーキテクチャ、設計、脅威モデリング
- V2 認証
- V3 セッション管理
- V4 アクセス制御
- V5 バリデーション、サニタイゼーション、エンコーディング
- V6 保存時の暗号化
- V7 エラー処理とログ記録
- V8 データ保護
- V9 通信
- V10 悪性コード
- V11 ビジネスロジック
- V12 ファイルとリソース
- V13 API と Web サービス
- V14 構成
バージョン5.0
- V1 エンコーディングとサニタイゼーション
- V2 バリデーションとビジネスロジック
- V3 Web フロントエンドセキュリティ
- V4 API と Web サービス
- V5 ファイル処理
- V6 認証
- V7 セッション管理
- V8 認可
- V9 自己完結型トークン
- V10 OAuth と OIDC
- V11 暗号化
- V12 安全な通信
- V13 構成
- V14 データ保護
- V15 セキュアコーディングとアーキテクチャ
- V16 セキュリティログ記録とエラー処理
- V17 WebRTC
最も目についたのは、「V1 アーキテクチャ、設計、脅威モデリング」という設計に関わる章がなくなったことです。
これについては、実は各章に分散しています。各章の1つめ、例えばV1.1 エンコーディングおよびサニタイゼーションアーキテクチャとなっており、各章ごとに設計から、実装まで読みやすくなっています。
さらに、「セキュリティ上の決定事項の文書化」という概念が追加されました。バージョン4.0は暗黙的に要求されていたのですが、バージョン5.0からは、各章の1つ目に明示されていることがあります。具体例は以下のとおり。
例）V2.1 バリデーションとビジネスロジックドキュメント
2.1.3 ビジネスロジックの制限とバリデーションに対する期待は、ユーザーごと、およびアプリケーション全体にわたって文書化されている。
レベル定義の再考
レベルについてもバージョンごとに再考がされています。
バージョン4において各レベルは、以下で定義されていました。
- L1（レベル1） ：最小 (Minimum)
低保証レベル向けであり、すべてがペネトレーションテスト可能です。 - L2 （レベル2）：「標準 (Standard)」
機密データを含むアプリケーション向けであり、保護を必要とし、ほとんどのアプリに推奨されるレベルです。 - L3 （レベル3）：上級 (Advanced)」
極めて重要なアプリケーション向けであり、高額取引を行うアプリケーション、機密性の高い医療データを持つアプリケーション、最高レベルの信頼性を必要とするアプリケーションのためのものです。
バージョン4では、L1の要件数が約120項目と多かったうえに、「最小（Minimum）」レベルとして設定されていたにもかかわらず、多くのアプリケーションには不十分な内容でした。その結果、要件数の多さが採用のハードルとなってしまったことが指摘されました。
そこで、以降のバージョンにおいて、L1の要件をより明確かつ少なく整理することが目指されています。バージョン4.0.3では、全278件の要件のうちL1の要件は128件あり、全体の約46%を占めていました。一方、バージョン5.0.0では、全345件のうちL1要件は70件に減り、全体の約20%と大幅に削減されています。
また、バージョン4では、L1要件の評価において「ブラックボックス（外部ペネトレーションテスト）で確認できるかどうか」が重視されていました。しかし、これは本来のL1が意図する「セキュリティコントロールの最小セット」と必ずしも一致していませんでした。
そこで、バージョン5.0では、各レベルの決定基準をリスク軽減の効果を中心に見直し、さらに実装に必要な労力も考慮した、より実践的でバランスの取れた構成へと改善されています。
各章の説明
ASVS バージョン5 では、17の章、約350の要件があります。
章が分かれている理由は、私たちの取捨選択のためです。例えば、マシン間で接続するような API を提供するアプリケーションの場合、Web フロントエンドに関連する V3 章の要件（主にブラウザに関連する要件）は関係ありません。OAuth や WebRTC を使用しないのであれば、V10 章やV17 章も無視できます。
各章について、ざっくり説明してみましょう。
| 章 | 内容 |
| V1 エンコーディングとサニタイゼーション | ユーザ入力などの信頼できないデータを処理する際に使われるエンコーディングやサニタイゼーションの要件が記載されています。主にSQLインジェクションやクロスサイトスクリプティングなどの攻撃に対する防御のために使われることが多く、ほとんど全てのWebアプリケーションで採用される章です。 |
| V2 バリデーションとビジネスロジック | ユーザ入力などの信頼できないデータを受け入れるときの検証に関する要件です。こちらもほとんど全てのWebアプリケーションで採用される章です。 |
| V3 Web フロントエンドセキュリティ | ブラウズで動作するWebアプリケーションに向けた章です。レスポンスヘッダやCookieの扱いなどが要件に含まれます。 |
| V4 API と Web サービス | Web ブラウザやマシン間で使用する API を公開 (通常 JSON, XML, GraphQL を使用) するアプリケーションに向けた章です。GraphQLやWebSocketに関する要件などが含まれます。 |
| V5 ファイル処理 | ファイルを処理する場合の要件です。ファイルを受け取って保存したり、ダウンロードさせる要件がある場合には、この章を参照してください。 |
| V6 認証 | 認証に関する要件です。認証がある場合は、必ずこの章を参照してください。 |
| V7 セッション管理 | セッション管理メカニズムに関する要件です。セッション管理があるアプリケーションは必ず参照してください。なお、Cookieを利用する場合は、V3 Web フロントエンドセキュリティを、自己完結型トークン(IDトークンなど)を利用する場合は、V9 自己完結型トークンも併せて参照してください |
| V8 認可 | アクセス権限の制御があるアプリケーションでは必ず参照してほしい章です。認証がある場合は、V6,7と併せてこの章もほとんど必須になると思います。 |
| V9 自己完結型トークン | 自己完結型トークンという概念は 2012 年のオリジナルの RFC 6749 OAuth 2.0 で言及されています。これは受信側サービスがセキュリティ上の決定を行うために依拠するデータやクレームを含むトークンを指します。IDトークンや一部のアクセストークン、SAMLアサーションを指します。 |
| V10 OAuth と OIDC | OAuthやOIDCプロトコルを利用するアプリケーションのための要件です。OAuthクライアント、OAuthリソースサーバ、OAuth認可サーバのそれぞれの役割ごとの要件が記載されていますので、実装する役割に合わせて参照しましょう |
| V11 暗号化 | 暗号の一般的な使用に関するベストプラクティスを定義されています。主に、データを暗号化して保存する場合に参照してください |
| V12 安全な通信 | 通信を暗号化する際の要件です。ほとんどWebアプリケーションが、TLS通信で提供されるため、この要件の対象となります |
| V13 構成 | この章は設定に関するガイダンスです。例えば、「シークレットへのアクセスは最小権限の原則に従っている。」など設定に関する内容が入っています。この章でカバーするトピックは、データ漏洩の防止、コンポーネント間の通信の安全な管理、シークレットの保護などです。 |
| V14 データ保護 | この章には、どのようなデータを保護する必要があるのか、どのように保護すべきなのか、実装すべき具体的なメカニズム、回避すべき落とし穴といった定義に関連する要件です。サーバ上で暗号化するという内容ではなく、ロードバランサやブラウザにキャッシュされないようにすることなどが記載されています。機密データを扱う場合は、必ず参照する章です。 |
| V15 セキュアコーディングとアーキテクチャ | この章ではアプリケーションの設計と開発の際に考慮すべき、一般的なセキュリティ要件を提供します。読むとへーーと言いたくなるような内容が結構含まれているので、実装される方には、ぜひ見てほしい章です。 |
| V16 セキュリティログ記録とエラー処理 | アプリケーションが残すログとそのログファイルの扱いに関する要件です。ログは必ず残すものなので、ほとんど全てのアプリケーションで採用されると思います。 |
| V17 WebRTC | Web リアルタイム通信 (Web Real-Time Communication, WebRTC) システムを開発、ホスト、統合する関係者向けのセキュリティ要件を提供します。 |
ECサイトであれば、V1,V2,V3,V5,V6,V7,V8,V9,V11,V12,V13,V14,V15,V16 を参照することになります。
他のOWASPプロジェクトとの関係
OWASP ASVSは、単体で使うこともできますが、他のOWASPプロジェクトと組み合わせることでより効果的に活用できます。
- OWASP Top 10
最もよく見られる脆弱性をまとめた「啓発資料」です。ASVSが「どう作るべきか」を示すのに対し、Top 10は「何が問題か」を教えてくれます。開発初期のリスク認識に活用できます。
https://owasp.org/www-project-top-ten/ - OWASP Cheat Sheet Series
ASVSの各要件を「具体的にどう実装すればよいか」を示すガイド集です。ASVSが“何をすべきか”、Cheat Sheetが“どうやるか”を補い合う関係です。
https://cheatsheetseries.owasp.org/ - OWASP Web Security Testing Guide
ASVSの要件を「どのようにテストすれば確認できるか」を詳しく解説する手引きです。ASVSを基準書、Testing Guideを検証マニュアルとして使うと効果的です。
https://github.com/OWASP/wstg
ASVSを中心に、Top 10で課題を認識し、Cheat Sheetで実装し、Testing Guideで検証するという流れが理想的です。
まとめ：ASVSを「読む」から「使う」へ
OWASP ASVSは、セキュリティを「リリース前のチェックリスト」から「設計段階の要件」に引き上げるための、強力なフレームワークです。
バージョン5.0では、全体の構成が大きく見直され、特にレベル1の項目が約半分に減り、導入しやすくなりました。以前よりもシンプルで現実的な内容になったことで、開発チームが段階的にセキュリティ品質を高めていくことが可能になっています。
まずは、レベル1から始めてみましょう。自社の開発プロセスに合わせて、少しずつASVSの要件を取り入れていくことで、「セキュリティを後付けする開発」から「セキュリティを前提に設計する開発」へと自然にシフトできます。ASVSは、読むだけではなく“使ってこそ価値がある”標準です。
このブログをきっかけに、あなたのチームでもASVSを活用し、安全で信頼されるアプリケーション開発に一歩踏み出してみてください。
セキュアなシステム開発についての
＼ 無料相談受付中！ ／
株式会社神戸デジタル・ラボ
デジタルビジネス本部 Securityチーム オーナー / 生産技術チーム
神戸大学情報知能工学科卒。2014年にKDLに入社。自社で構築するECサイトのほぼすべてのプロジェクトに関与しながら、多くの開発プロジェクトを経て、現在はSecurityチーム オーナーと全社のセキュア開発を推進する生産技術チームを兼任。開発部門主導のセキュア開発を実践している。
コミュニティ活動として、OWASP Kansaiボードメンバー、アルティメットサイバーセキュリティクイズ実行委員を務める。
【参考サイト】
OWASP Application Security Verification Standard ja
https://github.com/owasp-ja/asvs-ja
OWASP Application Security Verification Standard
https://github.com/OWASP/ASVS
Open Worldwide Application Security Project（OWASP）
https://owasp.org/
OWASP Top10
https://owasp.org/www-project-top-ten/
OWASP Cheat Sheet Series
https://cheatsheetseries.owasp.org/
OWASP Web Security Testing Guide
https://github.com/OWASP/wstg
