Эталонный стенд для защиты кода

Эталонная реализация для автономного обнаружения и устранения уязвимостей с помощью Claude, основанная на нашем опыте партнёрства с командами безопасности в нескольких организациях с момента запуска Claude Mythos Preview. Подробный разбор этих выводов и лучших практик см. в сопроводительной записи в блоге (также доступна в blog-post.md). Лёгкое пошаговое руководство по тому же циклу recon → find → triage → report → patch только с помощью SDK см. в сопутствующем cookbook.

Этот репозиторий не поддерживается, и вклады в него не принимаются.

🔒 Нужен управляемый вариант? Anthropic предлагает Claude Security — размещённый продукт, который находит и устраняет уязвимости в вашем исходном коде в нескольких проектах. Claude Security сканирует ваш репозиторий на предмет уязвимостей, применяет многоступенчатый конвейер верификации для снижения числа ложных срабатываний и позволяет управлять находками на всём их жизненном цикле: триаж, проверка исправлений и быстрая генерация исправлений.

Этот репозиторий — открытая эталонная реализация, основанная на общих лучших практиках поиска уязвимостей с помощью Claude. Вы можете использовать его для создания собственного конвейера поиска уязвимостей, настраивать логику, и его можно использовать с любым доступом к API Claude (включая Bedrock, Vertex или Azure).

Содержание

• Навыки Claude Code: /quickstart, /threat-model, /vuln-scan, /triage, /patch, /customize: интерактивное определение границ, сканирование, триаж и патчинг. Откройте этот репозиторий в Claude Code и запустите /quickstart, чтобы сориентироваться.
• harness/: автономный эталонный конвейер (recon → find → verify → report → patch), настроенный для поиска уязвимостей памяти в C/C++ с помощью Docker и ASAN. Этот стенд — эталонная реализация, а не продукт. Общая архитектура, промпты и песочница переиспользуемы, но стенд не будет работать с любой кодовой базой «из коробки». Запустите /customize, чтобы перенести его на ваш язык, детектор или класс уязвимостей.

⚠️ Безопасность: /quickstart, /threat-model, /vuln-scan и /triage только читают и записывают файлы. Запуск /patch по статическим находкам (TRIAGE.json или VULN-FINDINGS.json) также заключается только в чтении и записи. /customize редактирует код стенда и выполняет команды проверки. Любой из этих навыков безопасно запускать вне песочницы, если вы просматриваете и одобряете каждое использование инструмента в Claude Code. Автономный эталонный конвейер (включая /patch по результатам конвейера) выполняет целевой код, поэтому он отказывается запускаться вне песочницы gVisor без явного переопределения. Для настройки один раз запустите scripts/setup_sandbox.sh, затем вызывайте конвейер через bin/vp-sandboxed. Подробнее см. в docs/security.md и .

Начало работы

git clone https://github.com/anthropics/defending-code-reference-harness
cd defending-code-reference-harness
claude

# 30-sec intro + guided first run on the canary target
> /quickstart

> /quickstart how do I port the pipeline to Java?
> /quickstart how do I triage all these bugs?

Дополнительные материалы

• Запись в блоге · Сопроводительная запись в блоге с выводами + лучшие практики
• Конвейер · Как это работает: диаграмма, этапы, флаги CLI
• Безопасность · Песочница, что нельзя монтировать
• Песочница агента · Изоляция gVisor + список разрешённых исходящих подключений для каждого агента
• Настройка · Перенос на мой стек; какие файлы изменяются и почему
• Патчинг · Генерация и проверка исправлений для подтверждённых сбоев
• Устранение неполадок · Дубликаты, лимиты запросов, закрепление модели субагента
• Защитные механизмы · Блокировка опасной киберработы

Разгон

Наиболее успешные команды безопасности, с которыми мы работали, — это те, кто быстрее всего перешёл к практической работе. Хотя и возникает соблазн потратить месяцы на проектирование идеального конвейера, мы рекомендуем начинать с малого в первый день и развивать его по мере поступления опыта. Приведённые ниже шаги следуют этой схеме и задают амбициозный (но разумный) темп, основанный на том, что мы видели.

Шаг 1 (День 1): постройте модель угроз и выполните первое статическое сканирование + триаж

День 1 посвящён тому, чтобы увидеть весь цикл целиком. Используя только интерактивные навыки, вы построите модель угроз, выполните статическое сканирование в её границах, проведёте триаж полученных результатов и подготовите черновики кандидатных исправлений. К концу дня у вас будут модель угроз, ранжированный список статических находок и кандидатные патчи.

Соответствующие навыки только читают и записывают файлы в вашем репозитории. Пока вы запускаете Claude Code в интерактивном режиме и одобряете каждое использование инструмента, песочница не нужна.

# Pin every subagent to the model you want
export CLAUDE_CODE_SUBAGENT_MODEL=<model-id>
claude

# 0. intro + guided first run
> /quickstart

# 1. Build a threat model (aim before you shoot)
> /threat-model bootstrap targets/canary

# 2. Run a static scan, scoped by that threat model
> /vuln-scan targets/canary

# 3. Verify, dedupe, and rank what came back
> /triage targets/canary/VULN-FINDINGS.json

# 4. Generate candidate fixes for the verified findings
> /patch ./TRIAGE.json --repo targets/canary

Этот процесс создаёт THREAT_MODEL.md, VULN-FINDINGS.{json,md}, TRIAGE.{json,md} и PATCHES/.

Кандидаты в уязвимости, полученные на Шаге 1, появляются в результате статического анализа исходного кода, выполненного Claude (ничего не собирается и не запускается), поэтому на любых целях, отличных от canary, ожидайте больше ложных срабатываний. На Шаге 2 вы получите находки, подтверждённые исполнением.

Примечание: на canary-цели /triage может отклонить находки сканирования как ложные срабатывания. entry.c сам заявляет о себе как о намеренно уязвимом демонстрационном коде, и /triage корректно исключает ошибки в тестовом / фикстурном коде. Чтобы увидеть полный процесс подтверждения / дедупликации / ложных срабатываний, запустите его на курируемом фикстуре (/triage .claude/skills/triage/fixtures/canary-findings.json --repo targets/canary) или направьте навыки Шага 1 на свой код.

Шаг 2 (День 2): запустите эталонный конвейер на библиотеке C/C++

Во второй день вы перейдёте от интерактивных навыков к первому автономному запуску с использованием эталонного конвейера. Вы выполните полный цикл recon → find → verify → report в своём окружении на заведомо уязвимой библиотеке с открытым исходным кодом, а затем сгенерируете кандидатный патч для того, что он найдёт. В итоге вы получите набор воспроизводимых сбоев, отчёты об эксплуатируемости и кандидатные патчи, а также понимание того, как работает конвейер.

Запуск конвейера прост:

# One-time setup
python3 -m venv .venv && .venv/bin/pip install -e .
./scripts/setup_sandbox.sh   # installs gVisor, builds the agent images, and verifies isolation; note: requires Docker
export ANTHROPIC_API_KEY=sk-ant-...   # or CLAUDE_CODE_OAUTH_TOKEN, or Bedrock — see docs/agent-sandbox.md

# Run the recon → find → verify → report loop
bin/vp-sandboxed run drlibs --model <model-id> --runs 3 --parallel --stream --auto-focus
# Generate a candidate patch for each finding
bin/vp-sandboxed patch results/drlibs/<timestamp>/ --model <model-id>

# Or, ask Claude Code to launch the pipeline and watch the run for you
claude
> run the pipeline on drlibs and explain findings as they come

Результаты цикла сохраняются в каталог results/drlibs/<timestamp>/. С флагом --stream первый отчёт появится в течение нескольких минут в каталоге reports/bug_NN/.

⚠️ run порождает автономных агентов. Конвейер запускает каждого агента внутри контейнера gVisor с исходящим трафиком, ограниченным только API Claude. Подкоманды, порождающие агентов, отказываются запускаться вне него без явного переопределения. Дополнительную информацию см. в docs/security.md и docs/agent-sandbox.md.

Под капотом конвейер проходит семь этапов:

1. Build: компилирует цель в Docker-образ с ASAN (детектором ошибок памяти для C и C++). Конвейер автоматически собирает этот образ при первом запуске, используя Dockerfile цели.
2. Recon: лёгкий агент читает исходный код внутри изолированного от сети контейнера и предлагает разбиение, т.е. «вот N отдельных подсистем разбора входных данных, которые стоит атаковать по отдельности», чтобы параллельные find-агенты исследовали разные области, а не сходились на одной и той же ошибке. Без флага --auto-focus конвейер использует список focus_areas из config.yaml цели.
3. Find: параллельно работают N агентов, каждый в собственном изолированном контейнере. Каждый агент читает исходный код, формирует некорректные входные данные и запускает ASAN-бинарник, пока конкретный ввод не вызовет сбой 3 раза из 3.
4. Verify: отдельный агент-оценщик (grader) воспроизводит каждый сбой в новом контейнере, к которому find-агент не прикасался. Единственное, что передаётся от find-агента оценщику, — это созданный им proof of concept.
5. Dedupe: агент-судья (judge) сравнивает подтверждённые сбои с уже сообщёнными ошибками и решает, является ли каждый из них новой ошибкой, лучшим примером известной ошибки или дубликатом, который нужно пропустить.
6. Report: агент-репортёр составляет структурированный анализ эксплуатируемости для каждой уникальной ошибки, включая сведения о классе примитива, достижимости, пути эскалации и серьёзности.
7. Patch (отдельная команда patch, описанная выше): агент-патчер пишет предлагаемое исправление, а агент-оценщик подтверждает, что новый код собирается, исходный ввод из proof of concept больше не вызывает сбой, тестовый набор цели по-прежнему проходит и новый find-агент не может найти обходной путь для исправления.

Подробнее см. в docs/pipeline.md.

Шаг 3 (Дни 3–5): настройте конвейер под вашу цель

В дни 3–5 вы настроите стенд под свою собственную цель. Сначала вы направите навыки Шага 1 на свой код, а затем используете /customize, чтобы перенести конвейер на ваш стек. К концу недели у вас будет каталог targets/<your-service>/, против которого можно запускать конвейер, проверенный одним дымовым запуском конвейера и готовый к масштабированию на Шаге 4.

Хотя эталонный конвейер предназначен для поиска уязвимостей памяти в коде C и C++, его архитектура универсальна. Перенос на новый класс уязвимостей или язык сводится к ответу на следующие вопросы для вашего целевого стека:

Перед настройкой направьте навыки Шага 1 на свой код. Напоминаем: они работают только с чтением и записью файлов, поэтому их можно запускать без песочницы.

claude

> /quickstart how do I customize this for ~/code/my-service?

> /threat-model bootstrap-then-interview ~/code/my-service
> /vuln-scan ~/code/my-service
> /triage ~/code/my-service/VULN-FINDINGS.json --repo ~/code/my-service

Затем используйте артефакты, созданные этими навыками, в навыке /customize, который изменяет стенд под вашу кодовую базу.

> /customize use ~/code/my-service/{THREAT_MODEL.md,VULN-FINDINGS.json} and ./TRIAGE.md

Когда /customize завершится, у вас будет настроенный каталог targets/my-service/. Проверьте его дымовым запуском конвейера, прежде чем масштабироваться.

bin/vp-sandboxed run my-service --model <model-id> --runs 1

Подробнее см. в docs/customizing.md.

Шаг 4 (Неделя 2): начните автономное сканирование, триаж и патчинг

На второй неделе вы будете использовать конвейер, настроенный на Шаге 3, на своих целях, добавив внешний цикл к внутреннему циклу конвейера: запускайте несколько сканирований конвейера, проводите триаж находок со всех этих запусков, вносите исправления на основе приоритизации и повторяйте.

# Scan - run a wave of parallel runs against your target
bin/vp-sandboxed run my-service --model <model-id> --runs 5 --parallel --stream --auto-focus

# Triage - dedupe and rank every finding across all waves using your threat model
> /triage results/my-service/ --repo ~/code/my-service --auto --votes 5

# Patch - generate and validate fixes, starting with what triage ranked the highest
> /patch results/my-service/<timestamp>/ --model <model-id>

⚠️ Соблюдайте те же правила песочницы, что и в Шаге 2

Отдельный запуск конвейера уже сам проверяет и дедуплицирует свои находки. /triage работает в масштабе множества запусков конвейера. При наведении на каталог results/ он устраняет дубликаты по всем запускам (а также любые статические находки из /vuln-scan, если они есть), перекалибрует оценки серьёзности относительно вашей модели угроз и пытается направлять каждую находку владельцу компонента.

По возможности быстрое исправление находок помогает поддерживать внешний цикл максимально продуктивным. Когда находки исправлены, модель не может найти их заново и вместо этого выявляет принципиально новые, как правило более глубокие проблемы. По мере выполнения новых волн конвейера количество находок, скорее всего, будет уменьшаться, но сложность, вероятно, будет расти. Если быстрое исправление невозможно, даже простое фиксирование предыдущих находок в known_bugs цели может помочь направить будущие запуски на новые ошибки.

Автономный триаж и патчинг остаются открытыми вопросами, и этот эталонный стенд не решает их полностью. Стратегии верификации в /patch помогают поднять планку, но серьёзность и приоритизация в конечном счёте являются суждениями о вашем окружении, а проверенные патчи не всегда можно отправить в апстрим. Многие партнёры называют эти шаги своими текущими узкими местами, поэтому вам стоит заложить на них реальное инженерное время.

Подробнее см. в docs/triage.md и docs/patching.md.

Взгляд в будущее

После первоначального разгона команды, с которыми мы работали, как правило, инвестировали в несколько направлений:

1. Просмотр всех внутренних репозиториев и ключевых зависимостей с открытым исходным кодом, ранжирование того, какие из них важнее всего сканировать (например, на основе их экспозиции, истории CVE, критичности для бизнеса), а затем последовательное сканирование списка в порядке приоритета.
2. Создание специальной инфраструктуры для сканирования, чтобы убрать сканирование с ноутбуков и разовых виртуальных машин. Самые успешные команды сопротивляются желанию построить идеальную платформу сканирования до масштабирования.
3. Встраивание сканирования в свой SDLC. Некоторые команды настроили регулярное сканирование (например, ежедневное или еженедельное) или добавили сканирование в свои CI-конвейеры.
4. Тестирование и эксперименты с моделями, чтобы выяснить, что лучше всего работает для них.