# Как Anthropic защищает разработку, где 80% кода пишет Claude

Канонический URL: https://zero2claude.ru/blog/securing-ai-native-sdlc
Дата: 2026-07-21
Теги: безопасность, claude-code, агенты, enterprise

Заместитель CISO Anthropic рассказывает, как команда безопасности перестроила процессы разработки под мир, где агенты пишут и ревьюят большую часть кода.

Инженеры Anthropic сейчас выпускают в среднем в 8 раз больше кода за квартал, чем в 2021–2025 годах. Причина проста: Claude перестал быть просто помощником и стал основным автором кода — сегодня он пишет около 80% всего кода, который попадает в кодовую базу компании. Больше половины merge-запросов проходит через внутреннюю версию Claude Tag, а люди-инженеры всё чаще занимаются не написанием строк, а постановкой задачи и финальным одобрением.

<Cover src="/blog/securing-ai-native-sdlc.jpg" alt="Щит защищает поток кода" />

Такой скачок скорости — это не только про продуктивность, но и про риски. Заместитель CISO Anthropic Джейсон Клинтон описал, как команда безопасности перестроила процессы вокруг цикла разработки (SDLC), чтобы не превратиться в бутылочное горлышко по закону Амдала — когда всё ускоряется, кроме ревью и мониторинга, и именно они начинают тормозить весь конвейер.

## От каких угроз защищаются

Клинтон честно называет конкретные угрозы, под которые спроектирован весь набор мер. Первая — скомпрометированный или подверженный prompt-инъекции агент, который вносит вредоносное изменение. Вторая — отравление supply chain и зависимостей, когда агент воспринимает вредоносный код как доверенный вход. Третья — обычные классы уязвимостей приложений, просто теперь возникающие в гораздо большем объёме, потому что кода стало на порядок больше.

Под эти три категории риска и выстроены все дальнейшие механизмы защиты.

## Четыре стратегии вместо одной большой стены

Команда безопасности Anthropic не пытается закрыть весь риск одним универсальным барьером. Вместо этого используются четыре взаимодополняющие стратегии:

- сдвиг безопасности «влево» — интеграция прямо в стадию написания кода;
- жёсткие границы доступа и идентичности, чтобы ограничить «радиус поражения» при инциденте;
- сочетание детерминированных проверок и агентных ревью до и после продакшена;
- участие человека именно в тех точках, где это даёт наибольший эффект.

Эти принципы применяются на каждом этапе жизненного цикла — от планирования до продакшена, — и дальше разберём, как именно это работает на практике.

## Планирование: агент вместо ручного security-review

Один из первых автоматических инструментов безопасности в Anthropic был совсем простым: веб-приложение на Claude Opus, которое читало проектный документ и сверяло его с фреймворком MITRE ATT&CK, чтобы найти потенциальные уязвимости и предложить меры защиты.

![Схема автоматического процесса security review проекта. Источник: Anthropic](/blog/securing-ai-native-sdlc-1.jpg)

Сегодня этот инструмент подключён к внутреннему индексу знаний компании — с историей решений, политиками и связанными системами. Это дало более глубокий контекст и заодно ловит информацию, которая раньше просто выпадала из поля зрения ревьюеров. Как только команда убедилась, что оценки Claude точны, командам разрешили самостоятельно одобрять свои проекты — если Claude оценивал риск запуска как достаточно низкий.

Раньше проверка безопасности архитектуры (PSR) была нужна до долгого и дорогого процесса написания кода: ошибка, найденная на этой стадии, спасала месяцы переработки. Сегодня несколько прототипов крупной функции можно собрать за часы, и детальный архитектурный ревью уже не такой критичный барьер — важнее не создавать искусственную задержку там, где скорость важнее бюрократии.

<Callout type="tip" title="Устойчивый принцип">
Подключай агентов безопасности туда, где уже живёт контекст — переписки, прошлые ревью, кодовую базу, — а не заставляй команды писать подробную документацию на этапах, где она больше не нужна.
</Callout>

## Написание кода: правила зашиты прямо в момент генерации

Раньше команды по безопасности собирали статистику по повторяющимся уязвимостям и писали гайдлайны для разработчиков — но эти гайдлайны сложно проверять и редко кто их реально соблюдает. В Anthropic эти же правила зашиты в файлы CLAUDE.md и подключаемые организационные skills, поэтому код с самого момента генерации следует лучшим практикам.

Работает это как закрытый контур: как только агент обнаруживает новый класс багов, соответствующий файл сразу обновляется — и в будущем этот класс ошибок уже не повторяется. Дальше в CLAUDE.md прописана команда `/security-review`, которую агент запускает перед открытием PR: она ищет места, где может проникнуть контролируемый атакующим ввод, сканирует подозрительные ссылки и проверяет свои же находки. Сегодня эта проверка вообще происходит параллельно с генерацией кода — установленный security-плагин следит за диалогом и кодом «на ходу» и сразу предлагает улучшения в той же сессии.

![Иллюстрация к разделу о написании кода и жёстких границах доступа. Источник: Anthropic](/blog/securing-ai-native-sdlc-2.jpg)

Помимо самого кода, важно ограничивать «радиус поражения» — на случай, если что-то пошло не так. Anthropic перевела разработчиков на удалённые виртуальные машины: это дало больше контроля и видимости по сравнению с обычными ноутбуками. Трафик агентов на этих VM ограничен белым списком (egress-allowlist) — то есть агент может обращаться только к заранее одобренному узкому набору сервисов. Это критично именно тогда, когда агент читает недоверенный вход, в который может быть встроена prompt-инъекция: даже если вредоносная инструкция «сработает», у неё просто нет маршрута для утечки данных за пределы разрешённого списка адресов.

Раньше удалённая среда разработки использовалась в основном для защиты интеллектуальной собственности; сегодня зрелые AI-команды всё чаще применяют её именно как способ удержать агента в узких рамках.

## Тестирование и CI: где скорость встречается с контролем

По опыту Клинтона, именно этап тестирования и CI быстрее всего превращается в самое болезненное горлышко при переходе на AI-native разработку. Когда большинство разработчиков в Anthropic начали одновременно запускать несколько агентов, стало очевидно: вся команда теперь движется со скоростью, с которой люди успевают ревьюить код.

Ответом стало не отказ от человеческого контроля, а его перераспределение: ревью ускорили за счёт сочетания агентных и детерминированных проверок, оставив ручной разбор для регулируемого или по-настоящему критичного кода. Историческое допущение, что человеческое ревью — золотой стандарт, не подтверждается практикой: security-баги регулярно проникают в продакшен по всему миру, даже когда ревью делали люди. Многоагентная проверка ловит больше кода и справляется со сложными случаями лучше.

Результаты впечатляют: доля PR, получающих содержательные комментарии по существу, выросла с 16% до 54% — после того как агентам стали требовать письменное доказательство, что найденная проблема действительно валидна. По оценке команды, около трети багов, стоявших за прошлыми инцидентами claude.ai, были бы пойманы уже действующими сейчас автоматизированными процессами.

Anthropic не одиноки в этом выводе. Партнёры и другие компании нашли похожие эффекты:

| Компания | Что сделали | Результат |
|---|---|---|
| Anthropic (внутри) | Многоагентное ревью PR с доказательством находок | Доля содержательных ревью выросла с 16% до 54% |
| Intercom | Автоматически одобряют часть PR | Автоодобрение 19% PR, деплой ускорился вдвое, простои от багов упали на 35% |
| CircleCI | Агент Chunk на Claude чинит CI/CD и сам проверяет свои фиксы | Доля задач агента, доходящих до готового PR, выросла вдвое |

Когда PR открывается, его автоматически проверяют несколько узкоспециализированных агентов — каждый сфокусирован на конкретной проблеме и использует RAG для контекста по прошлым инцидентам. Такой подход эффективнее одного «супер-агента безопасности» по трём причинам: у разных агентов не совпадают предвзятости и слепые зоны; ошибку или компрометацию одного агента может заметить другой; и усилия не размазываются тонким слоем по слишком многим направлениям сразу.

![Иллюстрация многоагентного ревью пул-реквестов. Источник: Anthropic](/blog/securing-ai-native-sdlc-3.jpg)

При этом агенты не мержат код в продакшен без всякого контроля — кодовая база разбита по уровням риска, и часть репозиториев остаётся под строгим человеческим одобрением. Каждое решение об апруве логируется вместе с сигналами и объяснением, а выборка, взвешенная по риску, регулярно проверяется людьми. Отдельный слой тестов следит за инвариантами вроде «пользователь A никогда не может прочитать данные пользователя B» и при подозрении запускает дополнительный ручной разбор. Агентные проверки дополняются классическими SAST-инструментами, которые тоже оставляют комментарии прямо в PR.

<Callout type="note">
Автоматизированные проверки стоят денег пропорционально объёму кода — и этот объём будет только расти. В Anthropic закладывают рост издержек, но рассчитывают, что удельная стоимость проверки будет падать вместе с тем, как модели становятся лучше в коде.
</Callout>

## Что из этого стоит забрать себе

Даже если твоя команда далека от масштабов Anthropic, идея разбить SDLC на этапы и на каждом задать вопрос «где здесь агент может навредить, и как ограничить последствия» работает в любом масштабе. Если хочешь на практике попробовать, как выглядит осторожная работа с агентами и код-ревью, посмотри бесплатный курс zero2claude — там разбираются базовые привычки безопасной работы с Claude Code, которые пригодятся и одиночному разработчику, и большой команде.

Похожий взгляд на организацию агентных пайплайнов есть и у других компаний — например, в истории о том, как [Datadog построил «универсальный станок» для агентов Claude Code](/blog/datadog-temper-universal-machine-tool), или в рассказе о [ночных агентах Rakuten](/blog/rakuten-claude-fable-5-overnight-agents), которые работают без присмотра человека.

## Частые вопросы

<Faq>
<FaqItem q="Значит ли это, что в Anthropic код мержится без человека?">

Нет. Часть кодовой базы, особенно регулируемая и критичная, остаётся под строгим человеческим одобрением. Даже там, где решение принимает Claude, каждый апрув логируется с обоснованием, а выборка проверок регулярно перепроверяется людьми.

</FaqItem>
<FaqItem q="Почему нельзя просто использовать один мощный агент безопасности вместо нескольких?">

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

</FaqItem>
<FaqItem q="Что такое egress-allowlist и зачем он агентам?">

Это белый список сетевых адресов, к которым агенту разрешено обращаться. Он ограничивает последствия prompt-инъекции: даже если вредоносная инструкция «сработает» внутри агента, у неё просто не будет маршрута, чтобы отправить данные куда-то за пределы этого узкого списка.

</FaqItem>
<FaqItem q="Как менялась роль человека в этом процессе?">

Люди сместились от написания кода к постановке задач, финальному одобрению и разбору выборочных, взвешенных по риску случаев. Ручной разбор целиком сохраняется там, где ошибка стоит особенно дорого — например, в инвариантах вроде доступа к чужим данным.

</FaqItem>
</Faq>

Если хочешь попробовать всё это руками — начни с бесплатного курса [«ИИ без иллюзий»](/learn/ai-critical).

<Callout type="note" title="Источник">
По мотивам статьи Anthropic «How Anthropic secures its AI-native software development lifecycle». Пересказали по-русски для новичков.
</Callout>
