application-security-testing について
Strix によるアプリケーションセキュリティ評価の計画を支援する導入ガイドです。資産ごとのテスト選択、検出結果の影響度に基づく統合、未検査範囲の報告を扱います。
主な機能
- 01資産の種類に応じたテスト選択
- 02コード、アプリ、API の評価計画
- 03検証済みの影響度による結果の整理
- 04未検査範囲とスキャン制限の記録
活用シーン
- 01複数のリポジトリや環境の評価計画
- 02コードレビュー後にステージングをテスト
- 03スキャン結果を統合した修正計画の作成
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/application-security-testingを入力して読み込まれたか確認します。
詳細
アプリケーションセキュリティテスト
対象がまだ単一の URL やリポジトリに絞られていない、「アプリケーションを安全にしてほしい」という依頼のためのエントリーポイントです。ここでの作業は、各資産に適したテストを選んで実行し、優先順位を付けた計画を 1 つ作成することです。すべてを最大限の深度で実行するわけではありません。
インストール、LLM のセットアップ、すべての CLI フラグ、マネージドクラウドの利用方法については、penetration-testing-with-strix スキルを参照してください。strix --version が失敗する場合は、まずそちらを読んでください。Docker も LLM キーも使わない実行では、同じバイナリからマネージドプラットフォームを利用できます。strix cloud login を実行し、続けて strix cloud scans start ... を実行してください（詳細は managed-pentesting-with-strix を参照）。
ユーザーが所有しているか、テストする権限を持つ資産だけをテストしてください。最初の実行前に許可を確認し、可能であれば本番環境よりステージング環境を優先してください。エージェントは実際のエクスプロイトペイロードを送信し、データを変更する可能性があるためです。
1. 資産を把握する
スキャンの前に、質問するかリポジトリから情報を確認し、回答を書き留めてください。
- ソース — リポジトリは 1 つですか、モノレポですか、それとも複数のサービスですか？使用している言語やフレームワークは何ですか？
- 実行環境 — ステージング環境はありますか？一般公開されている本番サイトはありますか？ローカルの開発サーバーのみですか？
- API — REST、GraphQL、gRPC のどれですか？OpenAPI または GraphQL のスキーマはありますか？
- 認証 — 異なるテナントに属するテストアカウントを 2 つ用意できますか？影響の大きい脆弱性の多くは、これらのアカウントを必要とします。
- 制約 — 対象外のパス、本番環境に触れてよいかどうか、予算、所要時間の上限。
ステージング環境がなく、本番環境にも触れられない場合は、早い段階でその旨を伝えてください。コードのみのレビューにも価値はありますが、実行中のアプリケーションに対する悪用可能性を証明することはできません。
2. 資産ごとに適切なテストを選ぶ
| 資産 | 使用するスキル |
|---|---|
| リポジトリまたは作業ツリー | find-security-vulnerabilities-in-code |
| 稼働中の Web アプリまたはステージングサイト | web-app-penetration-testing |
| REST／GraphQL／gRPC API | api-security-testing |
| OWASP のカテゴリに対応付けた評価 | owasp-top-10-testing |
| すべてのプルリクエストを対象とした継続的な実行 | ci-security-scanning-with-strix |
| Docker も LLM キーもない場合、または監査人が受け入れるレポートが必要な場合 | managed-pentesting-with-strix |
これらのスキルには、フラグ、認証情報の取り扱い、結果の読み方に関する詳細が記載されています。ここで手順を重複して記載しないでください。
初回評価の実施順序：
- コードをレビューします。最も低コストで実行でき、認可モデルを把握できます。
- 認証情報を使ってステージング環境をペネトレーションテストし、エージェントがソースのコンテキストを維持できるよう、リポジトリも 2 つ目の対象として渡します。
- CI スキャンを追加し、以降のリグレッションを手動で再テストしなくても検出できるようにします。
資産は一度に 1 つだけ実行し、次を開始する前に各レポートを確認してください。コードレビューで得られた知見により、ライブテストの精度が上がります。
3. 結果を 1 つの計画にまとめる
各実行の結果は strix_runs/<run>/ に保存されます。これらを 1 つのリストにまとめ、スキャナーの重大度ではなく、実証された影響に基づいて優先順位を付けてください。
- 認証なしで到達可能な、検証済みのエクスプロイト。
- 検証済みのテナント間アクセスまたは権限昇格の問題。
- 認証済みアカウントを必要とする、検証済みの問題。
- 未検証の所見（設定、依存関係、強化に関する指摘）—その旨を明記し、確認済みの脆弱性として提示しないでください。
重複を排除してください。同じ根本原因が、コードレビューとライブペネトレーションテストの両方で見つかることはよくあります。
4. テスト範囲を正直に伝える
テストしなかった対象を明確に伝えてください。ステージング環境がない資産、ブラックボックステストでは到達できないカテゴリ（ロギングとアラート、サプライチェーンの完全性、安全でない設計）、予算またはターン数の上限に達して完了しなかった実行が含まれます。各実行について、run.json のステータスとコストを --max-budget と照らし合わせて確認してください。途中で打ち切られたスキャンで結果が空でも、問題がないことを示すものではありません。
その後、fix-security-vulnerabilities-with-strix を使って修正してください。このスキルは各修正に対して Strix を再実行し、エクスプロイトが機能しなくなったことを確認します。