owasp-top-10-testing

OWASP Top 10 に対するテスト

OWASP Top 10 はリスクカテゴリの分類体系であり、テストスイートではありません。「OWASP Top 10 テスト」とは、実際のアプリケーションに対して各カテゴリの検証を行い、実際に悪用可能なものを報告することを意味します。Strix のエージェントが悪用を実行します。このスキルでは、カテゴリごとにテストを実行し、対象範囲を正直に報告する方法を説明します。

現行版のOWASP Top 10:2025を使用してください（第8版で、2021年版に取って代わるものです）。古い版を対象にする場合は、事前にユーザーに確認してください。一部のコンプライアンスチェックリストでは今も2021年版が参照されており、誤った版を記載したレポートは誤解を招きます。2021年版からの主な変更点は、SSRF が A01 に統合されたこと、A03 ソフトウェアサプライチェーンの障害が従来の「脆弱で古いコンポーネント」から範囲を拡大したこと、そしてA10 例外的な状況への不適切な対応が新設されたことです。A02 セキュリティ設定ミスは5位から2位に移動しました。

インストール、LLM のセットアップ、マネージドクラウドの代替手段については、penetration-testing-with-strixを参照してください。Docker も LLM キーも使わずに実行する場合は、同じバイナリでマネージドプラットフォームを利用できます。strix cloud loginを実行してから、strix cloud scans start ...を実行してください（詳細はmanaged-pentesting-with-strixを参照）。

エージェントでテストできること、できないこと

この点はユーザーに率直に伝えてください。10項目すべてを漏れなくテストしたと主張するのは誤解を招きます。

カテゴリ（2025年版）	対応範囲
A01 アクセス制御の不備（SSRF を含む）	強力 — ユーザー間・テナント間のアクセス、権限昇格、IDOR、SSRF（帯域外コールバックを介したブラインド SSRF を含む）は、すべて悪用を検証します。認可の両面を証明するには、2つのアカウントと、さらに1つの特権アカウントが必要です。
A02 セキュリティ設定ミス	強力 — デバッグ用エンドポイント、詳細すぎるエラー、過度に許可的な CORS、強化設定の不足、デフォルト認証情報、露出した管理画面などが対象です。
A03 ソフトウェアサプライチェーンの障害	部分的 — バージョンのフィンガープリンティングと、ソースが提供された場合の依存関係の脆弱性・陳腐化の確認が対象です。このカテゴリのより広い範囲にあたる、ビルドシステムや配布インフラの侵害は、実行時スキャンの対象外です。SCA とビルド来歴管理を組み合わせてください。
A04 暗号化の失敗	部分的 — 通信設定、転送中の非暗号化データ、レスポンス内で漏えいしたシークレットやトークンが対象です。保存データの暗号化と鍵管理には、ソースまたはインフラのレビューが必要です。
A05 インジェクション	強力 — SQL／NoSQL／コマンド／テンプレートインジェクションと XSS が対象で、悪用を検証します。
A06 安全でない設計	部分的 — ビジネスロジックの悪用（価格・数量の改ざん、ワークフローのスキップ、競合状態）は、到達可能な場合に検出します。設計意図の確認には、引き続き人によるレビューと脅威モデリングが必要です。
A07 認証の失敗	強力 — 認証バイパス、脆弱なセッション／トークン処理、パスワードリセットや MFA の不備が対象です。
A08 ソフトウェアまたはデータの完全性の失敗	部分的 — 到達可能な場合、安全でないデシリアライゼーションと署名のない更新経路が対象です。CI/CD の信頼境界は実行時にはテストできません。
A09 セキュリティログとアラートの失敗	外部からはテスト不可 — ログとアラートのパイプラインをレビューする必要があります。合格として報告するのではなく、テストできないことを明記してください。
A10 例外的な状況への不適切な対応	部分的 — エージェントはエラー処理とフェイルオープンの動作（不正な入力、エラーの強制、競合状態やタイムアウトの条件）を積極的に調査し、情報漏えいや制御のバイパスを報告します。内部エラーパスを網羅的に確認するには、ソースレビューが必要です。

API では、OWASP API Security Top 10 (2023) に対して同じテストを実施してください。API1 BOLA、API3 オブジェクトプロパティレベル認可の不備（2019年版の過剰なデータ露出と一括割り当てを統合）、API5 機能レベル認可の不備が対象です。api-security-testingスキルを使用してください。

実行する

カテゴリーを最大限網羅するには、エージェントにソースと実行中のインスタンスの両方を渡し、さらに2つの権限レベルの認証情報を用意してください。

strix -n \
  -t https://github.com/org/app \
  -t https://staging.example.com \
  --scan-mode deep --max-budget 30 \
  --instruction "OWASP Top 10:2025 assessment. Cover every category systematically and map each finding to its 2025 category id.
Accounts: [email protected]/<pw> (org 1), [email protected]/<pw> (org 2), [email protected]/<pw>.
Prioritise A01 (cross-org access, privilege escalation, SSRF), A02, A05, A07, A10.
Out of scope: /billing/*, outbound email."

• ここでは --scan-mode deep が重要です。10個のカテゴリーを体系的に調べるには、簡易スキャンでは不十分です。
• 2つ目のアカウントがない場合、A01 の結果は構造的に不完全です。明記しないままにせず、レポートにその旨を記載してください。
• 監査担当者向けのPDFが必要ですか？ マネージドプラットフォームで実行し、技術レポートを取得してください（managed-pentesting-with-strix）。

正直に報告する

strix_runs/<run>/ から vulnerabilities/*.md をカテゴリー別にまとめ、カテゴリーごとに、試みたこと、実証できたこと、評価できなかったこと（A09 は常に、A03/A04/A06/A08/A10 は部分的に）を記載してください。使用したエディションをレポートに明記してください。PoC はすべて、自分で検証してからユーザーに提示してください。

終了コードが 0 でも、分析対象の範囲で悪用可能な脆弱性が実証されなかったことを意味するにすぎません。run.json のステータスとコストを --max-budget と照合してください。予算上限に達して終了した実行は、評価が完了したとはいえません。

その後、修正して再テストする

fix-security-vulnerabilities-with-strix で修正し、それぞれのエクスプロイトが無効化されたことを証明するために再実行してください。アプリの変更に応じて継続的に確認するには、ci-security-scanning-with-strix を使ってプルリクエストにゲートを設定してください。