# Ваш security-агент слепнет через 5 минут. Cloudflare показала, что с этим делать

- Site: VeraPoint News
- Section: Новости
- Date: 2026-06-19
- Canonical: https://verapointmedia.com/news/build-your-own-vulnerability-harness/
- Markdown: https://verapointmedia.com/news/build-your-own-vulnerability-harness.md
- Summary: Cloudflare объяснила, почему одиночные LLM-агенты для поиска уязвимостей — тупик, и опубликовала архитектуру харнесса, который живёт дольше любой модели.
- Tags: #cloudflare #llm #безопасность #devsecops #архитектура #projectglasswing
- Image: https://verapointmedia.com/static/content-assets/news/build-your-own-vulnerability-harness/cover.webp

## Sources

- https://blog.cloudflare.com/build-your-own-vulnerability-harness/
- https://news.google.com/rss/articles/CBMic0FVX3lxTE1pWDBMczJHSmhnRDNhYUZjdFVKTHM5M05NMUdoNWl5VE00cGJ2Y0tscHF4T3lvMWIxOGwzRHJ6SjNEQmItOFAtYktkRWJ2d2dTSWJ3bDkwN2lvUklpUHRQX2FnQjNSeDBnLTZIdkJWMUR4Mkk?oc=5

---

Ваш босс спросит через месяц: «Слушай, а почему мы тратим бюджет на LLM-агента для поиска багов, если он находит одно и то же и теряет контекст после пары файлов?»

И у меня для вас плохие новости — скорее всего, так и будет.

Cloudflare только что выкатила вторую часть разбора своего проекта Glasswing. И это не красивая презенташка про «AI-powered security», а честный инженерный пост про то, почему подход «одна модель — один агент — одно репо» для реального поиска уязвимостей не работает. Вообще. Они объяснили, как построить харнесс, который решает эту боль.

Я прочитала, покопалась в деталях и попробую пересказать человеческим языком.

## Первое: почему ваш нынешний агент тупит

Представьте: вы просите LLM-агента проверить безопасность кода. Он заходит в репозиторий, видит сотни файлов, начинает читать… и примерно через 5 минут его контекстное окно забито настолько, что он забывает, с чего начал. Дальше он либо галлюцинирует, либо сваливается в ложные срабатывания — видит «уязвимость» там, где её нет. Или не видит там, где она есть.

Cloudflare называет это проблемой «одной гипотезы»: агент держит в голове только одну версию того, что происходит в коде. И когда контекст схлопывается — а он схлопывается всегда — вы теряете результаты.

Они описали это в первой статье про Project Glasswing (та была про общие выводы). Новая статья — уже с конкретными рецептами.

## В чём суть решения: это не промпт, это архитектура

Главный тезис Cloudflare: будущее не за отдельными моделями, а за харнессом — слоем-оркестратором, который управляет процессом поиска уязвимостей. Модели внутри харнесса — сменные компоненты.

Почему это важно? Потому что рынок AI-моделей штормит. Сегодня у вас лучшая модель — завтра она исчезла, или вышла новая, в два раза точнее. Если вы завязаны на одну, вы в ловушке.

Харнесс Cloudflare построен так, чтобы пережить любую модель. Он:
- управляет состоянием поиска;
- не теряет гипотезы между запусками;
- кросс-проверяет результаты разными моделями (adversarial review — состязательная проверка, когда одна модель ищет баги, а другая критикует находки первой);
- обходит лимиты контекстного окна, дробя задачу на сессии.

Если упростить: вместо одного «умного» агента, который пытается объять необъятное, работает фабрика из маленьких проверок. Одна модель выдвинула гипотезу — её результат сохранился отдельно. Вторая модель перепроверила. Третья — трассирует зависимости между репозиториями.

## «А почему не subagents?» — Cloudflare ответила сразу

В статье прямо разобрали возражение, которое наверняка возникнет у инженера: «Может, просто наплодить subagents, и они справятся?»

Ответ Cloudflare: subagents — хороший старт, но не решение. Проблема в том, что анализ безопасности требует сотен параллельных расследований, которые:
- живут между запусками (persistence);
- не делят одно переполненное контекстное окно;
- могут быть переиспользованы и перекрёстно сверены позже;
- в идеале — отслеживают уязвимости через цепочки зависимостей между репозиториями (fleet-wide dependency tracing).

То есть «просто добавьте агентов» не работает. Это оркестрационная задача, и промптом её не закрыть.

## Где здесь пахнет PR, а где — реальная инженерия

Cloudflare не скрывает, что это архитектурный подход, а не готовый продукт. Статья — технический гайд с объяснением управления состоянием, дедупликации и triage-цикла (триаж — это когда из тысяч сырых срабатываний вручную или автоматически отбирают те, что реально надо чинить).

Но нужно держать в голове ограничения:
- Cloudflare — крупная компания с ресурсами. Внедрить такой харнесс в маленькой команде — отдельный инженерный подвиг.
- Сложность архитектуры растёт: чем больше моделей и этапов проверки, тем выше стоимость вычислений и поддержки.
- Подход model-agnostic — это свобода, но и головная боль: каждая новая модель потребует калибровки.

Так что «берите и делайте» — громко сказано, но направление мысли понятное.

## Почему это важно прямо сейчас

Если коротко: вы либо строите систему, которая переживёт смену моделей, либо каждый апдейт в индустрии будет для вас катастрофой.

Cloudflare подтверждает то, что многие инженеры уже чувствуют на практике: LLM-пайплайны без нормальной обвязки — это дорого и ненадёжно. Ложные срабатывания умножаются, контекст теряется, время уходит.

Харнесс, описанный в статье — не серебряная пуля, но честная попытка решить эти проблемы на уровне архитектуры.

Для технических команд это стоит изучить не как «готовый ответ», а как инженерный вызов: можете ли вы сделать свою систему безопасности model-agnostic? Если нет — какой ценой вы будете платить за каждый следующий апдейт моделей?

## Материалы

- [Cloudflare Blog] Build your own vulnerability harness: https://blog.cloudflare.com/build-your-own-vulnerability-harness/
- [news.google.com] supporting context: https://news.google.com/rss/articles/CBMic0FVX3lxTE1pWDBMczJHSmhnRDNhYUZjdFVKTHM5M05NMUdoNWl5VE00cGJ2Y0tscHF4T3lvMWIxOGwzRHJ6SjNEQmItOFAtYktkRWJ2d2dTSWJ3bDkwN2lvUklpUHRQX2FnQjNSeDBnLTZIdkJWMUR4Mkk?oc=5