セキュリティ要件を相手に伝えるとき、何を渡せばいいのか。「安全に作ってください」では通じないし、自前のチェックリストを作れば漏れが出る。かといって「セキュリティ診断で何点」という数字は、何を確かめたのかを何も語らない。
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点です」でもなく、「この版のこのレベルの要件を、ここまで検証した」と言えるようになる。何を確かめ、何を確かめていないかが、同じ言葉で共有できる。
セキュリティを組織の外——発注先、取引先、監査、稟議——に説明する場面が増えるほど、この共通の単位が効いてくる。