セキュリティチェックを自分たちで回したい、でも専門家を呼ぶほどの予算も時間もない——そんな状況で「AIが攻撃シナリオを自律生成するペネトレーションテストツール」という触れ込みの strix を見つけました。
リリース前のステージング環境に向けて実際に動かしてみたので、セットアップのつまずきどころから結果の読み方・限界まで、正直に書いておきます。
「すごいツールが出た」という紹介記事ではなく、「実務で使えるか」を判断するための一次情報として読んでもらえると幸いです。
strix とは何か——ルールベースとの構造的な違いから入る
usestrix/strix で公開されているオープンソースのペネトレーションテストツールです。
Apache-2.0 ライセンスで、Docker ベースで動き、OpenAI・Anthropic・Google などの LLM API キーを用意すれば動かせます。
従来の OWASP ZAP や Burp Suite と何が違うのか、というのがまず気になるところですよね。
ZAP や Burp Suite は、既知の攻撃パターンをルールとして持ち、それをリクエストとして送信して応答を検査する仕組みで動いています。
アクティブスキャン・パッシブスキャンを組み合わせて網羅的に当てていくアプローチで、枯れた技術として安定しています。
ただ、「ルールにない攻撃は見つけられない」という構造的な天井があります。
strix はそこが根本的に違います。
LLM がその場でアプリを観察し、攻撃シナリオを組み立てて実行する マルチエージェント構成 になっています。
リポジトリでは「Graph of Agents」と呼ばれているアーキテクチャで、偵察・攻撃・レポートをそれぞれ担うエージェントが並列で走ります。
見つけた脆弱性に対して PoC（実証コード）と修正案まで自動生成してくれるのが、従来ツールとの決定的な差です。
ただし、これは裏を返すと LLM の推論品質に結果が直結する ということでもあります。
使うモデルが賢ければ賢いほど検出の精度は上がりますし、API コストもそのまま跳ね上がります。
「無料で全部やってくれる」ではなく、「LLM の能力をペネトレーションテストに向けるためのフレームワーク」という理解が正確です。
この両面を最初に押さえておかないと、使い始めてから期待値のズレが生じます。
セットアップ——つまずきやすいポイントを先に潰す
前提として必要なのは Docker と、対応 LLM プロバイダの API キーです。
OpenAI・Anthropic・Google のほか、Vertex AI・Bedrock・Azure・ローカルモデルにも対応しています。
基本的な流れはこうなります。
# リポジトリをクローン
git clone https://github.com/usestrix/strix.git
cd strix
# API キーを環境変数に設定してからコンテナを起動
export OPENAI_API_KEY=sk-xxxxxxxxxxxxxxxxxxxx
# Anthropic を使う場合はこちら
# export ANTHROPIC_API_KEY=sk-ant-xxxxxxxxxxxxxxxxxxxx
docker-compose up -d --build
コンテナが起動したら、ブラウザからダッシュボードにアクセスできます（ポート番号はリポジトリの docker-compose.yml を確認してください）。
ここまで来れば準備完了です。
つまずきやすいのは API キーの渡し方 です。
docker-compose up の前に環境変数をエクスポートしておかないと、コンテナ内に渡らずにエラーになります。
.env ファイルを使う場合は docker-compose.yml 側で env_file の設定が必要なので、リポジトリの README を確認してください。
もう一つ、 モデル選択は最初から高性能なものを使わない のが現実的な進め方です。
まずは軽量・低コストなモデルで試してから、結果の質を見て上位モデルに切り替えていく順番がコストを抑えやすいです。
高性能モデルを最初から使うと、一回のスキャンで思いのほか API コストがかかることがあります。
実際に動かしてみた——コマンドと出力レポートの読み方
ターゲットの指定方法は大きく3パターンあります。
ローカルのコードリポジトリを直接渡すホワイトボックス、GitHub リポジトリの URL を渡すパターン、そしてデプロイ済みの URL を渡すブラックボックスです。
# ブラックボックス：デプロイ済み URL に対するスキャン
strix --target http://localhost:3000
# ホワイトボックス：ローカルのコードリポジトリを渡す
strix --target ./app-directory --scan-mode standard
# GitHub リポジトリを渡す
strix --target https://github.com/yourorg/yourapp
# --instruction で診断の焦点を絞る
strix --target http://staging.your-app.com \
--instruction "Focus on business logic flaws and IDOR vulnerabilities"
# CI/CD 組み込み用：non-interactive モード
strix --target http://staging.your-app.com -n
--instruction フラグが地味に便利で、「IDOR とビジネスロジック欠陥に絞る」のように診断の焦点を自然言語で指定できます。
スコープが広いアプリで全部やると時間とコストがかかるので、リリース前の特定機能だけ集中的に見たいときに使えます。
出力されるレポートは penetration_test_report.md（全体サマリ）と vulnerabilities.csv（脆弱性一覧）の2ファイルです。
なお、OWASP Juice Shop を対象にした実験では約30分で6件の脆弱性が検出されうち4件が CRITICAL と判定されたという報告があり（参考: furiousgreen.co）、スキャン時間とレポート構成のイメージとして参考になります。
レポートを読むときに大事なのは、 CVSSスコアだけで判断しないこと です。
strix は各脆弱性に対して PoC を生成しますが、その PoC が実際に自分の環境で再現できるかを必ず手で確認してください。
「CRITICAL と書いてあるから即対応」ではなく、「PoC が本当に通るか」を起点に優先度を判断するのが正しい読み方です。
non-interactive モード（-n フラグ）は CI/CD への組み込みを見据えた実行パターンで、脆弱性が見つかった場合に非ゼロの終了コードで終わります。
GitHub Actions のワークフローに組み込んで、ステージングデプロイ後に自動実行する使い方が現実的な落とし所です。
何が検出できて、何が検出できなかったか——誤検知と限界の正直な話
スキャンを走らせてまず驚いたのは、ビジネスロジックまわりの検出でした。
たとえば認証フローの途中で特定のパラメータを書き換えると別ユーザーのリソースにアクセスできてしまう、いわゆる IDOR 系の問題を、LLM がエンドポイントの応答を観察しながら自力でシナリオを組み立てて検出してきます。
ZAP のようなルールベースのツールでは「そのパターンを知っているか」が検出の前提になりますが、strix は「アプリの挙動を見て推論する」ので、既知のパターンに縛られない動き方をします。
この点は、使ってみて一番「なるほど」と感じたところです。
リポジトリに記載されている検出カテゴリと実際の動作を照らし合わせると、以下のあたりは機能していると感じました。
- SQL インジェクション（ログイン画面・検索フォームへの基本的な攻撃）
- 認証バイパス・JWT 攻撃・セッション固定
- ビジネスロジック欠陥（レースコンディション・支払いフローの改ざん・IDOR）
- API の認証不備・マスアサインメント
一方で、検出が難しいカテゴリも明確にあります。
- インフラ・クラウドの設定ミス（Supabase の RLS ミスコンフィグ・Firebase ルールの不備など「アプリの外側」の問題）
- ネットワーク層・クラウド設定層の問題全般
- 複数リクエストや状態変化を組み合わせた複合的な欠陥
- アプリ固有のビジネスルールを深く理解しないと気づけない脆弱性
インフラ層の問題は、アプリのコードやエンドポイントを観察して攻撃シナリオを組み立てる構造上、strix の視野の外になります。
ここは ZAP でも同様に苦手な領域なので、別途インフラ側の確認が必要です。
誤検知については、正直なところ無視できない量が出ます。
LLM は「それっぽい攻撃シナリオ」を生成するのが得意ですが、アプリの実装を完全に理解しているわけではありません。
たとえば、エラーレスポンスの形式から「SQLi の可能性がある」と判断したものの、実際にはパラメータがサニタイズされていて問題なかった、というケースが出てきます。
PoC の再現確認なしに結果をそのまま信じてはいけない というのが、使ってみて一番強く感じたことです。
レポートに書いてある内容を起点に、自分のアプリの文脈でリスクの重みを付け直す作業が必ず必要になります。
strix はあくまで「候補を洗い出すツール」であって、「判定を下すツール」ではありません。
使っていいケース・使ってはいけないケース——法的リスクと現実的な落とし所
最初に明確にしておきます。
自分が管理権限を持っていない環境への実行は、不正アクセス禁止法に抵触します。
ペネトレーションテストは、管理者または利用者の承諾を得た範囲内での実施に限り適法です。
「試しに有名サービスに向けて動かしてみた」は、どれだけ善意でも違法行為になります。
ステージング環境・ローカル環境・自分が所有するテスト用アプリに対してのみ使うことが大前提です。
その前提の上で、strix が向いているユースケースはこうです。
リリース前のステージング環境に対する 一次スクリーニング として使うのが一番しっくりきます。
専門家によるフルペネトレーションテストほどの網羅性はありませんが、明らかな穴を短時間で洗い出せるのは実務的に価値があります。
CI/CD の non-interactive モードに組み込んで、ステージングデプロイのたびに自動チェックを走らせる使い方も現実的です。
逆に向いていないのは、本番環境への直接実行と、専門家によるフルペネトレーションテストの代替として使うことです。
本番環境に向けて動かすと、スキャン中の攻撃的なリクエストがデータを壊したりサービスに影響を与えたりするリスクがあります。
コンプライアンス要件を満たすための診断や、重要なシステムのリリース判断に使う場合は、strix の結果だけでは根拠として不十分です。
今回の実験を通じて見えてきた現実的な落とし所は、ZAP や Burp Suite と 並列で使う二段構え です。
strix でビジネスロジック欠陥や認証まわりの候補を洗い出し、ZAP で OWASP Top 10 を網羅的に補完する形です。
strix が拾った候補を人間が PoC で確認し、ZAP の結果と突き合わせてから対応優先度を決める——このフローが現実解として見えてきました。
「strix だけで全部できる」という期待値で使い始めると必ずギャップが出ます。
でも「一次スクリーニングの自動化」という位置づけで組み込むなら、十分に実務で使えるツールです。
LLM の推論が年々良くなっていることを考えると、半年後・一年後にはまた評価が変わりそうだとも思っています。
株式会社ホコサキは山口県宇部を拠点に、Web制作・業務システム開発・AI活用支援を手がけています。
strix のような新しいツールの評価・導入検討から、セキュリティを考慮した開発フローの整備まで、実務ベースでご相談に乗れます。
気になることがあれば お問い合わせ からどうぞ。