RAPTOR выглядит как попытка собрать в одном месте то, что обычно живет отдельными инструментами: Semgrep, CodeQL, fuzzing через AFL++, crash analysis через GDB и rr, LLM-валидацию находок, генерацию PoC и черновиков патчей. Фреймворк работает поверх Claude Code и превращает интерактивного кодового ассистента в агента для исследования безопасности кода.
Главный смысл RAPTOR не в том, что «ИИ сам найдет все уязвимости». Более честная формулировка звучит так: система пытается связать механические сканеры, анализ потоков данных, проверку достижимости и рассуждения модели в один конвейер. В хорошем сценарии исследователь получает меньше сырого шума от сканеров и быстрее доходит до вопроса, который реально важен: достижима ли находка извне, можно ли подтвердить эксплуатацию и какой фикс не сломает приложение.
Как устроен RAPTOR
Архитектура разделена на два слоя. Python-часть запускает инструменты, парсит SARIF, управляет проектами, пишет отчеты и считает покрытие. Слой Claude Code принимает решения: какие находки изучать глубже, как читать путь атаки, где модель видит ложное срабатывание, а где нужен отдельный агент для fuzzing, CodeQL или crash analysis.
Базовый сценарий начинается с проекта. Пользователь создает рабочую область командой /project create, указывает путь к коду, затем запускает /understand для карты поверхности атаки и /agentic для полного цикла. Внутри /agentic RAPTOR запускает Semgrep и CodeQL, дедуплицирует находки, передает результаты в многоступенчатую валидацию, а затем может подготовить PoC и патч для подтвержденных проблем.
| Команда | Назначение | Зрелость по README |
|---|---|---|
| /scan | Статический анализ через Semgrep и CodeQL | Stable |
| /understand | Карта entry points, trust boundaries, sinks и потоков данных | Stable |
| /validate | Проверка достижимости и реалистичности эксплуатации | Stable |
| /fuzz | Fuzzing бинарей через AFL++ и разбор падений | Stable |
| /exploit | Генерация демонстрационного PoC | Beta |
| /patch | Генерация исправления для подтвержденной проблемы | Beta |
| /web | Сканирование веб-приложений | Alpha или stub |
Отдельно авторы добавили интеграцию с Z3. Для CodeQL такой слой проверяет, достижим ли найденный путь с точки зрения ограничений, прежде чем отправлять находку в LLM. Для бинарной эксплуатации Z3 помогает оценивать constraints для one-gadget на конкретном crash state. Идея здравая: модель не должна рассуждать о красивом, но невозможном пути, если SMT-solver уже показывает недостижимость.
Как попробовать без лишней теории
Ручная установка выглядит просто: git clone https://github.com/gadievron/raptor.git, затем cd raptor, pip install -r requirements.txt, npm install -g @anthropic-ai/claude-code, pip install semgrep и запуск claude из каталога проекта. Практически лучше начинать с devcontainer, потому что фреймворк тянет CodeQL, AFL++, rr, GDB, Playwright и другие зависимости. Минус очевиден: контейнер крупный, а для rr README просит запуск Docker с --privileged.
Вот здесь начинается первая взрослая проверка. --privileged дает контейнеру слишком широкие права на хосте, поэтому запускать такой контейнер на рабочей машине с чувствительными данными нельзя. Для экспериментов нужен отдельный стенд, временная виртуальная машина или изолированная среда без секретов, токенов CI и корпоративных ключей.
Материал предназначен для легального и ответственного использования. RAPTOR можно применять для анализа собственного кода, разрешенного аудита, обучения и защитных исследований. Нельзя использовать такие инструменты для несанкционированного доступа, слежки, взлома, нарушения правил сервисов или незаконного обхода ограничений. Российским читателям отдельно стоит учитывать законы РФ и внутренние регламенты компании.
Где RAPTOR может быть полезен
Самый сильный сценарий для RAPTOR, разбор большого репозитория, где обычный SAST уже нашел десятки или сотни срабатываний. Инженеру нужно не красивое число в отчете, а приоритизация. Например, одна XSS-находка лежит в тестовом коде, вторая требует недостижимого состояния, третья проходит через реальный обработчик пользовательского ввода. RAPTOR пытается отделить такие случаи не только правилами Semgrep, но и анализом контекста.
Второй сценарий, аудит C и C++ после падений. Здесь связка AFL++, rr, GDB и LLM-объяснения может ускорить путь от crash input до root cause. Модель не заменяет реверсера, но помогает собрать стек, регистры, дизассемблирование и гипотезу в связный отчет. Для команды разработки такая форма часто полезнее, чем просто «SIGSEGV somewhere».
Третий сценарий, подготовка патчей. Генерация исправлений в RAPTOR заявлена как beta, поэтому принимать патч без ревью опасно. Но черновик фикса, привязанный к подтвержденной атакующей цепочке, экономит время. Особенно если патч сопровождается объяснением, какие входные данные ломали код и почему предложенная проверка закрывает путь атаки.
Ограничения и неприятные детали
RAPTOR не похож на отполированный коммерческий продукт. Авторы прямо пишут, что проект собран энтузиастами и держится не только на инженерной строгости, но и на «duct tape». Для лаборатории и сильной AppSec-команды такой статус приемлем. Для внедрения в корпоративный процесс без пилота, контроля прав и отдельного владельца, нет.
Фреймворк зависит от качества моделей. README поддерживает Anthropic, OpenAI, Gemini, Mistral и Ollama для анализа, но локальные модели, по словам авторов, хуже справляются с генерацией exploit и patch code. Значит, автономность упирается в стоимость запросов, лимиты, доступность провайдеров и политику передачи кода во внешний LLM. Для российского корпоративного контура вопрос передачи исходников за пределы периметра часто важнее технических возможностей.
Еще один риск, ложная уверенность. Многоступенчатая валидация снижает шум, но не превращает результат в доказанную истину. LLM может убедительно описать невозможную эксплуатацию, пропустить важное условие сборки, неверно прочитать фреймворк или предложить патч с регрессией. Поэтому RAPTOR стоит считать помощником для исследователя, а не автоматическим арбитром безопасности.
Есть и лицензионный нюанс. Сам RAPTOR распространяется под MIT, но авторы отдельно предупреждают, что CodeQL имеет собственную лицензию и коммерческое использование требует проверки условий. Перед внедрением в платный аудит или внутренний корпоративный процесс нужно прочитать не только LICENSE проекта, но и ограничения зависимостей, включая лицензию CodeQL.
Маркетинговый миф вокруг таких инструментов прост: автономный агент якобы заменит пентестера или AppSec-инженера. RAPTOR показывает более реалистичную картину. Агент хорошо связывает инструменты, задает вопросы к коду, помогает оформлять выводы и быстрее проверять гипотезы, но ответственность за выводы остается у человека.
Кому стоит смотреть на RAPTOR
RAPTOR интересен AppSec-командам, vulnerability researchers, CTF-исследователям, разработчикам SAST-процессов и инженерам, которые уже понимают Semgrep, CodeQL, fuzzing и triage. Новичку фреймворк может показаться удобной кнопкой «найти уязвимости», но без базовых знаний пользователь быстро начнет принимать уверенный текст модели за факт.
Для продакшена безопаснее начать с небольшого пилота: взять открытый учебный проект или внутренний сервис без секретов, прогнать /scan и /understand, сравнить выводы с ручным ревью, затем отдельно проверить /validate на заранее известных уязвимостях. Если RAPTOR снижает шум и помогает быстрее подтверждать реальные баги, фреймворк можно подключать к CI как вспомогательный источник SARIF и отчетов. Если отчеты выглядят убедительно, но команда не может воспроизвести находки, агент пока приносит больше риска, чем пользы.
RAPTOR можно считать заменой Semgrep или CodeQL?
Нет. RAPTOR использует Semgrep и CodeQL как источники механических находок, а затем добавляет дедупликацию, анализ достижимости, LLM-валидацию, отчеты, PoC и черновики патчей. Без базовых сканеров фреймворк теряет значительную часть смысла.
Можно ли запускать RAPTOR на закрытом корпоративном коде?
Технически можно, но сначала нужно решить вопрос с передачей кода и фрагментов находок внешним LLM-провайдерам. Для чувствительного кода потребуется локальная модель или отдельное юридическое и ИБ-согласование. Также нельзя запускать контейнер с широкими правами на машине, где лежат секреты.
Насколько опасна функция генерации exploit PoC?
Функция полезна для подтверждения уязвимости в разрешенном аудите, но несет очевидный риск злоупотребления. В рабочем процессе лучше хранить PoC отдельно, ограничивать доступ, не публиковать детали до исправления и использовать только на собственных системах или в рамках письменного разрешения.
Стоит ли использовать RAPTOR с Ollama и локальными моделями?
Для первичного анализа и экспериментов локальная модель может подойти. Для генерации сложного PoC и патча авторы проекта сами рекомендуют более сильные frontier-модели. Локальный запуск снижает риск утечки кода, но качество выводов придется проверять жестче.
Где RAPTOR работает хуже всего?
Слабее всего выглядят сценарии, где нужна стабильная промышленная эксплуатация, строгий веб-сканер, автоматическое доверие к патчам и работа без квалифицированного оператора. Веб-модуль пока обозначен как alpha или stub, а beta-функции exploit и patch требуют обязательного ручного ревью.
RAPTOR стоит воспринимать как лабораторный, но уже насыщенный фреймворк для ускорения security research. Его сила в связке инструментов и проверке гипотез, а не в обещании автономного взлома или автономной защиты. Начинать стоит с изолированного стенда, небольшого репозитория, понятных правил доступа к коду и обязательной ручной перепроверки каждой сильной находки.
