security-testing

ハッピーパスだけを確認するログインテストは合格しても、有効期限切れの JWT が依然として管理者権限を与え、IDOR によってユーザー A がユーザー B の注文を読み取れ、Webhook のフィールドが `169.254.169.254` に到達することがあります。このスキルでは、アクセス制御の不備、インジェクション、SSRF、認証バイパス、サプライチェーンのドリフトといったネガティブパスのチェックを CI で全 PR に対して実行し、DAST、SCA、SAST、カスタム Playwright テストを組み合わせて、単一のツールの死角から問題がリリースされないようにします。OWASP Top 10（2025）に対応する実行可能なテストと、カテゴリに回帰があった場合にビルドを失敗させる CI ゲートを用意します。

調査の質問

まず .agents/qa-project-context.md を確認してください。存在する場合はその内容を使い、すでに回答済みの項目（認証方式、コンプライアンス要件、インフラストラクチャ）はスキップしてください。その後、以下を確認します。

1. 脅威モデル： チームは主要な資産、脅威アクター、攻撃対象領域を特定していますか？まだの場合は、テストを書く前に簡易的な脅威モデルを作成してください。どのカテゴリが最も重要かを判断できます。
2. 認証方式： セッション Cookie、JWT、OAuth 2.0/OIDC、API キー、MFA のどれですか？それぞれに固有のネガティブパステスト（アルゴリズムの混乱、セッション固定、状態の改ざん）があります。
3. コンプライアンス要件： SOC 2、HIPAA、PCI DSS、GDPR のどれですか？これらには特定のコントロールが義務付けられています。compliance-testing を使って対応付けてください。このスキルでは、コントロールが正しく機能することだけを確認します。
4. 既存のセキュリティツール： OSV-Scanner、Snyk、Dependabot、Semgrep、ZAP をすでに実行していますか？重複を追加する前に、CI 設定で既存のセキュリティステージを確認してください。
5. API の範囲： REST、GraphQL、gRPC のどれですか？プロトコルごとに、固有のインジェクションおよび認可の攻撃ベクトルがあります。
6. デプロイモデル： クラウド（AWS/GCP/Azure）、コンテナ、サーバーレスのどれですか？クラウドメタデータのエンドポイントは主要な SSRF の標的であり、設定ミスは A02 に該当します。

---

基本原則

1. セキュリティは継続的なものであり、単独の工程ではありません。 四半期ごとの侵入テストではなく、すべての PR で CI スキャンを実行します。脆弱性を持ち込んだ PR で検出できれば数分で済みますが、本番環境で同じ脆弱性が見つかればインシデントになります。

2. OWASP Top 10 は最低ラインであり、上限ではありません。 最も一般的で影響の大きいカテゴリを対象としています。ドメイン固有の脅威（医療データ、金融取引、マルチテナントの分離）には、さらに独自の分析が必要です。

3. 多層防御 — どの単一ツールもすべてを検出できるわけではありません。 ZAP は認証ロジックのバグを見逃し、SCA は独自コードを見逃し、Semgrep は実行時の問題を見逃します。DAST + SCA + SAST + 認証テスト + シークレットスキャンを組み合わせてください。ある層の死角を別の層がカバーすれば、回帰がリリースされるにはすべての層をすり抜ける必要があります。リリースされるコードの大半はサードパーティ製であるため、SCA は重要な層です。依存関係に含まれる既知の CVE は、最も手間の少ない攻撃ベクトルなので、ビルドのたびにスキャンしてください。

4. シフトレフト。 各カテゴリをできるだけ早い段階で検出します。コミット時に SAST とシークレットスキャン、PR で依存関係／サプライチェーンのチェック、ステージング環境で DAST、実行のたびにカスタム認証テストを行います。この仕組みが組み込まれる開発・QA ワークフローについては、shift-left-testing を参照してください。

5. ユーザーではなく攻撃者をテストしてください。 ハッピーパスの認証テストで確認できるのはログインが機能することです。セキュリティテストでは、ログアウトによってセッションが無効になること、有効期限切れのトークンが拒否されること、権限昇格が失敗すること、不正なペイロードが安全側に倒れて拒否されることを確認します。ネガティブパスこそがテストです。

---

OWASP Top 10（2025）テストチェックリスト

2025 年版（確定版、owasp.org/Top10/2025/）ではカテゴリの順序が変更され、新たに 2 つのカテゴリが追加されました。2021 年版からの変更点：

• A03 ソフトウェアサプライチェーンの障害が新設されました（「脆弱で古いコンポーネント」を置き換え、来歴、ビルドパイプラインの信頼性、SBOM まで対象を拡大）。
• A10 例外条件の不適切な処理が新設されました。SSRF は独立したカテゴリではなくなり、関連テストは A01（アクセス制御）と A06（安全でない設計）に含まれます。
• A02 セキュリティ設定ミスが A05 から繰り上がりました。
• A07 認証の失敗 — 名前が短縮されました（「識別と」が削除）。
• A09 セキュリティログ記録とアラートの失敗 — 名前が変更されました（旧称は「ログ記録と監視」）。

カテゴリごとの実行可能なテストコードについては、references/owasp-tests.md を参照してください。

A01: アクセス制御の不備

最も多い脆弱性です。ユーザーが意図された権限の範囲を超えて操作します。攻撃者がサーバーを誘導して内部リソースにアクセスさせる場合、SSRF もアクセス制御の不備に該当します。

テスト項目： IDOR（リソース ID を変更して他のユーザーのデータにアクセスする）、関数レベルのアクセス制御の欠如（一般ユーザーとして管理者用エンドポイントにアクセスする）、パストラバーサル（../../etc/passwd）、CORS の設定ミス、SSRF（ユーザーが指定した URL から内部ネットワーク、クラウドメタデータのエンドポイント、file:// にアクセスする）。

A02: セキュリティ設定の不備

デフォルトの認証情報、不要な機能、詳細すぎるエラー。A05 から順位が上がりました。今も最も簡単な侵入経路です。

テスト項目： 本番環境でスタックトレースが無効になっていること、デフォルトの認証情報が変更されていること、不要な HTTP メソッド（例：TRACE）が無効になっていること、ディレクトリ一覧表示が無効になっていること、管理パネルが公開されていないこと、クラウドバケットが公開されていないこと。

A03: ソフトウェアサプライチェーンの障害

2025 年に新設されました。「古い依存関係」だけでなく、来歴、ビルドパイプラインの完全性、サプライチェーン全体が対象です。

テスト項目： ロックファイルがコミットされ、CI がそこからインストールすること（npm ci を使い、npm install は使わない）。SBOM が生成され、ビルド成果物として保存されること（Syft / anchore/sbom-action）。ビルド成果物に対する来歴の証明（SLSA v1.0 L2/3、cosign / actions/attest-build-provenance で署名）。すべての PR で依存関係レビューを実施すること。CI のシークレットがフォークに公開されないこと。セルフホストランナーが信頼できない PR のコードから隔離されていること。

依存関係レビュー／SBOM／来歴のワークフローとロックファイルの不整合チェックについては、references/owasp-tests.md を参照してください。

A04: 暗号化の不備

暗号化が弱い、または暗号化されていないために、機密データが漏えいします。

テスト項目： TLS のバージョン／暗号スイート／HSTS。パスワードが bcrypt/argon2 でハッシュ化されていること（MD5/SHA1 は使わない）。URL、ログ、エラーに機密データが含まれていないこと。Cookie に Secure、HttpOnly、SameSite が設定されていること。セキュリティヘッダーが設定されていること（HSTS、X-Content-Type-Options: nosniff、X-Frame-Options）。

A05: インジェクション

信頼できないデータがインタープリターに送られます。

テスト項目： パラメーター／フィールド／ヘッダーへの SQL インジェクション。ユーザーコンテンツでの XSS（反射型、格納型、DOM ベース）。状態を変更する操作への CSRF。ファイル名、検索クエリ、Webhook URL へのコマンドインジェクション。

A06: 安全でない設計

アーキテクチャ上の欠陥は、実装だけでは修正できません。許可リストなしで URL を受け付ける機能における設計レベルの SSRF、レート制限なしのクレデンシャルスタッフィング、ビジネスロジックの悪用などが含まれます。

テスト項目： 認証エンドポイントのレート制限（ログインを 15 件並行して試行し、応答に 429 が含まれることを確認する）。ビジネスロジックの悪用（負の数量、クーポンの併用）。ログイン失敗後のアカウントロック。ユーザー指定の URL を取得する機能における許可リスト方式の設計。

A07: 認証の不備

認証の破綻、脆弱なパスワード、クレデンシャルスタッフィング。ログイン後のセッションローテーション、期限切れ／alg:none の JWT の拒否、RBAC マトリクス、OAuth の state 改ざん。references/auth-tests.md を参照してください。

A08: ソフトウェアまたはデータの完全性の不備

署名されていない更新、安全でないデシリアライズ、信頼できない CI/CD。

テスト項目： CDN スクリプトに対する Subresource Integrity（SRI）。Content-Security-Policy ヘッダーが設定され、'unsafe-inline'／'unsafe-eval' を含まないこと。

A09: セキュリティログとアラートの不備

ログ記録の不足に加え、記録された内容に対するアラートも不足しています。2025 年の名称変更は、アラートのないログは検知ではなく、事後的な証拠にすぎないことを強調しています。

テスト項目： ログイン失敗が記録され、かつしきい値を超えた場合にアラートが発報されること。管理者操作が監査ログに記録され、かつ時間外の操作でアラートが発報されること。ログにシークレット／PII が含まれていないこと。アラートパイプライン自体が監視されていること。

A10: 例外条件の不適切な処理

2025年に新設されました。エラーや予期しない状態は攻撃対象領域です。フェイルオープンのデフォルト設定、内部情報を漏らす未処理の例外、エラー処理経路における競合状態、「何か問題が発生した」際にスキップされるセキュリティチェックなどが該当します。

テスト内容： エラーレスポンスからスタックトレース、フレームワーク名、DB スキーマが漏れないこと、認証がフェイルクローズであること（デフォルトで拒否）、タイムアウトや部分的な障害によって認可が回避されないこと、すべてのエラー処理経路でリソースが解放されることを確認します。すべてのエンドポイントにファジングを行い、レスポンスが文書化されたエラー仕様の範囲内に収まることを検証します。

---

OWASP LLM Top 10 (2025)

アプリに LLM（チャットボット、RAG、エージェント、コパイロット）を組み込んでいる場合、上記の従来の Top 10 ではその障害モードをカバーできません。OWASP Gen AI Security Project の別のリスト（genai.owasp.org/llm-top-10/）を使用してください。これはセキュリティ／CI ゲート向けの観点で、カテゴリごとに「テスト内容」を一文でまとめています。LLM01 と LLM02 の詳細な動作カバレッジ（ツール／RAG データ経由の間接的なインジェクション、テスター防御手法、ジェイルブレイクのレッドチーミング、実行可能なインジェクション検出器）については、ai-system-testing に引き継いでください。ここで重複させないでください。

ID	カテゴリ	テスト内容
LLM01	プロンプトインジェクション	直接的・間接的なインジェクション（取得したドキュメント、ツール出力、ファイルの内容に隠された指示）がシステムの意図を上書きしないこと。→ 詳細なカバレッジは ai-system-testing を参照してください。
LLM02	機密情報の漏えい	細工されたプロンプトによって、モデルが PII、シークレット、他のテナントのデータ、または学習データを漏らさないこと。→ 詳細なカバレッジ（検出器、スコープを限定したテスト）は ai-system-testing を参照してください。
LLM03	サプライチェーン	モデル、アダプター、データセット、プラグインの来歴、固定／検証済みの重み、悪意のあるサードパーティ製モデルや LoRA を確認します。
LLM04	データおよびモデルのポイズニング	学習／ファインチューニング／RAG 取り込みデータの完全性、汚染されたソースを介して注入されたバックドアやバイアスを確認します。
LLM05	出力処理の不備	LLM の出力がサニタイズされずに後続のインタープリターへ渡されることによる、XSS、SSRF、SQLi、生成テキストからのコマンドインジェクションを確認します。
LLM06	過剰な自律性	エージェントがタスクに必要な範囲を超えるツール／権限／自律性を持っていないこと、人間による承認なしに削除、支払い、メール送信ができないことを確認します。
LLM07	システムプロンプトの漏えい	システムプロンプトが抽出できないこと。さらに、シークレットの保持や、サーバー側で行うべき認可の強制をシステムプロンプトに依存していないことを確認します。
LLM08	ベクトルおよび埋め込みの脆弱性	RAG 検索がテナント／権限の境界を越えないこと、埋め込みの反転、コンテキストとして返される汚染ベクトルを確認します。
LLM09	誤情報	自信に満ちた捏造（幻覚による事実、偽の引用／URL、安全でないコード）が信頼できる情報として受け入れられないことを確認します。
LLM10	無制限の消費	トークン／レート／コストの上限がないことによる、プロンプト主導のリソース枯渇、金銭的損失を狙ったサービス妨害、クエリ量を利用したモデル抽出を確認します。

LLM05（出力処理の不備）は、従来の Top 10 と再びつながる部分です。LLM の出力を信頼できない入力として扱い、生成されたすべての内容に対して A05 インジェクションのチェックを再実行してください。

---

自動セキュリティスキャン

完全なパイプラインでは、DAST、依存関係／サプライチェーンスキャン、SAST、シークレットスキャンを段階的に組み合わせます。設定と CI ワークフローについては、references/scanning-and-ci.md を参照してください。

• OWASP ZAP（DAST）： PR ごとにステージング環境を対象にベースラインスキャンを実行します。API には zap-api-scan.py を使用します。現行バージョンは ZAP 2.17.0 です（週次の w2026-MM-DD Docker タグ）。**ZAP MCP Server（2026 年 4 月）**を使うと、コーディングエージェントがスパイダー／アクティブスキャン／アラート分析を実行し、「差分をスキャンする」ワークフローを実現できます。
• **依存関係／サプライチェーン：**OSV-Scanner をデフォルトのゲートにします — 多言語に対応し、脆弱性が1件でもあるとゼロ以外の終了コードを返します。A03 対策として、SBOM（Syft）と来歴（cosign ／ attest-build-provenance）を追加します。npm audit --audit-level=high は semver のみを対象とするノイズの多い簡易チェックであり、ゲートには適しません（semver の厳密な形式に準拠しないバージョンにはフラグを立てず、ゼロ以外の終了コードも確実には返しません）。
• **SAST：**Semgrep p/owasp-top-ten を SAST ゲートにします。 eslint-plugin-security は弱い補助的なシグナルです — 以下の注記を参照してください。網羅性を担わせず、lint 時の注意喚起として使用してください。
• シークレットスキャン： CI では --only-verified を指定した TruffleHog を使用し、コミット前には git-secrets を使用します。

eslint-plugin-security を SAST ゲートとして頼りにするのは避けてください — 2026 年半ば時点でルールは約13個にとどまり、2020 年以降、実質的なルールの増加はありません。また、ベンチマークでは検出可能な脆弱性の約90％を見逃すとされています。バージョン 4.0.0 はフラット設定に対応しているため設定は動作しますが、Semgrep の代わりではなく、Semgrep の下に組み合わせてください。

ESLint 10（2026 年 2 月）では .eslintrc が完全に削除されました — フラット設定（eslint.config.js）のみが動作します。ESLint 10 では、.eslintrc.* のセキュリティ設定はすべて機能しません。ESLint 8 に固定したリポジトリでのみ使用してください。両方の設定ブロックについては、references/scanning-and-ci.md を参照してください。

---

認証テストのパターン

セッション管理、JWT（有効期限、alg: none の混同、誤ったキーでの署名）、RBAC マトリックスのテストを行います。完全なコードは references/auth-tests.md にあります。また、ログイン後のセッションローテーション（セッション固定攻撃対策）と OAuth の state パラメーターの改ざんもテストしてください。

---

CI との統合

完全なセキュリティパイプラインは、CI のステップとして実行する5つのレイヤーで構成されます。

1. シークレットスキャン — --only-verified を指定した TruffleHog
2. 依存関係チェック — OSV-Scanner（脆弱性が1件でもあれば失敗）；A03 対策として SBOM と来歴
3. SAST — Semgrep p/owasp-top-ten をゲートとして使用し、ESLint のセキュリティプラグインは弱い補助として使用
4. DAST — ステージング URL を対象に ZAP のベースラインスキャンを実行
5. カスタム認証テスト — npx playwright test --project=security

PR ゲートとしてのセキュリティ： OSV-Scanner は脆弱性が1件でもあるとゼロ以外の終了コードを返し、マージを直接ゲートします。代わりに npm audit をゲートにする場合は、npm audit --json を解析し、high／critical の件数が 0 より大きければ exit 1 を実行してください — npm audit はそれ自体ではゼロ以外の終了コードを確実には返しません。実行可能なゲートについては、references/scanning-and-ci.md を参照してください。

---

アンチパターン

リリース前だけにセキュリティテストを行う。 発見が遅れるほど修正コストが高くなります。四半期ごとではなく、すべての PR をスキャンしてください。

単一のツールに頼る。 ZAP は認証ロジックのバグを見逃し、SCA は独自コードの問題を見逃し、ESLint は実行時の問題を見逃します。複数のツールを組み合わせてください。

ほとんど使われなくなったリンターを SAST のカバレッジとして扱う。 eslint-plugin-security だけでは、ほとんど何も検出できません（ルールは約 13 件で、検出内容は 2020 年ごろの水準です）。Semgrep の p/owasp-top-ten をゲートにし、リンターは注意喚起として使い続けてください。

依存関係の警告を無視する。 「後で修正する」は、既知の CVE のバックログになります。OSV-Scanner で重大度が高またはクリティカルな場合は、ビルドを失敗させてください。

正常系の認証だけをテストする。 ログインは動作する。それで問題ありません。ログアウトするとセッションは無効になりますか？ 有効期限切れのトークンでリソースにアクセスできますか？ 権限の昇格は可能ですか？

テストファイルにシークレットをハードコードする。 実際のキーを含むテスト自体が脆弱性になります。環境変数と CI シークレットを使用してください。

SSRF テストを省略する。 URL を受け付ける機能（Webhook、画像アップロード、インポートなど）は、すべて SSRF の攻撃ベクトルになります。内部アドレスとクラウドメタデータのエンドポイントをテストしてください。

複数のステータスコードが有効なのに、単一のコードだけをアサートする。 SSRF／CSRF／例外的な状態のテストでは、許容されるコードが複数あります。expect([400, 403, 422]).toContain(response.status()) を使用してください。toBeOneOf は組み込みのマッチャーではないため、実行時にエラーになります。

既知のペイロードだけをテストする。 参考資料にある XSS／SQLi のペイロードは一例であり、網羅的ではありません。幅広くカバーするため、ZAP が保守するペイロードデータベースを使用してください。

---

検証

アサーションが実際に機能することを証明してください。誤った URL を使っていてマッチャーが実行されないなど、実質的に何も検証せず通過するセキュリティテストスイートは、ないよりも悪いものです。

1. 意図的に脆弱性を含めたターゲットに、異常系のテストを 1 つ向けて、テストが失敗することを確認してください。OWASP Juice Shop のような既知の脆弱性を含むアプリをローカルで実行します：

   docker run --rm -p 3000:3000 bkimminich/juice-shop
   BASE_URL=http://localhost:3000 npx playwright test --project=security
   

   IDOR／インジェクション／ヘッダー欠落のテストで、失敗が報告されるはずです。Juice Shop に対してすべて成功する場合、アサーションがアプリに到達していません。自分のステージング環境で成功した実行結果を信頼する前に、セレクター／URL を修正してください。
2. マッチャーの形式が実行されることを確認してください。 grep -r "toBeOneOf" tests/ が何も返さないことを確認してください。許容値の集合を使うすべてのアサーションで、expect([...]).toContain(...) を使用します。
3. 仕込んだ脆弱性でゲートが失敗することを確認してください。 既知の脆弱性を含む依存関係を追加し、OSV-Scanner のステップを実行して、ジョブがゼロ以外の終了コードを返すことを確認します。その後、依存関係を削除してください。

---

完了条件

• コミット済みの owasp-coverage.md（またはそれを検証する CI ジョブ）が、OWASP 2025 のすべてのカテゴリを、少なくとも 1 つのタグ付きテスト、または根拠を記録した「軽減済み／受容済みリスク」の項目に対応付けていること。カテゴリが暗黙のうちに抜けていてはいけません。
• OSV-Scanner（または同等のツール）が CI で実行され、重大度が高またはクリティカルな脆弱性があるとジョブがゼロ以外の終了コードを返すこと。これは「検証」の仕込んだ脆弱性のチェックで確認します。
• Semgrep の p/owasp-top-ten が CI で実行され、メインブランチに未解決の検出結果がないこと（ESLint のセキュリティプラグインは、ゲートにしない補助的なシグナルとして実行してもかまいません）。
• ZAP のベースラインスキャンがステージング環境に対して実行され、毎回の実行でレポートが CI アーティファクトとしてアップロードされること（if: always()）。
• セキュリティ用 Playwright プロジェクト（--project=security）がステージング環境に対して終了コード 0 で終了し、OWASP Juice Shop に対して実行すると失敗が発生すること（アサーションが機能している証拠）。
• 認証／セッションの各エッジケースに合格するテストがあること：CSRF の拒否、期限切れトークンの拒否、alg:none の拒否、ログアウト時のセッション無効化、RBAC による権限昇格の防止。
• テストファイルに実際のシークレットがないこと（grep／TruffleHog で問題が検出されないこと）。

関連スキル

• ci-cd-integration — パイプラインのステージ接続とデプロイゲートの仕組みです。これらのステップを どのように 実行するかはそちらで、ここでは 何を 検証するかを扱います。
• compliance-testing — セキュリティ制御を規制（SOC 2、HIPAA、PCI、GDPR）に対応付けます。このスキルでは制御が機能することを検証し、そちらでは適切な制御が選ばれていることを検証します。
• ai-system-testing — 自社製品のLLM機能を扱います。OWASP LLM Top 10の詳細な対応を担当し、間接的なプロンプトインジェクション、インジェクション検出器、機密情報漏えいテスト、ジェイルブレイクのレッドチーミングを扱います。このスキルではCIゲート用にLLMのカテゴリを示し、そちらではエージェントを防御します。
• api-testing — 攻撃者モデルを用いない、REST／GraphQLの機能的な認証、入力、レート制限のテストです。シミュレーションする脅威がない場合はそちらを参照してください。
• shift-left-testing — シフトレフトの原則を支える開発・QAワークフロー、TDD、完了の定義を扱います。
• test-environments — セキュアなテスト環境の設定、シークレット管理、ネットワーク分離を扱います。
• database-testing — データベースレベルのデータ整合性とアクセス制御を扱います。

参考ファイル（references/ 内）

• owasp-tests.md — OWASP A01～A10（IDOR、SSRF、インジェクション、暗号化、セキュリティヘッダー、レート制限、サプライチェーンのSBOM／プロベナンス、例外的な条件）を対象とする、実行可能なPlaywrightコードと、許容ステータスセットのマッチャーに関する注記です。
• scanning-and-ci.md — ZAP、OSV-Scanner／Snyk、SemgrepとESLintのフラット設定によるSAST、シークレットスキャン、実行可能な依存関係ゲートを含む5層のCIパイプラインを扱います。
• auth-tests.md — A07向けのセッション、JWT（alg:none、有効期限）、RBACマトリクスのテストです。