TL;DR

OWASP ASVSは、開発者、テスター、アーキテクトが使用する、ウェブアプリのセキュリティを検証するための、コミュニティ主導の詳細なチェックリストです。

AuthN、AuthZ、暗号、APIセキュリティなどの分野をカバーし、L1（基本）からL3（重要なアプリ）に分かれている。

認定資格ではないが、セキュリティのベースラインを設定したり、ペンテストを実施したり、セキュアなアプリを一から構築したりするのに理想的だ。

OWASP ASVS スコアカードまとめ：

• 開発者の労力：開発者の労力：中～高（多くの領域にわたる詳細なセキュリティ管理を理解し、開発中にそれらを正しく実装する必要がある。）
• ツール費用：低～中程度（標準自体は無料。コストは、ASVS要求事項に対するテストに使用するツール（SAST、DAST、IAST、ペンテストツール）に関連する。
• 市場への影響：高い（Web アプリのセキュリティ検証の業界標準として広く認められている。）
• 柔軟性：高（リスクに応じて調整できるレベル。）
• 監査の強度：該当なし（認証のための正式な監査基準ではないが、厳しいセキュリティ評価／テストの際に使用される）。

OWASP ASVSとは？

OWASP Application Security Verification Standard（ASVS）は、ウェブアプリケーションのセキュリティを検証するために特化した、セキュリティ要件と管理の枠組みを提供するオープンソースプロジェクトです。ASVSの主な目的は2つあります：

1. 開発者向けセキュアな開発手法の指針となる、セキュリティ要件の詳細なリストを提供する。
2. テスト実施者向けセキュリティ評価、侵入テスト、セキュアコードレビューにおいて、ウェブアプリケーションの技術的なセキュリティ対策をテストするための基礎を提供します。

OWASP ASVSは、主要なセキュリティ領域をカバーする章立てになっている：

• V1:アーキテクチャ、デザイン、脅威モデリング
• V2:認証
• V3: セッション管理
• V4: アクセス・コントロール
• V5: バリデーション、サニタイゼーション、エンコーディング
• V6: 蓄積暗号
• V7: エラー処理とログ
• V8: データ保護
• V9: 通信セキュリティ
• V10：悪意のあるコード
• V11: ビジネス・ロジック
• V12: ファイルとリソース
• V13: APIとウェブサービス
• V14: コンフィギュレーション

各章の中に、具体的な検証要件（管理策）が列挙されている。重要なことは、OWASP ASVSが、3 つのセキュリティ検証レベル（ASVS レベル）を定義していることです：

• レベル1（低保証）：低リスクのアプリケーション、あるいは、最初のステップのためのものです。容易に検出可能な脆弱性と、多くの場合自動的 にチェック可能な管理（例えば、基本的な侵入テスト）に重点を置いています。すべてのアプリケーションは、少なくともレベル 1 を目指すべきです。
• レベル2（標準保証）：ほとんどのアプリケーション、特に機密データを扱うアプリケーションや重要なトランザクションを実行するアプリケーションに推奨。一般的なアプリケーションセキュリティリスク（OWASP Top 10 のような）に対する防御をカバーする、より詳細なチェックが必要。設計／コードレビュー要素を含む、自動テストと手動テストの両方が必要。
• レベル3（高保証）：機密性の高いデータを扱うクリティカルなアプリケーション向け（金融、医療、政府機関など）。熟練した攻撃者に耐えられるよう、綿密な設計レビュー、コードレビュー、厳格なテストなど、包括的なセキュリティ検証が必要。

要求レベルは、各章の中でどの特定の検証要件を満たさなければならないかを決定する。

なぜ重要なのか？

OWASP ASVSは、現代のウェブ・アプリケーション・セキュリティの要である：

• 標準化を提供します：何が安全なウェブアプリケーションを構成するかについて、一貫した再現可能な標準を提供し、その場限りのテストから脱却します。
• 実行可能なガイダンス：開発者には具体的な要件を、テスターには具体的な検証項目を与え、ハイレベルな原則と実装のギャップを埋める。
• リスクベースのアプローチ：レベルシステムにより、組織はアプリケーションのリスクプロファイルに基づいて検証作業を調整することができる。
• OWASP Top 10 を補完：トップ10は一般的なリスクをリストアップしているが、ASVSはこれらのリスク（およびその他多くのリスク）を軽減するために必要な詳細なコントロールを提供する。
• 業界からの評価開発者、セキュリティ専門家、ソフトウェアを調達する組織から広く評価され、世界中で使用されている。
• セキュアな SDLC をサポートします：要求の定義、設計/コーディングの指針、検証テストの基礎の形成など、SDLC 全体を通して統合することができます。
• オープンソース＆コミュニティ主導セキュリティ専門家のグローバルコミュニティにより、自由に利用でき、常に更新されています。

OWASP ASVS を使用することで、セキュリティテストが徹底的で、一貫性があり、ウェブアプリケーションを保護するために 実際に重要なコントロールに焦点を当てていることを確実にすることができます。

何をどのように実施するか（技術・政策）

OWASP ASVSを実装することは、認証を取得することではなく、安全なアプリケーションを構築し、検証するために標準を使用することである：

1. 必要なレベルの決定：アプリケーションのデータの機密性、ビジネスの重要性、および規制要件に基づいて、目標とするASVSレベル（1、2、または3）を選択します。
2. 要件に統合する（設計段階）： 選択したレベル（及び関連する章）の ASVS 要件を、設計及び計画段階におけるセキュリティ要件のインプットとして使用する。
   
   • 例（V4 アクセス制御）：異なるユーザー・ロールを必要とするアプリを構築する場合、V4.1.1（「アプリケーションが信頼されたサービス・レイヤー上でアクセス制御ルールを強制することを検証する...」）のようなASVSチャプターV4の要件を確認し、それに従ってシステムを設計する。
3. ガイド開発（コーディング段階）： 開発者は、ASVSの要件をチェックリストとして使用し、セキュアなコーディングプラクティスが守られていることを確認する。
   
   • 例(V5 Input Validation)：入力フォームを構築する際には、V5.1.1（「アプリケーションがHTTPパラメータ汚染に対する防御を持っていることを検証する...」）やV5.2.1（「構造化データが強く型付けされていることを検証する...」）のようなV5要件を参照すること。これらの要件を満たす入力検証ライブラリとルーチンを実装してください。
4. セキュリティテスト（検証段階）を知らせる： セキュリティテスト担当者（ペンテスト担当者、コードレビュー担当者）は、対象レベルの ASVS チェックリストを使用して、評価を構成する。該当する各要件が満たされているかどうかを検証する。
   
   • 例（V2 認証）：レベル 2 を検証するテスタは、V2.2.1（「パスワードの最小長が 12 文字であることを検証する...」）、V2.1.1（「クレデンシャルが決して回復可能な形で保存されないことを検証する...」）、 V2.4.1（「アカウントロックアウトの仕組みがあることを検証する...」）のような要求事項をチェックする。
5. ツール統合：
   
   • SAST/DAST ツール：ASVS 要件に関連する違反をチェックするためにスキャナを構成する（例えば、V5 に関連する潜在的なインジェクションの欠陥を見つける）。
   • チェックリストの管理：スプレッドシートやSecurityRATのようなツールを使用して、ASVS要件の管理、適用可能性の追跡、検証結果の記録を行う。
6. 文書化：設計文書、コードコメント、テストレポートの一部として、ASVS要求事項がどのように満たされたか（または、適用できないと判断された理由）を文書化する。

実装とは、安全に構築するためのガイドとして、また、セキュリティを検証するためのチェックリストとして、SDLC 全体を通じて ASVS リストを積極的に使用することです。

避けるべき一般的な間違い

OWASP ASVSを使用する際には、これらのよくあるエラーに注意してください：

1. 誤ったレベルの選択：リスクの高いアプリケーションにレベル1を選択したり、リソースがレベル2の検証しかできないのにレベル3を目指したりすることで、不十分または不完全な評価につながる。
2. 単なるペンテスト・チェックリストとして扱うこと：レベル2とレベル3では、設計とコードレビューの側面が必要となります。ダイナミック・スキャンだけに頼っていると、重要な脆弱性を見逃してしまう。
3. 適用可能性の無視：特定のアプリケーションのアーキテクチャ、技術スタック、機能に関連するかどうかを考慮せずに、やみくもにすべての要件を適用しようとすること。
4. 開発者トレーニングの欠如：必要なセキュリティの基礎概念やセキュアなコーディングプラクティスに関するトレーニングを行わずに、開発者が ASVS 要件を満たすことを期待する。
5. 一貫性のない適用：あるテストでは ASVS を厳格に適用するが、次のテストでは表面的に適用するため、セキュリティ態勢に一貫性がない。
6. 早期に統合しない：ASVSを、最初から安全な設計や開発に役立てるのではなく（その方がはるかに効果的である）、最終的なテストにのみ使用する。
7. 要件の誤解：特定の ASVS 検証要件の背後にあるニュアンスや意図を理解していない。

監査人/テスト担当者が質問すること（開発者フォーカス）

OWASP ASVSを使用するセキュリティテスト担当者は、基本的に、開発者に（直接、あるいはコード／設計レビューを通じて）、特定の要求事項がどのように満たされているかを示すように求めます：

• (V1)"このアプリケーションの脅威モデルを見せてもらえますか？"(1.1.1 - L2+)
• (V2)「ユーザーのパスワードはどのように保存されていますか？ハッシュ化の実装を見せてもらえますか？"(2.2.2 - L1+)
• (V3)「どのようにセッション・トークンを生成し、ハイジャックから保護するか」（3.1.1、3.3.1 - L1+）。
• (V4)「標準ユーザが管理者機能にアクセスすることを、アプリケーションがどのように防ぐかを示すこと。(4.1.1, 4.1.2 - L1+)
• (V5)"この重要な API エンドポイントに使用されている入力検証ルーチンを示してください。"(5.1.3, 5.2.1 - L1+)
• (V6)"暗号鍵はアプリケーション内のどこで、どのように管理されるか?"(6.2.1 - L2+)
• (V7)"アプリケーションは機密情報を漏らさずにエラーをどのように処理するか？"(7.1.1 - L1+)
• (V8)"データベースに保存される機密データはどのように保護されていますか（暗号化、マスキング）？"(8.1.1 - L2+)
• (V13)"APIリクエストの認証と認可はどのように行われますか?" (13.1.1, 13.2.1 - l1+)(13.1.1, 13.2.1 - L1+)

彼らは、コード、構成、設計文書、または実行中のアプリケーションに具体的な証拠を求め、ターゲット・レベルに関連する各ASVS要求事項への準拠を検証する。

開発チームのクイックウィン

開発者は、OWASP ASVSの原則を簡単に取り入れることができる：

1. レベル 1 の基本に集中する：まず、認証（V2）、アクセス制御（V4）、入力バリデーション（V5）といった主要分野のレベル 1 要件を見直し、実装することから始める。これらは、多くの一般的な欠陥をカバーしている。
2. セキュアなフレームワークのデフォルトを使用する：Webフレームワークの組み込みセキュリティ機能（セッション管理、CSRF保護、出力エンコーディングなど）を活用します。
3. 検証およびエンコード： すべての入力を一貫して検証し、ブラウザ、API、データベース向けのすべての出力をエンコードします。(V5のコア)
4. 基本的なログの記録主要なセキュリティイベント（ログイン、失敗、重要なトランザクション）がログに記録されるようにする。 V7 の中核
5. OWASP トップ 10 のレビュートップ 10 のリスクを理解し、ASVS コントロールがどのようにリスクの軽減に役立つかを理解する。
6. SAST ツールを使用する：SAST ツールを構成し、一般的な ASVS 要件に関連する違反にフラグを立てる（例：安全でないパスワードの取り扱い、潜在的なインジェクション・ポイント）。

これを無視すれば...（コンプライアンス違反の結果）

OWASP ASVSに概説されている原則と要求事項を無視することは、基本的なウェブアプリケーションのセキュリティ対策 を無視することを意味します。その結果は直接的です：

• 侵害の可能性が高くなる：アプリケーションは、XSS、SQLインジェクション、認証違反、アクセス制御違反などの一般的な攻撃に対してより脆弱になる（ASVSの章に直接関連する）。
• データの損失/盗難：脆弱性により、攻撃者は機密性の高いユーザーデータを盗むことができ、プライバシー侵害や規制上の罰金（GDPRなど）につながる。
• サービスの中断：攻撃はアプリケーションをオフラインにし、ビジネスの中断と収益の損失を引き起こします。
• 風評被害：セキュリティ・インシデントは顧客の信頼を損ない、企業ブランドを傷つける。
• セキュリティ監査／ペンテストの失敗：顧客やパートナーがセキュリティテストを要求する場合、ASVS の原則を念頭に置いて構築されていないアプリケーションは失敗する可能性が高く、取引やデプロイメントが阻害される可能性があります。
• 修復コストの増加：サイクルの後半や侵害後に脆弱性を見つけて修正することは、ASVSをガイドとしてセキュリティを構築するよりもはるかにコストがかかる。

本質的に、OWASP ASVSに準拠しないことは、本質的に安全でないウェブ・アプリケーションを構築することを意味する。

よくあるご質問

OWASP ASVSは、SOC 2やISO 27001のようなコンプライアンス規格ですか？

OWASP ASVSは検証標準であり、基本的にはウェブアプリケーションのセキュリティをテストするための詳細なチェックリストです。SOC 2 や ISO 27001 のような正式な監査や認証には関与しません。しかし、ASVS のレベルを満たすことで、これらの広範な枠組みにおける技術的な管理要件を満たすことができます。

OWASP ASVSとOWASP Top 10の違いは？

OWASP トップ 10 は、コミュニティのコンセンサスとデータに基づいて、最も重大な 10 のウェブアプリケーションのセキュリティリスクをリストアップしています。OWASP ASVS は、これらのリスク（および、他の多くのリスク）を予防し、テストするために必要な、詳細なセキュリ ティ対策と検証要件を提供します。ASVS は、それらに対する防御をどのように検証するかを教えてくれます。

どのASVSレベルを目指すべきか？

リスクによって異なる。レベル1は、すべてのアプリケーションの最低基準です。レベル2は、機密データやトランザクションを扱うほとんどのアプリケーションに推奨される。レベル3は、障害が深刻な結果をもたらすような重要度の高いアプリケーション（金融、健康データなど）向けです。

特定のレベルに必要な条件を100％満たす必要がありますか？

一般的には、すべての適用可能な要求事項に対して「はい」である。この規格では、要件が本当にアプリケーションの技術や機能に適用されない場合、「Not Applicable」とマークすることを認めていますが、これには正当な理由が必要です。特定の要求事項を直接満たすことができない場合、代償となるコントロールが認められることがあります。

ASVSは侵入テストだけですか？

侵入テスト（特にレベル 1）で多用されていますが、ASVS のレベル 2 とレベル 3 では、アーキテクチャ、設計、および、ソースコードのレ ビューを含め、動的テストを超えた検証を明確に要求しています。これは、全体的なアプリケーションセキュリティ検証を意図しています。

ASVSとの照合はどのくらいの頻度で行うべきか？

検証は SDLC に統合されるべきである。これは、コードレビュー中に関連する要求事項をチェックすること、CI/CD において ASVS と整合した自動テストを実行すること、そして、主要なリリースの前や、重要なアプリケーションのために定期的（例えば、毎年）に完全な ASVS 評価を（ターゲットレベルで）実行することを意味するかもしれません。

ASVSはAPIやモバイルアプリに使用できますか？

OWASP ASVS第 13 章では、API とウェブサービスの検証を特に取り上げている。主にウェブ・アプリケーションに焦点を当てているが、多くの原則は広く適用される。モバイルに特化したものとして、OWASP にはモバイル・アプリケーション・セキュリティ検証基準（MASVS）もある。