Более 60% находок в тестах инструментов для защиты приложений оказываются ложными, нерелевантными или вообще относятся к недостижимому коду. Для тех, кто надеялся закрыть эту боль через LLM, новости так себе: приоритизация уязвимостей с помощью больших языковых моделей пока чаще добавляет работы, чем снимает ее. Для российских команд разработки и безопасности это важный сигнал: если в пайплайне и так много шума, еще один умный слой без контекста ситуацию не спасет.
Об этом, как пишет Dark Reading, рассказал Аршан Дабирсиаги, сооснователь и CTO AppSec-стартапа Pixee. По его словам, команда протестировала больше десятка инструментов для сканирования приложений и пришла к неприятному выводу: свыше 60% срабатываний по-прежнему составляют ложноположительные находки, уязвимости в недостижимом коде или проблемы с низким уровнем критичности. В августе на Black Hat USA Дабирсиаги собирается представить эти результаты и объяснить, почему стандартные LLM плохо справляются именно с тем, что больше всего нужно AppSec-командам, а именно с отбором реальных рисков из длинного списка подозрительных мест.
Проблема не только в точности моделей, но и в банальной экономике процесса. Если довериться автоматике без фильтра, организация получает поток обновлений зависимостей, pull request и алертов, которые надо разбирать руками. Альтернатива не лучше: посадить людей на штучную проверку каждого срабатывания. Сам Дабирсиаги описывает это как выбор между бесконечным потоком автоматических обновлений и ручным поиском тех самых нескольких процентов действительно опасных случаев. Для крупного продукта с насыщенным CI/CD это не академический спор, а нагрузка на команду, билд-минуты, сроки релизов и уровень доверия к security-процессу внутри разработки.
На этом фоне особенно неприятно выглядит общий тренд рынка. По оценке FIRST, число уязвимостей, получающих идентификатор CVE, в 2026 году вырастет на 50%. Microsoft, как отмечает Dark Reading, уже бьет рекорды по объему Patch Tuesday. Иными словами, входящий поток проблем растет, а фильтры качества пока не догоняют. Отсюда и главный парадокс момента: генеративный ИИ стал заметной темой в AppSec, но на практике он нередко работает медленнее и дороже привычных инструментов, при этом все равно требует плотного человеческого контроля. Для менеджмента это плохая новость, потому что обещание «сократим ручной труд за счет ИИ» разбивается о необходимость нанимать тех же специалистов, чтобы разбирать результаты ИИ.
Ключевой тезис Дабирсиаги звучит довольно жестко: без контекста LLM в задачах безопасности слишком «тупы», чтобы им доверять самостоятельное исправление кода. Модель может увидеть потенциальную уязвимость в строке X и предложить фикс даже там, где проблемы нет. Дальше начинается уже не защита, а порча приложения: ухудшается производительность, усложняется код, появляются лишние изменения, а реальная безопасность от этого не растет. Для разработчиков это знакомый сценарий. Если инструмент слишком часто ошибается, его перестают слушать, merge rate падает, а доверие к рекомендациям безопасности быстро испаряется. В итоге страдает именно приоритизация уязвимостей: вместо короткого списка реальных рисков команда получает длинную очередь сомнительных задач.
Почему модели спотыкаются? Потому что для нормального триажа им нужен как минимум тройной контекст: организационный, технический и кодовый. Надо понимать, где именно работает приложение, как устроен деплой, какие компоненты реально используются, какие функции доступны извне и насколько конкретная находка вообще достижима в рантайме. Пример с MD5, который приводит Дабирсиаги, хорошо показывает проблему. На бумаге это средняя по опасности находка. В жизни все зависит от сценария: если MD5 используют для хеширования паролей или секретов, ситуация плохая; если алгоритм применяют вне задач безопасности, вывод может быть совсем другим, вплоть до низкого приоритета или ложного срабатывания. Универсальная модель без знания контекста проекта такую развилку часто не удерживает.
Отдельная тема — reachability, то есть достижимость кода и библиотек в реальном исполнении приложения. Именно здесь AppSec-команды получают самый ощутимый выигрыш от нормального анализа. Dark Reading приводит два показательных исследования: одно показало, что 62% библиотек с открытым исходным кодом вообще не используются во время выполнения, другое — что 71% Java-кода в приложениях приходится на open source, но реально используется лишь 12% этого объема. Для бизнеса вывод очевиден: без проверки достижимости сканер может пугать уязвимостью в компоненте, который физически не участвует в работе продакшена. Для команды это лишние тикеты, лишние согласования и лишний шум в backlog.
Есть и еще одна неприятная особенность LLM: нестабильность выводов. Один и тот же набор данных модель может интерпретировать по-разному от запуска к запуску. Сегодня она объявляет находку ложноположительной, завтра — подтвержденной. Для инженерной среды, где важны воспроизводимость и предсказуемость, это почти токсичное свойство. Поэтому речь идет уже не о том, чтобы просто «подкрутить промпт», а о необходимости строить вокруг модели полноценную обвязку: дополнительные проверки, детерминированные правила, внешние источники контекста, валидацию результатов и ограничения на автоматические действия. Иначе LLM превращается не в помощника AppSec, а в еще один нестабильный источник задач.
Для русскоязычного рынка из этой истории следует довольно практичный вывод. Генеративный ИИ в безопасности приложений уже можно использовать как слой ускорения, но не как автономный центр принятия решений. Командам, которые сейчас пересобирают SDLC, разумнее вкладываться не в очередной модный ярлык на сканере, а в качество сигналов: достижимость, нормализацию находок, связь с архитектурой и эксплуатационным контекстом, а также понятные правила, по которым строится приоритизация уязвимостей. Похоже, ближайшая конкуренция в AppSec пойдет не между теми, у кого «есть ИИ», а между теми, кто сумеет превратить ИИ из болтливого стажера в инструмент, который хотя бы не спорит сам с собой на каждом повторном запуске.