2026.07.06 セキュリティ

OWASPとは？主要プロジェクトの全体像とアプリ開発への組み込み方【2026年時点】

OWASP（Open Worldwide Application Security Project）は、WebアプリケーションやAPIのセキュリティを改善するためのドキュメント・ツールを無償で公開している非営利団体です。読み方は「オワスプ」。名前だけは知っていても、Top 10・ASVS・WSTG・ZAPといった成果物がどう関係し、自社の開発でどれをどの工程に使えばよいのかは、意外と整理されていません。この記事では、OWASPの成り立ちと主要プロジェクトの全体像、Web・API・LLMという3系統のTop 10の使い分け、そして設計からリリースまでの工程別の組み込み方を、実装者の視点でまとめます。各Top 10の項目ごとの詳細や個別ツールの操作手順は、末尾の関連記事および本文中の版別記事に配流します。

まとめ：OWASPは団体名であり、Top 10は成果物の一つという整理

最初に結論を示します。OWASPは「団体（財団）の名前」であり、よく混同されるOWASP Top 10はその団体が公開する成果物の一つにすぎません。実務で押さえる順序はこうです。まずOWASPが何を出しているかの全体像（Top 10・ASVS・WSTG・Cheat Sheets・SAMM）を把握し、次に自分たちの対象（Web／API／LLM）に対応するTop 10を選び、最後にASVSやWSTGを要件・テストの言語へ翻訳します。

ツールとしてのOWASP ZAPやDependency-Checkは、この「翻訳」を自動化する手段です。ツールから入ると全体像を見失います。開発現場での要点を一言でいえば、OWASPは規格そのものではなく、規格化のための共通語彙を与えるものだと捉えると使いこなしやすくなります。Top 10を「守るべきチェックリスト」ではなく「議論の出発点」として扱うのが、遠回りに見えて確実な入り口です。

OWASPとは何か：非営利団体の成り立ちと主要プロジェクトの全体像

OWASPを正しく使う前提として、団体としての位置づけと、公開されている成果物の種類を押さえます。ここを飛ばすと、Top 10だけを断片的に眺めて終わってしまいます。

OWASPの正式名称・読み方と運営するOWASP財団の体制概要

OWASPは2001年に発足し、米国を拠点とする非営利のOWASP財団によって運営されています。名称は長らく「Open Web Application Security Project」でしたが、対象がWebに限らずAPIやモバイル、生成AIへ広がったことを受け、2023年ごろから「Open Worldwide Application Security Project」という表記が公式に併用されるようになりました。OWASPの読み方は「オワスプ」で、英語圏でも同様に発音されます。

特徴は、成果物のライセンスがオープンである点です。企業・個人を問わず無償で参照でき、多くは翻訳や再配布が許可されています。日本国内にもOWASP Japanという地域チャプターがあり、勉強会や日本語訳の整備が進められてきました。ベンダー中立で運営されるため、特定製品の宣伝ではなく脆弱性の分類や検証観点そのものを議論できるのが、この団体を参照する理由になります。

OWASP主要成果物の全体像：Top 10・ASVS・WSTG・SAMM

OWASPが公開するプロジェクトは数百に及びますが、開発現場でまず知るべきは次の5つに絞れます。役割が重ならないよう整理しておきます。

  • Top 10：頻出かつ影響の大きいリスクを10項目に順位づけした「気づきのための一覧」。入門と合意形成に使う。
  • ASVS（Application Security Verification Standard）：検証すべき要件を階層化した「合否を測る物差し」。x.y系で改訂が続く。
  • WSTG（Web Security Testing Guide）：どう検査するかの「テスト手順書」。ASVSの要件を実際の試験に落とす。
  • Cheat Sheet Series：個別テーマの実装対策を短くまとめた「逆引きメモ」。コードレビュー時に引く。
  • SAMM（Software Assurance Maturity Model）：組織のセキュリティ成熟度を測る「体制の物差し」。プロセス改善に使う。

この5つのうち、開発初期に触れる機会が多いのはTop 10とCheat Sheetです。ASVSとWSTGは要件定義・テスト設計の段階で効き、SAMMは単一プロジェクトではなく組織運営の話になります。まずはTop 10とCheat Sheetから入り、監査や第三者検証が視野に入った時点でASVS・WSTGへ広げる順序が、負担を抑えつつ抜け漏れを防ぎます。

OWASP Top 10の3系統：Web・API・LLM向けリストと最新版の位置づけ

「OWASP Top 10」と一括りにされがちですが、対象別に独立した3つのリストが並行して維持されています。自社の作っているものに合わないリストを見ると、対策がずれます。ここは版と対象を必ずセットで確認してください。

OWASP Top 10（Web）の版管理と2021年版・2025年版の扱い

もっとも参照されるWebアプリ向けのTop 10は、数年おきに改訂されます。2026年時点で正式版として広く使われているのは2021年版で、その後継となる2025年版がリリース候補（RC）として公開され、確定作業が進んでいる段階です。版が変わると項目の統廃合や順位入れ替えが起きるため、社内標準に引用する際は「2021年版」「2025年版RC」のように版を明記するのが安全です。

各項目（インジェクション、アクセス制御の不備など）を一つずつ実装対策まで掘り下げると、この記事だけでは収まりません。最新版の項目構成と変更点はOWASP Top 10 2025年版とは何かで個別に扱っているため、Webの詳細対策はそちらを起点にしてください。

API・LLM向けTop 10という派生標準と適用対象の見分け方

WebのTop 10ではカバーしきれない領域には、専用のリストがあります。バックエンドをAPI中心に組む場合は、認可の不備（BOLAなど）を軸にしたAPI向けのリストが実態に合います。適用対象は次の表に整理しました。

系統 主な対象 版の扱い・時点
Web Top 10 Webアプリ全般 2021年版が正式・2025年版はRC
API Top 10 Web API 2023年版が最新（時点）
LLM Top 10 生成AI・LLMアプリ 2025年版が公開（時点）

API側の詳細な脅威分類はOWASP API Security Top 10 の概要とその重要性に、プロンプトインジェクションや機微情報の漏えいを扱う生成AI向けはOWASP Top 10 for LLMにまとめています。判断基準は単純で、認証・認可をAPIゲートウェイで捌く構成ならAPI版、LLMを組み込む機能があるならLLM版を併読します。1つのプロダクトで複数系統が同時に該当することも珍しくありません。

診断と検証に使うOWASPツールと標準：ZAP・ASVS・WSTG

ドキュメントを読むだけでは脆弱性は見つかりません。OWASPは、検証を自動化・標準化する道具も提供しています。ここでは「動かして探す道具」と「基準として測る道具」を分けて捉えます。

OWASP ZAP（DAST）とDependency-Check（SCA）の使い分け

OWASP ZAP（Zed Attack Proxy）は、稼働中のアプリに疑似的な攻撃リクエストを送って脆弱性を探すDAST（動的解析）ツールです。画面遷移やフォーム送信を通じて、XSSやインジェクションの兆候を外側から検出します。一方Dependency-Checkは、利用しているライブラリに既知の脆弱性（CVE）がないかを照合するSCA（ソフトウェア構成解析）ツールで、対象がまったく異なります。

両者は排他ではなく補完関係にあります。自前のコードの挙動を突くのがZAP、持ち込んだ部品の由来を調べるのがDependency-Check、と役割を分ければ重複しません。ZAPの診断項目やスキャン種別の具体はWeb脆弱性診断ツール「OWASP ZAP」とは？で詳しく解説しています。CI/CDに組み込む場合は、ZAPを結合テスト環境の後段、Dependency-Checkをビルド段に置くのが定石です。

ASVSとWSTGを要件定義・テスト設計へ落とし込む具体手順

ツールの検出結果を「合否」に変えるのがASVSとWSTGです。ASVSは検証要件をレベル1〜3に段階化しており、一般的な業務システムはレベル2、決済や個人情報を大量に扱う系はレベル3を目安に据えます。要件定義の非機能要件として「ASVSレベル2の該当項目を満たす」と書けば、抽象的な「安全に作る」を検証可能な条件へ翻訳できます。

WSTGは、そのASVS要件を「どう試験するか」の手順に対応させたガイドです。実務の流れは次の順序が扱いやすいです。

  1. 対象の重要度からASVSのレベルを決める
  2. 該当するASVS要件を抜き出し、受け入れ条件に転記する
  3. 各要件をWSTGの試験項目に紐づけ、テストケース化する
  4. ZAP等の自動診断で拾える範囲を切り分け、残りを手動試験に回す

この4手順を踏むと、「なんとなくの診断」から「要件に対する合否判定」へ検証の性質が変わります。バージョンはASVSがx.y系で改訂されるため、参照時点の版を要件書に明記しておきます。

開発プロセスへのOWASP組み込み：採用すべき場面と見送る場面

ここからは独自の見解です。OWASPは全部を採り入れれば安全になる、という道具ではありません。工程ごとに使いどころを絞り、費用対効果が合わない部分は割り切る判断が要ります。

設計からリリースまで工程別にOWASP成果物を割り当てる指針

成果物を工程に割り当てると、負担が平準化します。設計段階ではTop 10を脅威モデリングの観点リストに使い、実装段階ではCheat Sheetをコードレビューの逆引きに使います。テスト段階でASVS／WSTGとZAPを合わせ、ビルド段階でDependency-Checkを回す。この配置なら、リリース直前にまとめて診断してから手戻りする、という最悪の順序を避けられます。

小規模な開発で全工程に導入するのが難しい場合は、優先度を明確にします。まず入れる価値が高いのはDependency-Check（既知脆弱性の混入は事故に直結する）と、設計段階でのTop 10レビューです。この2つは費用がほぼ人的コストのみで、効果が読みやすいからです。

OWASPをそのまま全面採用すべき条件と過剰投資で見送る場面

立場を明確にします。ASVSレベル3やWSTG全項目の手動試験まで踏み込むべきなのは、決済・医療・個人情報を大量に扱う、あるいは外部監査や取引先の要求で第三者検証が必須になるケースに限られます。ここでは全面採用が妥当です。

逆に、社内利用のみで機微情報を持たない管理ツールや、公開前の検証用プロトタイプに対して、ASVSレベル3を課すのは過剰投資です。この段階でTop 10のアクセス制御とインジェクションだけを重点確認し、ASVSの全要件チェックは本番公開の判断が立ってから段階導入する、という見送りが現実的です。判断軸は「扱うデータの機微度」と「外部からの検証要求の有無」の2点で、ここが弱いのに手厚い検証を積むのは、リリースを遅らせるだけの負債になります。セキュアなアプリ・システム開発の進め方に迷う場合は、Webシステム開発の相談窓口で要件段階から一緒に検証レベルを設計できます。

よくある質問

OWASPの概念と使い方について、検索で多く見られる質問に簡潔に答えます。

OWASPの読み方は？何の略称ですか？

「オワスプ」と読みます。Open Worldwide Application Security Project（旧称：Open Web Application Security Project）の略で、Webやアプリのセキュリティ向上を目的に、ドキュメントやツールを無償公開している非営利団体を指します。2023年ごろから「Web」を「Worldwide」に改めた表記が公式に使われるようになりました。

OWASP Top 10の最新版はどれですか？

Webアプリ向けは2026年時点で2021年版が正式版として広く使われ、2025年版がリリース候補として公開されている段階です。対象別にAPI版（2023年版が最新）、LLM版（2025年版が公開）が別途あります。社内引用時は「どの系統の何年版か」を必ず明記してください。項目の詳細は本文リンク先の版別記事で確認できます。

OWASP ZAPは商用の脆弱性診断の代わりになりますか？

一次的なスクリーニングには十分機能しますが、完全な代替にはなりません。ZAPは自動診断で拾える範囲を効率よく検出しますが、業務ロジックの不備や認可の抜けなど、文脈依存の脆弱性は手動試験や専門家の判断が必要です。自動診断で網を張り、重要度の高い箇所を手動で補う二段構えが実務的です。

OWASP ASVSとTop 10はどう使い分けますか？

Top 10は「気づき」のための入門的な一覧で、抜け漏れの発見や関係者の合意形成に向きます。ASVSは「合否を測る」ための検証要件集で、要件定義やテストの受け入れ条件に落とし込む段階で使います。入り口はTop 10、監査や第三者検証が視野に入ったらASVS、という順序が扱いやすいです。

OWASPの成果物は無料で使えますか？

主要なドキュメント（Top 10・ASVS・WSTG・Cheat Sheetなど）とツール（ZAP・Dependency-Check）は、いずれもオープンライセンスで無償利用できます。多くは翻訳・再配布も許可されており、商用プロジェクトでの参照も可能です。ただし版によって内容が変わるため、参照時点の版を記録しておくと後の監査で齟齬が出ません。

関連記事

資料請求

RELATED POSTS 関連記事

一覧へ戻る