«У тебя агент ронял прод?» Что ИИ-пентест умеет в 2026 году и где он до сих пор плох
Агент на пентесте сам решил перезапустить базу данных, потому что она ему мешала. Он рассчитывал, что сервис поднимется, результат не проверил и пошёл дальше. База не поднялась. Это был мой стенд и моя база, поэтому история закончилась смешно. Александр Кельчин, CTO и CISO Medici Lab, ронял агентами демостенды заказчиков, причём по договорённости.
Об этом и о том, где ИИ в пентесте реально помогает, мы проговорили почти час. Полная запись есть на YouTube, аудиоверсия — на подкаст-площадках. В статье я собрал практическую часть: что агенты умеют на боевой инфраструктуре, почему они лучше подтверждают уязвимости, чем находят, и как не положить заказчику прод. Цитаты Александра слегка отредактированы под письменную речь.
Автопентест старше LLM/агентского пентеста лет на двадцать
Автоматизированный пентест — старый класс продуктов. Для меня первым российским был XSpider. В мире к этому классу относили автоматизацию эксплуатации вокруг Metasploit, которая подбирала и отправляла полезные нагрузки. Сейчас это направление вендоры называют по-разному: непрерывный пентест (CPT), CTEM, управление уязвимостями. По сути это связка двух вещей. Первая — управление поверхностью атаки, то есть инвентаризация внешнего и внутреннего контура. Вторая — управление уязвимостями: просканировали периметр, сопоставили с базой уязвимостей, получили список того, что чинить.
Первая волна LLM добавила в эти продукты суммаризацию. Руководитель открывает дашборд и вместо графиков, которые всем надоели за двадцать лет, видит короткую выжимку о самых опасных уязвимостях на контуре и может задавать по ней вопросы. Агенты поменяли картину сильнее: у модели появились руки в виде вызова инструментов, а MCP-серверы для них начали появляться в большом количестве.
Где агент уже экономит дни
Первое — объёмы данных, которые человек читать не будет. Александр много работает с сетями, а в вебе, по его словам, разбирается «так себе». Однажды он начал скармливать агенту сетевой трафик целиком: ARP, DNS, SSL-сертификаты, чтобы модель проверяла, как подписываются и что отдают узлы.
Руками смотреть на одинаковые буковки и циферки ARP — это просто себя не уважать. Он мне дал понятно читаемый вывод.
Второе — связка агента с привычными инструментами. Когда MCP ещё не было, Александр писал свою обёртку вокруг Burp Suite и передавал агенту состояние через файлы. Сейчас у PortSwigger есть официальный MCP-сервер для Burp.
Ты открываешь Burp Suite, у него есть MCP, который отлично работает с твоим агентом, и понимаешь, что тебе не нужно больше это делать руками. Восхитительное ощущение.
У меня с Burp первая встреча с ИИ была хуже. Ранний Burp AI анализировал часть трафика и предлагал запросы, которые отправлять приходилось самому. Бесплатных кредитов хватило примерно на три часа работы. В скоупе на две тысячи хостов ассистент, который только советует, бесполезен. Агент через MCP закрыл эту разницу.
Третье — специализированные модели. OpenAI открыла проверенным защитникам доступ к моделям для кибербезопасности через программу Trusted Access for Cyber. Александр получил доступ через компанию и пробовал на них сигнатурный анализ кода. Свою обвязку вокруг такой модели он в итоге написал сам и говорит, что она нравится ему больше готовых: когда делаешь сам, понимаешь, что внутри.
Подтверждает хорошо, находит плохо
Александр начинал с открытых агентов Strix и PentAGI. В небольшом контексте на несколько тысяч токенов они неплохо понимали, что не так, но на боевой инфраструктуре работали плохо. Около трёх лет назад ему было быстрее и надёжнее смотреть руками.
Они отлично умеют понимать, уязвимость это или нет, но найти её с нуля оказались не очень эффективными. Под капотом у всех стандартная модель, которая не предназначена для поиска уязвимостей.
Хорошо это видно на XBOW. Летом 2025 года он вышел на первое место лидерборда HackerOne по итогам второго квартала и отправил около 1 060 отчётов. Компания пишет, что все находки были полностью автоматическими, но перед отправкой их просматривала команда безопасности, как требуют правила HackerOne для автоматизированных инструментов. Подтверждение в XBOW построено на «валидаторах». Иногда это LLM, иногда программная проверка. Для XSS, например, headless-браузер заходит на страницу и проверяет, что полезная нагрузка действительно выполнилась.
Александр покупал коммерческую версию. По его словам, это нормальный enterprise-продукт за несколько тысяч долларов, и этап ручной перепроверки виден в самом продукте. Первый пентест своей инфраструктуры этим инструментом произвёл на него сильное впечатление, особенно по сравнению с открытыми агентами годичной давности. Вывод при этом тот же, что и для AI SOC: проверку гипотезы ИИ автоматизирует хорошо, а поиск с нуля упирается в модель общего назначения.
У меня есть объяснение, почему с внутренним пентестом так. У разработчиков моделей нет данных: отчёты по внутренней инфраструктуре закрыты NDA, и пентестеры не отдают их в обучение. Без данных модель справляется хуже человека, и специалисты разумно продолжают работать руками. Чтобы стало лучше, кто-то должен этими данными поделиться, а это нарушение NDA.
«Нет, я ронял инфру»
«У тебя агент ронял инфру?» — спросил Александр. Я ответил честно: инфру клал я, а не агент. Если пентестер ни разу не ломал инфру, он ещё не дорос до сеньора.
С агентом у меня был один показательный случай. Он посчитал, что база данных ему мешает, и решил её перезапустить. По его расчёту сервис должен был подняться сам, но не поднялся, а агент этого не проверил и продолжил работу. Удалений не было ни разу: ни DROP DATABASE, ни rm -rf. Это было на моём стенде. У заказчиков я ограничиваю агента командами echo, cat, cp и pwd.
Александр работает иначе. Если заказчик говорит, что готов ко всему, он уточняет, действительно ли ко всему. Обычно речь о демостенде, потерю которого заказчик заранее принимает, и на таких стендах агенты у него инфраструктуру роняли.
Из этих двух историй получается простой набор правил:
Список разрешённых команд вместо списка запрещённых. Агент найдёт способ сделать опасное действие командой, которую вы не догадались запретить.
Деструктивное и перезапускающее — только с подтверждением человека. Мой случай показывает, что «перезапустить» для агента звучит безопасно, хотя может положить сервис.
Проверка результата после каждого изменяющего действия. Агент не знает, что сервис не поднялся, пока не проверит его явно.
Деструктивные проверки — на стенде, потерю которого заказчик принял письменно.
Агент сам по себе — новая поверхность атаки
Пентестерский агент читает чужой контент: ответы сервера, страницы, логи, баннеры. Любой из этих текстов может оказаться prompt injection, и агент с доступом к инструментам выполнит его в вашем контуре. Защиту модели изнутри, гардами и дообучением, Александр считает малоэффективной. В своём продукте для защиты LLM он строит защиту вокруг модели.
Направление задаёт работа CaMeL от Google DeepMind и ETH Zurich. Она развивает паттерн Dual LLM Simon Willison. Привилегированная модель строит план только по доверенному запросу, а недоверенные данные обрабатывает изолированная модель, которая не может менять ход программы. Политики проверяют каждый вызов инструмента. В AgentDojo CaMeL решил 77% задач с доказуемой защитой против 84% у системы без защиты.
Для закрытых моделей Александр видит один вариант: контейнер, в котором агенту обрезаны лишние вызовы. То, что продают под названием «LLM firewall», по сути должно быть DLP, а в идеале ещё и работать на уровне EDR. Для пентестерского агента это означает изолированный раннер, явный список разрешённых действий и контроль того, какие данные покидают стенд.
Сколько это стоит и что будет с ценой
По словам Александра, корпоративные лицензии на коммерческие автопентесты стоят тысячи долларов, а ручной пентест для формального соответствия у зарубежных заказчиков обходится в среднем в 15 тысяч долларов. На международном рынке он встретил платформу, которая предлагает аудит по подписке: заказчик сам проводит пентест на их платформе, их ИИ оценивает качество работы, и за 200 долларов выдаётся заключение. Нам с ним эта идея показалась странной: это лишний канал утечки сведений о ваших уязвимостях.
Про рынок у нас мы с Александром разошлись. Я считаю, что внешний пентест у нас уже стоит как пачка сухариков, а внутренний держится в цене только потому, что у моделей нет данных по внутренней инфраструктуре. Александр согласился про внешний и возразил про физический пентест, который стоит совсем других денег.
Мой прогноз осторожнее, чем заголовки про «ИИ-пентестер заменит людей». Агент уже снимает с пентестера рутину: трафик, повторяющиеся запросы, подтверждение типовых находок. Поиск нестандартных цепочек и ответственность за то, что агент сделал в чужой инфраструктуре, остаются за человеком.
А теперь вопрос к вам. Давали ли вы агенту доступ к боевому или стендовому контуру заказчика, и что он успел сломать? Какие ограничения вы ставите агенту, кроме списка разрешённых команд? Самые интересные случаи соберу во вторую часть.
Mentions
@yousefrol جرب هذا مع كذا مودل ، usestrix/strix
«У тебя агент ронял прод?» Что ИИ-пентест умеет в 2026 году и где он до сих пор плох Агент на пентесте сам решил перезапустить базу данных, потому что она ему мешала. Он рассчитывал, что сервис поднимется, результат не проверил и пошёл дальше. База не поднялась. Это был мой стенд и моя база, поэтому история закончилась смешно. Александр Кельчин, CTO и CISO Medici Lab, ронял агентами демостенды заказчиков, причём по договорённости. Об этом и о том, где ИИ в пентесте реально помогает, мы проговорили почти час. Полная запись есть на YouTube, аудиоверсия — на подкаст-площадках. В статье я собрал практическую часть: что агенты умеют на боевой инфраструктуре, почему они лучше подтверждают уязвимости, чем находят, и как не положить заказчику прод. Цитаты Александра слегка отредактированы под письменную речь. Автопентест старше LLM/агентского пентеста лет на двадцать Автоматизированный пентест — старый класс продуктов. Для меня первым российским был XSpider. В мире к этому классу относили автоматизацию эксплуатации вокруг Metasploit, которая подбирала и отправляла полезные нагрузки. Сейчас это направление вендоры называют по-разному: непрерывный пентест (CPT), CTEM, управление уязвимостями. По сути это связка двух вещей. Первая — управление поверхностью атаки, то есть инвентаризация внешнего и внутреннего контура. Вторая — управление уязвимостями: просканировали периметр, сопоставили с базой уязвимостей, получили список того, что чинить. Первая волна LLM добавила в эти продукты суммаризацию. Руководитель открывает дашборд и вместо графиков, которые всем надоели за двадцать лет, видит короткую выжимку о самых опасных уязвимостях на контуре и может задавать по ней вопросы. Агенты поменяли картину сильнее: у модели появились руки в виде вызова инструментов, а MCP-серверы для них начали появляться в большом количестве. Где агент уже экономит дни Первое — объёмы данных, которые человек читать не будет. Александр много работает с сетями, а в вебе, по его словам, разбирается «так себе». Однажды он начал скармливать агенту сетевой трафик целиком: ARP, DNS, SSL-сертификаты, чтобы модель проверяла, как подписываются и что отдают узлы. Руками смотреть на одинаковые буковки и циферки ARP — это просто себя не уважать. Он мне дал понятно читаемый вывод. Второе — связка агента с привычными инструментами. Когда MCP ещё не было, Александр писал свою обёртку вокруг Burp Suite и передавал агенту состояние через файлы. Сейчас у PortSwigger есть официальный MCP-сервер для Burp. Ты открываешь Burp Suite, у него есть MCP, который отлично работает с твоим агентом, и понимаешь, что тебе не нужно больше это делать руками. Восхитительное ощущение. У меня с Burp первая встреча с ИИ была хуже. Ранний Burp AI анализировал часть трафика и предлагал запросы, которые отправлять приходилось самому. Бесплатных кредитов хватило примерно на три часа работы. В скоупе на две тысячи хостов ассистент, который только советует, бесполезен. Агент через MCP закрыл эту разницу. Третье — специализированные модели. OpenAI открыла проверенным защитникам доступ к моделям для кибербезопасности через программу Trusted Access for Cyber. Александр получил доступ через компанию и пробовал на них сигнатурный анализ кода. Свою обвязку вокруг такой модели он в итоге написал сам и говорит, что она нравится ему больше готовых: когда делаешь сам, понимаешь, что внутри. Подтверждает хорошо, находит плохо Александр начинал с открытых агентов Strix и PentAGI. В небольшом контексте на несколько тысяч токенов они неплохо понимали, что не так, но на боевой инфраструктуре работали плохо. Около трёх лет назад ему было быстрее и надёжнее смотреть руками. Они отлично умеют понимать, уязвимость это или нет, но найти её с нуля оказались не очень эффективными. Под капотом у всех стандартная модель, которая не предназначена для поиска уязвимостей. Хорошо это видно на XBOW. Летом 2025 года он вышел на первое место лидерборда HackerOne по итогам второго квартала и отправил около 1 060 отчётов. Компания пишет, что все находки были полностью автоматическими, но перед отправкой их просматривала команда безопасности, как требуют правила HackerOne для автоматизированных инструментов. Подтверждение в XBOW построено на «валидаторах». Иногда это LLM, иногда программная проверка. Для XSS, например, headless-браузер заходит на страницу и проверяет, что полезная нагрузка действительно выполнилась. Александр покупал коммерческую версию. По его словам, это нормальный enterprise-продукт за несколько тысяч долларов, и этап ручной перепроверки виден в самом продукте. Первый пентест своей инфраструктуры этим инструментом произвёл на него сильное впечатление, особенно по сравнению с открытыми агентами годичной давности. Вывод при этом тот же, что и для AI SOC: проверку гипотезы ИИ автоматизирует хорошо, а поиск с нуля упирается в модель общего назначения. У меня есть объяснение, почему с внутренним пентестом так. У разработчиков моделей нет данных: отчёты по внутренней инфраструктуре закрыты NDA, и пентестеры не отдают их в обучение. Без данных модель справляется хуже человека, и специалисты разумно продолжают работать руками. Чтобы стало лучше, кто-то должен этими данными поделиться, а это нарушение NDA. «Нет, я ронял инфру» «У тебя агент ронял инфру?» — спросил Александр. Я ответил честно: инфру клал я, а не агент. Если пентестер ни разу не ломал инфру, он ещё не дорос до сеньора. С агентом у меня был один показательный случай. Он посчитал, что база данных ему мешает, и решил её перезапустить. По его расчёту сервис должен был подняться сам, но не поднялся, а агент этого не проверил и продолжил работу. Удалений не было ни разу: ни DROP DATABASE, ни rm -rf. Это было на моём стенде. У заказчиков я ограничиваю агента командами echo, cat, cp и pwd. Александр работает иначе. Если заказчик говорит, что готов ко всему, он уточняет, действительно ли ко всему. Обычно речь о демостенде, потерю которого заказчик заранее принимает, и на таких стендах агенты у него инфраструктуру роняли. Из этих двух историй получается простой набор правил: Список разрешённых команд вместо списка запрещённых. Агент найдёт способ сделать опасное действие командой, которую вы не догадались запретить. Деструктивное и перезапускающее — только с подтверждением человека. Мой случай показывает, что «перезапустить» для агента звучит безопасно, хотя может положить сервис. Проверка результата после каждого изменяющего действия. Агент не знает, что сервис не поднялся, пока не проверит его явно. Деструктивные проверки — на стенде, потерю которого заказчик принял письменно. Агент сам по себе — новая поверхность атаки Пентестерский агент читает чужой контент: ответы сервера, страницы, логи, баннеры. Любой из этих текстов может оказаться prompt injection, и агент с доступом к инструментам выполнит его в вашем контуре. Защиту модели изнутри, гардами и дообучением, Александр считает малоэффективной. В своём продукте для защиты LLM он строит защиту вокруг модели. Направление задаёт работа CaMeL от Google DeepMind и ETH Zurich. Она развивает паттерн Dual LLM Simon Willison. Привилегированная модель строит план только по доверенному запросу, а недоверенные данные обрабатывает изолированная модель, которая не может менять ход программы. Политики проверяют каждый вызов инструмента. В AgentDojo CaMeL решил 77% задач с доказуемой защитой против 84% у системы без защиты. Для закрытых моделей Александр видит один вариант: контейнер, в котором агенту обрезаны лишние вызовы. То, что продают под названием «LLM firewall», по сути должно быть DLP, а в идеале ещё и работать на уровне EDR. Для пентестерского агента это означает изолированный раннер, явный список разрешённых действий и контроль того, какие данные покидают стенд. Сколько это стоит и что будет с ценой По словам Александра, корпоративные лицензии на коммерческие автопентесты стоят тысячи долларов, а ручной пентест для формального соответствия у зарубежных заказчиков обходится в среднем в 15 тысяч долларов. На международном рынке он встретил платформу, которая предлагает аудит по подписке: заказчик сам проводит пентест на их платформе, их ИИ оценивает качество работы, и за 200 долларов выдаётся заключение. Нам с ним эта идея показалась странной: это лишний канал утечки сведений о ваших уязвимостях. Про рынок у нас мы с Александром разошлись. Я считаю, что внешний пентест у нас уже стоит как пачка сухариков, а внутренний держится в цене только потому, что у моделей нет данных по внутренней инфраструктуре. Александр согласился про внешний и возразил про физический пентест, который стоит совсем других денег. Мой прогноз осторожнее, чем заголовки про «ИИ-пентестер заменит людей». Агент уже снимает с пентестера рутину: трафик, повторяющиеся запросы, подтверждение типовых находок. Поиск нестандартных цепочек и ответственность за то, что агент сделал в чужой инфраструктуре, остаются за человеком. А теперь вопрос к вам. Давали ли вы агенту доступ к боевому или стендовому контуру заказчика, и что он успел сломать? Какие ограничения вы ставите агенту, кроме списка разрешённых команд? Самые интересные случаи соберу во вторую часть.
I Checked All 3 GitHub Repos 3 GitHub repos: Strix, Alibaba Page Agent, or Meetily: what is the catch? MOSTLY TRUE: Strix routes its automated pipeline scans through an app service. Which one would you deploy first? Made with an AI avatar of me. usestrix/strix mohammad-200-ai/alibaba-page-agent Zackriya-Solutions/meetily #factchecking #github #opensource #aiagents #shorts #ai
After LiteLLM's backdoor, we open-sourced an OS-level package firewall usestrix/firewall (news.ycombinator.com)
After LiteLLM's backdoor, we open-sourced an OS-level package firewall
Strix × Ollama で自分のサイトの穴を AI に探させる この記事でやること Strix は Apache 2.0 で公開されている AI ペネトレーションテストツールです。「自律型の AI ハッカー」が実際にコードを動かし、脆弱性を見つけ、動く実証コード（PoC）まで作って検証してくれます。静的解析ツールのように「怪しい行」を並べるだけで終わらず、本当に悪用できるかまで踏み込むのが特徴です。 通常はクラウドの大規模モデルに API キーをつないで使いますが、この記事では Ollama + ローカルモデル で動かす構成をまとめます。コードと LLM 推論を外部クラウドに送らずに検査できます（Web 検索などのツールが動くときは、その通信だけは別途発生します）。 そのうえで、 Strix で 自分のサイトのどんな穴を探せるのか 検査を回すと どんな結果が出てくるのか その結果から どう対策するのか までを一通り説明します。 ! Strix は実際に攻撃コードを実行します。自分が所有・管理しているサイトやコード、または明示的に許可を得た対象にだけ使ってください。他人のサイトへの無断スキャンは違法になり得ます。 1. 必要なもの macOS / Linux / Windows Docker（Docker Desktop 推奨。Strix は検査対象をコンテナ内で動かします） Ollama（ローカル LLM ランタイム） uv（Strix の実行に使用） 2. Ollama のインストールとモデル取得 macOS brew install ollama ollama --version ollama pull qwen3-coder-next:latest Linux curl -fsSL ollama.com | sh ollama pull qwen3-coder-next:latest Windows Ollama for Windows をインストールし、PowerShell で: ollama pull qwen3-coder-next:latest ダウンロード後、サーバーが動いているか確認します。 ollama list curl localhost Strix 向けの Ollama 設定（ここを外すと無言で失敗する） Strix は巨大なシステムプロンプトと多数のツール定義（tool schema）をモデルに渡し、モデルが返す ツール呼び出し（tool call） を使って検査を進めます。ここが噛み合わないと、スキャンは「エラーも出さずに何も見つけない」で終わります。実行前に次を必ず設定してください。 ツール呼び出しに対応したモデル／テンプレートを使う。 新しめの Ollama は、テンプレートがツール非対応だと tools param requires --jinja flag で弾きます。 推論系モデル（qwen3 系など）は thinking を切る。 thinking を残すと、ツール呼び出しが構造化された tool_calls ではなく本文（content）側に漏れ、Strix が認識できません。Modelfile やパラメータで think: false にするか、非 thinking の派生モデルを使います。 num_ctx を 16k〜32k 以上に上げる。 Ollama の既定コンテキストは小さく、ツール定義がプロンプトから溢れて切り捨てられると、モデルは正しい呼び出しを出さなくなります。 ! 怖いのは、短いテスト用プロンプトだと正常に見えるのに、本番のスキャンだけ失敗することです（num_ctx 不足やツール定義の切り捨てが原因）。「動作確認は通ったのに検出結果が 0 件」という場合、まずこの設定を疑ってください。 例（Modelfile でコンテキストと thinking を固定する）: cat > Modelfile <<'EOF' FROM qwen3-coder-next:latest PARAMETER num_ctx 32768 EOF ollama create qwen3-coder-next-strix -f Modelfile 以降、STRIX_LLM を ollama/qwen3-coder-next-strix:latest に向ける 3. Docker の確認 Strix 本体は Ollama のモデルを使いますが、検査対象のアプリやツールは Docker コンテナで動かします。 docker info エラーが出る場合は Docker Desktop を起動 open -a Docker # macOS 4. 環境変数で Ollama を指定 ~/.zshrc または ~/.bashrc に追記します。 Strix に Ollama のローカルモデルを使わせる export STRIX_LLM="ollama/qwen3-coder-next:latest" export LLM_API_BASE="localhost" 反映と確認: source ~/.zshrc # または source ~/.bashrc echo $STRIX_LLM echo $LLM_API_BASE 5. Strix のインストール cd ~/ss git clone usestrix/strix cd strix 依存関係 uv sync --no-dev 結果ビュアー（TUI）のビルド make tui-build 動作確認 uv run strix --help 6. Strix は自分のサイトの「どんな穴」を探せるのか Strix は、人間のペンテスターと同じ流れ（偵察 → 攻撃 → 検証）を自律的に回します。手元の構成で使える主な能力は次のとおりです。 検査できる対象（target） --target には複数の形を渡せます。自分のサイトを色々な角度から当てられます。 対象の種類 指定例 ローカルのソースコード --target ./ownplate 動いている Web アプリ --target staging.example.com GitHub リポジトリ --target you/repo API 仕様 --target ./openapi.yaml / --target ./collection.postman_collection.json ドメイン / IP --target example.com / --target 192.168.1.42 コードと動作中アプリを 同時に 渡すこともできます（ソースを読んで当たりをつけ、実アプリで悪用を試す、という人間に近い動き）。 uv run strix \ --target ./ownplate \ --target staging.ownplate.example \ --instruction "Firebase を使った注文サイト。認証と注文データのアクセス制御を重点的に" 探せる脆弱性の種類 Strix は代表的な Web 脆弱性を一通りカバーします（PoC で悪用を実証するものを含む）。 アクセス制御の不備 / IDOR — 他人の注文・ユーザー情報を ID 書き換えで覗けるか 認証・認可の欠陥 — ログインを飛ばせるか、権限昇格できるか XSS（格納型・反射型） SQL インジェクション / NoSQL インジェクション SSRF（サーバーを踏み台に内部へアクセス） CSRF XXE RCE（リモートコード実行） SSTI（テンプレートインジェクション） パストラバーサル 設定・シークレットの漏れ（Firebase ルールの緩さ、公開された鍵など） 使い方のバリエーション 偵察重視の軽いスキャン（CI 向け） uv run strix --target ./ownplate --scan-mode quick -n じっくり深く（デフォルト） uv run strix --target ./ownplate --scan-mode deep 変更差分だけを検査（PR レビュー用） uv run strix --target ./ownplate --scope-mode diff --diff-base origin/main 予算と手数の上限を切る uv run strix --target ./ownplate --max-budget-usd 5 --max-turns 60 -n（--non-interactive）を付けると TUI を出さずに実行し、完了で終了します。CI やバッチ実行向けです。 7. 実行してみる cd ~/ss/strix uv run strix \ -t ~/ss/ownplate \ -n \ --instruction "Firebaseプロジェクトのセキュリティチェックを実施してください" 実行が終わると、結果は ./strix_runs/<run 名>/ に保存されます（例: strix_runs/ownplate_3b40/）。 8. どんな結果が出てくるか 1 回の run で、次のファイルが strix_runs/<run 名>/ に生成されます。 ファイル 中身 penetration_test_report.md 人が読むレポート（要約・手法・分析・推奨） findings.sarif 機械可読の検出結果（GitHub Code Scanning に取り込める SARIF 形式） vulnerabilities.json 検出した脆弱性の一覧（ビューアーが読む。検出結果があるときに生成） coverage.json 何を検査し、どこに穴（gap）が残ったかの記録 run.json run の全メタデータ strix.log 実行ログ 1 件 1 件の検出結果（finding）の形 脆弱性が見つかると、Strix は単なる警告ではなく、次を揃えた 1 件のレポートとして記録します。 severity（深刻度）: CVSS v3 の内訳から算出され、critical / high / medium / low / info に分類 confidence（確信度）: high / medium / low PoC: 動的に見つかった脆弱性では、実際に悪用する poc_script_code（スクリプト／ペイロード）と証拠（evidence）が必須。これらが無いと登録されない（依存ライブラリの CVE など別種の検出結果は別経路で扱われます） fix_effort（修正コスト）: trivial / low / medium / high 深刻度を上下させうる条件や、確信度の根拠 この「動的な脆弱性は PoC が無ければ登録しない」という設計のおかげで、静的解析にありがちな大量の誤検知に埋もれずに済みます。 「何も出なかった」ときの読み方 実際に ownplate の コードだけ を検査した実行例（軽量なローカルモデル llama3.1:8b を使用）では、レポートは「重大な問題なし」で終わり、findings.sarif の results は空、coverage.json は次のようになっていました。 "summary": { "surfaces_reviewed": 0, "findings_filed": 0, "gaps": 1 }, "gaps": [ { "kind": "agent_recorded_no_coverage", "detail": "Root Agent ran ... without recording any coverage." } ] ここで大事なのは、「検出結果 0 件」＝「安全」ではないということです。surfaces_reviewed: 0 と gaps: 1 は「検査面をほとんど踏めていない（穴が残っている）」というサインです。ローカルモデルで手数や探索が足りない、対象の起動まで届いていない、あるいは ツール呼び出しが成立していない（§2 の num_ctx・thinking 設定） といった場合にこうなります。 結果を受け取ったら、 coverage.json の gaps と surfaces_reviewed を必ず確認する 0 件なら --scan-mode deep に上げ、--instruction で検査してほしい箇所を具体的に指示し、動作中アプリの URL も --target に足して 再実行 する という読み方・回し方をします。 9. 結果からどう対策するか 検出結果が出た場合 深刻度と修正コストで優先順位を付け、種類ごとに対処します。 見つかった穴 典型的な対策 IDOR / アクセス制御不備 サーバー側で所有者チェック。Firebase なら Security Rules で request.auth.uid と所有者を照合 認証・認可の欠陥 重要操作はサーバー側で再検証。クライアント判定に依存しない XSS 出力エスケープ、v-html を避ける、CSP の導入 SQLi / NoSQLi パラメータ化クエリ、入力バリデーション SSRF 外向きリクエストの宛先を許可リスト化、内部アドレスを拒否 CSRF トークン検証、SameSite クッキー シークレット漏れ 鍵をコードから除去しローテーション、環境変数へ Strix は各 finding に修正の方向性（remediation）と PoC を付けてくれるので、まず PoC を自分で再現して本物だと確認 → 修正 → 同じ PoC が通らなくなるか再検証、という流れが取れます。 修正したら差分だけ再検査する 修正後は全体を回し直さなくても、変更部分だけを当てられます。 uv run strix --target ./ownplate --scope-mode diff --diff-base origin/main CI に組み込んで「入れない」ようにする --fail-on を付けると、指定した深刻度以上の検出結果が出たとき Strix が終了コード 2 を返します。CI はこれを失敗として扱うので、PR ごとに差分を検査し、危険なコードが本番に入る前に止められます。 uv run strix \ --target ./ownplate \ --scope-mode diff --diff-base origin/main \ --scan-mode quick \ -n \ --fail-on high findings.sarif を GitHub Code Scanning にアップロードすれば、検出結果を PR 上の注釈として表示できます。 10. 結果を共有する ビュアーで確認 uv run strix view # 最新の run を開く uv run strix view ownplate_3b40 PDF レポートを生成 cd ~/ss/llm/strix uv run scripts/generate_pdf_report.py \ ~/ss/llm/strix/strix_runs/ownplate_3b40 \ ~/ss/llm/strix/strix_runs/ownplate_3b40/report.pdf 11. トラブルシューティング "Ollama connection refused" curl localhost # 応答がなければ未起動 ollama serve "Docker not available" open -a Docker # macOS docker info "Model not found" ollama list ollama pull qwen3-coder-next:latest 検出結果が 0 件で gaps だけ出る coverage.json の surfaces_reviewed が 0 なら検査が届いていない まず §2 の Ollama 設定（num_ctx 16k〜32k、thinking オフ、ツール対応テンプレート）を確認する — ツール呼び出しが成立しないと、この症状が最も起きやすい --scan-mode deep に上げる、--max-turns を増やす、--instruction を具体化する 動作中アプリの URL を --target に追加する ローカルモデルで探索が浅い場合は、より大きなモデルや（許可があれば）クラウドの API を併用する 推奨設定まとめ 項目 設定 モデル ollama/qwen3-coder-next:latest API Base localhost スキャンモード 日常は standard、本格検査は deep、CI は quick スコープ PR レビューは --scope-mode diff --diff-base origin/main CI ゲート --fail-on high（必要に応じて critical） 関連リンク Strix GitHub Strix Docs Ollama Docs
1) AI hackers attack you first Strix sends a team of AI agents at your app to break in like real hackers, then shows you how to fix every hole. 71,000 stars. usestrix/strix
It’s time to turn the AI security tools against your webapp repo and fix the issues now. This open source project launches 7 subagents that check for a number of issues in dependencies, XSS, CSRF, etc and makes it easy to prompt fixes and create PRs: usestrix/strix
Quick reminder, you can always use usestrix/strix to find and fix your app’s vulnerabilities for free
Strix: Open-source AI penetration testing tool to find and fix your app's vulnerabilities (70k stars) What it does All text below is quoted directly from the project README. >Strix are autonomous AI penetration testing agents that act just like real hackers - they run your code dynamically, find vulnerabilities, and validate them through actual proofs-of-concept. Key Capabilities: - Full pentesting toolkit - reconnaissance, exploitation, and validation out of the box - Multi-agent orchestration - teams of AI pentesters that collaborate and scale - Real exploit validation - working PoCs, not false positives like legacy vulnerability scanners - Developer-first CLI - actionable findings with remediation guidance - Auto-fix & reporting - generate patches and compliance-ready pentest reports >Install Strix: curl -sSL https://strix.ai/install | bash Repository usestrix/strix Repository stats |Metric|Value| |:-|:-| |Stars|70,189| |Forks|7,832| |Last release|v1.7.0 (2026-10-05)| |Languages|Python 77.8%, Go 11.3%, TypeScript 8.5%| |Contributors|78| |AI contributor accounts (Claude / Codex / Cursor / Copilot)|claude: 121| |AI co-authored commits|Claude: 124| Main contributor |Field|Value| |:-|:-| |Name|Ahmed Allam| |GitHub|@0xallam| |Commits to this repo|695 (top contributor)| |Bio|Building @usestrix - Applied Data Scientist @ Microsoft| |Company / Location|@usestrix / San Francisco| |X / Twitter|@0xallam| |Followers|600| |Public repos|40| |On GitHub since|2019-04-23| ────────────────────────────── 📌 How many great GitHub repos have you discovered and completely forgotten about? Don't let another useful tool disappear into your Reddit feed. Get the community's best repos, organized by category, plus key takeaways from real developer discussions, delivered to your inbox twice a week. 📬 Never lose track of great repos again. Subscribe free.