Журнал "Information Security/ Информационная безопасность" #4, 2026

В последние годы инструменты гене- ративного ИИ и Open Source кратно увеличили скорость генерации кода. Соответственно, анализируя сегодня код в крупной инфраструктуре с помощью SAST, команда AppSec может получать сотни тысяч срабатываний в сутки. Вруч- ную обработать такой поток, чтобы выде- лить наиболее критичные уязвимости, просто невозможно. При этом растет число зависимостей, усложняются цепоч- ки поставок. В российском решении SASTAV 1 сочетаются классический детерминированный SAST, анализ сто- ронних компонентов SCA и семантиче- ские проверки AI-SAST. SAST начинается не с LLM Самый очевидный способ добавить ИИ в анализ кода – передать репози- торий большой языковой модели и попросить найти уязвимости. Для исследовательской работы такой сце- нарий вполне применим, но промыш- ленный AI-SAST устроен сложнее. В SASTAV исходный код не отправ- ляется в LLM как большой неструкту- рированный массив текста. Сначала работает детерминированный слой: строятся синтаксические деревья, графы вызовов и другие представле- ния программы, проводится предва- рительный анализ и отбираются потенциально интересные участки. После этого языковая модель полу- чает только нужный для конкретной проверки контекст вместе с полити- кой безопасности, содержащей про- стыми человеческими словами опи- санный риск. То есть мы не поручаем LLM работу, которую обычный анализатор выполняет хорошо и надежно. Если можно одно- значно определить источник и приемник данных, построить цепочку вызовов или установить другую структурную харак- теристику программы, это лучше сделать детерминированно. ИИ-модель подклю- чается там, где установленные факты уже нужно интерпретировать с точки зрения безопасности. Хороший пример – нарушения авто- ризации. Для поиска IDOR мало обнару- жить обращение к объекту и проследить цепочку функций. Нужно понять, кто выполняет действие, над каким объ- ектом, какие права у пользователя долж- ны быть и допускает ли такое действие логика приложения. Реализаций подоб- ных сценариев слишком много, чтобы надежно свести их к одному техниче- скому паттерну. Обычно команда AppSec выполняет такую сложную семантиче- скую проверку вручную. Похожая задача возникает при проверке архитектурных требований. В организации могут действовать собственные правила взаимодействия сервисов, использования внутренних интерфейсов или обращения с определенными данными. Архитекторы и специалисты по безопасности хорошо понимают такие ограничения, но выразить их на языке классического SAST бывает сложно. Семантический анализ AI-SAST позволяет приблизить автоматическую проверку к политикам, принятым в кон- кретной системе. В такой логике меняется подход к созданию пользовательских проверок. В классическом SAST специалисту нужно не только понимать природу уязвимости, но и уметь выразить ее через механику конкретного движка – язык правил, ана- лиз потоков данных и внутреннее пред- ставление программы. В AI-SAST акцент смещается на описание риска: при каких условиях он возникает, какой сценарий считать опасным и какие случаи нужно исключить. То есть меньше работы ухо- дит на программирование механики поиска, а больше – на точную формули- ровку того, что именно должна проверить система. LLM может сомневаться, SASTAV – нет Вариативность ответов языковой модели для нас уже вполне привычна – один и тот же дефект можно описать шире или уже, обратить внимание на разные аспекты или по-разному класси- фицировать. В промышленном анализе кода такая свобода становится пробле- мой. Один и тот же фрагмент ИИ-модель может в одном запуске интерпретиро- вать как архитектурную проблему, а в другом – отнести к конкретному классу уязвимостей. Оба вывода могут быть обоснованными, но для системы управления результатами это уже два разных срабатывания. Для промышленного SAST важно, чтобы одна и та же проблема при повтор- ных проверках распознавалась одина- ково, иначе результаты сложно сопо- ставлять между сканированиями, отсле- живать исправления, применять исклю- чения и использовать в контроле рели- зов. Поэтому каждый ответ ИИ-модели в SASTAV проходит дополнительную обработку. Его нужно привести к единому формату, сопоставить с конкретным клас- сом проблем и сделать достаточно устой- чивым, чтобы повторный анализ того же кода давал сравнимый результат. В этом и состоит отличие промыш- ленного AI-SAST от простого анализа кода с помощью LLM. Языковая модель здесь отвечает только за семантическую часть проверки. Все остальное – от отбора релевантных участков кода до подготовки контекста и приведения результата к стабильному формату – берет на себя сам SASTAV. 70 • ТЕХНОЛОГИИ AI-SAST усиливает анализ кода в SASTAV татический анализ безопасности кода (SAST) стал сегодня при- вычным инструментом команд AppSec. Новый уровень AI-SAST не отменяет его, а удачно дополняет классические инструменты анализа. Он выполняет семантическую проверку кода, закрывая те сценарии, которые плохо поддаются детерминированным пра- вилам. Разберемся, как устроен этот подход и что он меняет в привычной архитектуре безопасной разработки. С Антон Михайлов, директор по развитию группы продуктов SASTAV компании ShiftLeft Security Фото: ShiftLeft Security 1 https://sastav.ru/