セキュリティ要件を相手に伝えるとき、何を渡せばよいのでしょうか。「安全に作ってください」では通じませんし、自前のチェックリストを作れば漏れが出ます。かといって「セキュリティ診断で何点」という数字は、何を確かめたのかを何も語りません。
OWASP ASVS(Application Security Verification Standard)は、この隙間を埋めるために作られました。アプリケーションセキュリティの要件を、検証可能な単位に分解して並べた目録です。
どこから来たものか
ASVSはOWASP(Open Worldwide Application Security Project)が公開している文書のひとつです。2009年から改訂を重ねていて、現在も更新が続いています。ライセンスは自由に使える形で公開されているので、社内標準に取り込んだり、契約書の別紙に使ったりできます。
背景にあったのは、評価が「診断した会社によって結果が変わる」状態にあり、何を見るかが共有されていない以上、結果を比べることもできなかった、という事情です。そこで「見るべき項目」を先に公開してしまおう、というのがこの文書の発想になります。
検証可能な要件、という考え方
ASVSの各項目は「〜を検証する(Verify that ...)」という形で書かれています。たとえば認証の章には、パスワードの最小長、ハッシュアルゴリズム、試行回数の制限といった項目が、それぞれ独立した番号付きの一文として並びます。
この書き方が効くのは、そのまま合否を判定できるからです。「認証が安全であること」では判定できません。「パスワードが12文字以上を許容すること」なら確かめられます。テストケースにも、レビューの観点にも、調達の要件にもそのまま落とせます。
OWASP Top 10と混同されやすいのですが、役割が違います。Top 10は「よくあるリスクの啓発」で、意識を向けるためのものです。順位が付いていて、網羅性は目指していません。ASVSは「検証すべき要件の一覧」で、網羅性を目指します。Top 10で問題意識を持ち、ASVSで確かめる、という関係になります。
要件にはCWE(Common Weakness Enumeration)への対応が付いていることが多くあります。CWEは脆弱性の「種類」に番号を振った分類で、たとえばSQLインジェクションはCWE-89にあたります。ASVSの要件とCWEが結びついていれば、その要件を満たさなかったときにどういう弱点が生まれるかを辿れますし、CWEで結果を返す検出ツールとの突き合わせにも使えます。
レベルという発想：点数を出しません
ASVSの特徴は、要件を三つのレベルに分けていることです。
レベル1 は、自動化されたテストや外部からの観察で確かめられる範囲です。侵入テストで到達できる程度の検証にあたり、すべてのアプリケーションが満たすべき最低線として置かれています。
レベル2 は、ソースコードや設計文書にアクセスして確かめる範囲です。多くの業務アプリケーションが目指すべき水準とされ、標準的な選択肢になります。
レベル3 は、機微な情報を扱う、あるいは止まると影響の大きいシステム向けです。医療、金融、重要インフラのような領域が想定されていて、設計の妥当性まで踏み込んで検証します。
ここで押さえておきたいのは、レベルが「点数」ではないことです。72点と85点の間に意味を見出すのは難しいのですが、「レベル2まで検証した」と「レベル1までしか検証していない」の差なら、そのまま言葉にできます。何を確かめて、何を確かめていないか。そこまで含めて伝わります。
稟議や取引先への説明で効くのはこの性質です。読み手が知りたいのは「使ってよいか」であって、点数ではありません。
誰が使うことを想定しているか
ASVSは、立場の違う三者が同じ文書を見られるように作られています。
作る側は、実装前の指針として使います。何を実装すべきかが要件として並んでいるので、設計の段階で漏れを減らせます。
検証する側は、テストの観点として使います。侵入テストでもコードレビューでも、何を見たかを要件番号で記録できます。
発注する側は、要求水準として使います。自分で技術的な詳細を書かなくても、レベルを指定すれば意図が伝わります。
同じ番号を三者が参照できること。これがこの文書の実用上の価値になっています。似た性質の文書として、モバイルアプリ向けのMASVSもあります。対象は違いますが、検証可能な要件をレベルで整理するという考え方は共通しています。
章の構成
要件は領域ごとの章に分かれています。認証、セッション管理、アクセス制御、入力値の検証、暗号、エラー処理とログ、データ保護、通信といった区切りです。ほかにアーキテクチャ、業務ロジック、ファイルとリソース、API、設定などの章も置かれています。
章立ては版によって再編されてきました。項目の統廃合や番号の振り直しがあるため、要件番号を引用するときは版数を必ず併記してください。 「V2.1.1」だけでは、どの版のどの要件か特定できないことがあります。
どう使うか
実務での使いどころは、大きく三つあります。
調達・発注の要件として。 「ASVSレベル2の要件を満たすこと」と書けば、何を求めているかが具体的に伝わります。開発会社側も、何をすればよいかが分かります。曖昧な「セキュアに」という指示より、双方にとって扱いやすくなります。
テスト設計の下敷きとして。 各要件がそのままテストケースの候補になります。自前でチェックリストを作るより漏れが少なく、なぜその項目を見るのかという根拠も、要件番号を示すだけで説明できます。
検査範囲の宣言として。 「どこまで確かめたか」を書くのに使えます。全項目を検証できないことは普通にありますが、そのときも「レベル2の要件のうち、Xの章は未検証」と書けば、受け取る側が判断できます。確かめていないことを、確かめていないと書けるのが、目録があることの利点です。
導入するときの順番
いきなり全項目を見ようとすると、まず間違いなく途中で止まります。現実的な進め方は次のようになります。
- 適用範囲とレベルを決める：対象のシステムと、目指すレベルを先に固定する。扱うデータの機微さと、止まったときの影響で決まる
- 該当しない要件を落とす：使っていない機能に関する要件は対象外にする。理由を書いて記録に残す
- 既に満たしているものを確認する：フレームワークが標準で担保している項目が多く、ここで残りの数が大きく減る
- 残りを優先度で並べる：全部を一度にやらず、落ちたときの影響が大きいものから
- 未検証の範囲を明示する：手が回らなかった範囲を、空白ではなく「未検証」と書く
五番目が抜けやすいところです。検証していない範囲を書かなければ、読み手はそこも確かめたものとして受け取ります。目録を使う利点の半分は、確かめていない場所を特定できることにあります。
注意しておくこと
すべてを満たす必要はありません。 ASVSは目録であって、全項目が全アプリケーションに当てはまるわけではありません。該当しない要件は「対象外」として、理由とともに記録するのが正しい使い方になります。適用範囲を決める作業が最初に来ます。
チェックを埋めることが目的化しやすくなります。 各項目に印を付ける作業に集中すると、そのアプリケーション固有のリスクが視界から外れます。業務ロジックの穴のような、目録に載らない問題は自分で見つけるしかありません。
AI固有の論点は、まだ十分にカバーされていません。 プロンプトインジェクション、モデルへの過剰な権限委譲、学習データの汚染。このあたりはOWASP Top 10 for LLM Applicationsのような別の文書が扱う領域です。AIを組み込んだアプリケーションを見るなら、ASVSだけでは足りません。
版の差に注意してください。 章立ても要件番号も版をまたぐと変わります。組織の基準として採用するなら、どの版を使うかを決めて明記しておく必要があります。
まとめ
ASVSが提供しているのは、要件の中身そのものよりも、セキュリティを語るための共通の単位です。
「安全です」でも「85点です」でもなく、「この版のこのレベルの要件を、ここまで検証した」と言えるようになります。何を確かめ、何を確かめていないかが、同じ言葉で共有できます。
セキュリティを組織の外（発注先、取引先、監査、稟議）に説明する場面が増えるほど、この共通の単位が効いてきます。手元の診断報告書を見直すときは、点数ではなく「どの版のどのレベルを、どこまで見たのか」が書かれているかを確かめてください。書かれていなければ、その報告書から読み取れる範囲は限られます。
