OWASP はベンダ中立の非営利組織であり、ベンダ、検証者、ソフトウェアの認証は行っていません。ASVS 準拠を主張する保証、認証マーク、認証はいずれも OWASP によって公式に承認されたものではないため、組織は第三者が主張する ASVS 認証に注意する必要があります。
OWASP の公式な認証であると主張しない限り、組織は保証サービスを提供できます。
アプリケーションセキュリティ検証標準 (ASVS) は、特に L2 および L3 検証において、アーキテクト、開発者、ドキュメント、ソースコード、認証されたテストシステムなどのリソースへのオープンアクセスが必要です。
従来のペネトレーションテストは「例外による」問題を報告し、不合格のみをリストします。しかし、認証レポートには、スコープ、合格および不合格のテストの要約、問題解決のガイダンスを含めるべきです。要件の中には適用できないもの (ステートレス API でのセッション管理など) もあり、その旨をレポートに記載しなければなりません。
作業書類、スクリーンショット、スクリプト、テストログなどの詳細なドキュメントは、調査結果の堅実な証跡を提供するための標準的な慣行です。各要件は検証可能な形でテストしていなければならないため、徹底的なテストを行わずにツールを実行するだけでは認証には不十分です。
ASVS はコンプライアンスを検証する厳密な方法について意図的に明確にしていません。しかし、いくつかの重要なポイントを強調しておくことは重要です。
組織は一般的にすべての要件を実施するわけではなく、一部の要件は組織にとって無関係またはそれほど重要ではない可能性があるため、検証のスコープは明確に定義する必要があります。検証者は、組織が達成しようとしているレベルを明確にし、実施されていない要件を除外する根拠についての意見を示す必要があります。
これにより、検証報告書の利用者は検証の背景を理解し、アプリケーションにおける信頼レベルについて十分に理解した上で判断できるようになります。
認証機関は適切なテスト手法を選択できますが、レポートでそれを開示する必要があります。アプリケーションや要件に応じて、手動ペネトレーションテストやソースコード解析などのさまざまな手法を使用して、入力バリデーションなどの側面を検証できます。
特定の ASVS 要件を検証するには、さまざまな技法が必要になることがあります。ペネトレーションテスト以外にも、ASVS 要件を検証するには、ドキュメント、ソースコード、構成、および開発プロセスに関与する人々へのアクセスが必要となることがあります。
ASVS 要件の検証における自動化の使用は、常に関心を集めるトピックです。バージョン 5.0 がリリースされた後、要件の検証方法を示すテストガイドを準備したいと考えていますが、現時点では自動テストとブラックボックステストに関連するいくつかのポイントを明確にすることが重要です。
DAST や SAST ツールなどの自動セキュリティテストツールは、ビルドパイプラインに効果的に実装されると、存在してはいけないセキュリティ問題を効果的に特定できます。ただし、慎重な設定とチューニングを行わないと、必要なカバレッジが得られない可能性があり、ノイズのレベルによって実際のセキュリティ問題を特定および緩和できない可能性があります。
これによって、出力エンコーディングやサニタイゼーションに関連するものなどの、より基本的で簡単な技術要件をカバーできるかもしれませんが、これらのツールではより複雑な ASVS 要件や、ビジネスロジックやアクセス制御に関連する要件の多くを完全には検証できないことに注意することが重要です。
それほど単純ではない要件では、自動化を利用できる可能性はありますが、これを実現するにはアプリケーション固有の検証を記述する必要があるでしょう。これらは組織がすでに使用している単体テストや統合テストに似ているかもしれません。そのため、この既存のテスト自動化インフラストラクチャを使用して、ASVS 固有のテストを記述することが可能かもしれません。これを行うには短期的な投資が必要ですが、これらの ASVS 要件を継続的に検証できるようになるという長期的な恩恵が大きくなるでしょう。
要約すると、自動化ツールを使用してテスト可能であることは、既製ツールを実行することではありません。
バージョン 4.0 の L1 は「ブラックボックス」(ドキュメントもソースもない) テストを実行するように最適化されていましたが、それでも、これは効果的な保証活動ではなく、積極的に推奨すべきではないことは明らかでした。
必要な追加情報にアクセスできない状態でテストを行うことは、セキュリティ検証のメカニズムとしては非効率的で非効果的です。それは、ソースをレビューし、脅威や対策漏れを特定し、より短い時間枠でのはるかに徹底的なテストを実施する可能性を逃すことになるためです。
ペネトレーションテストを、開発プロセス全体を通じて開発者とドキュメントに完全にアクセスできる、ドキュメントやソースコード主導 (ハイブリッド) のペネトレーションテストに置き換えることを強くお勧めします。これは、多くの ASVS 要件を検証するために必要になるでしょう。