AI-SAST усиливает анализ кода в SASTAV. Какие сценарии закрывает новый семантический слой?

Новость от 29.09.2026

Антон Михайлов, директор по развитию группы продуктов SASTAV, рассказал изданию Information Security о новых возможностях экосистемы SASTAV и ценности сочетания различных методов проверки кода на безопасность.

Статический анализ безопасности кода (SAST) стал сегодня привычным инструментом команд AppSec. Новый уровень AI-SAST не отменяет его, а удачно дополняет классические инструменты анализа. Он выполняет семантическую проверку кода, закрывая те сценарии, которые плохо поддаются детерминированным правилам. Разберемся, как устроен этот подход и что он меняет в привычной архитектуре безопасной разработки.

В последние годы инструменты генеративного ИИ и Open Source кратно увеличили скорость генерации кода. Соответственно, анализируя сегодня код в крупной инфраструктуре с помощью SAST, команда AppSec может получать сотни тысяч срабатываний в сутки. Вручную обработать такой поток, чтобы выделить наиболее критичные уязвимости, просто невозможно. При этом растет число зависимостей, усложняются цепочки поставок. В российском решении SASTAV сочетаются классический детерминированный 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.

При этом SASTAV не привязан к единственной LLM. Заказчик может использовать, например, собственную локальную модель, если она соответствует требованиям системы. Разные модели отличаются по качеству, ресурсным требованиям и поведению на конкретных типах проверок, поэтому AI-SAST должен уметь работать с ними как с заменяемым компонентом.

ASPM не исправит плохое срабатывание

Когда средств анализа становится много, возникает естественное желание собрать их результаты в ASOC или ASPM и уже там управлять рисками. Но платформа верхнего уровня не может компенсировать низкое качество исходных данных. Корреляция и дополнительный контекст помогают уточнять оценку риска, но не снимают требований к точности и обоснованности данных, которые поставляют анализаторы. Поэтому SASTAV обогащает результат анализа еще до передачи во внешнюю систему. Тогда вместе со срабатыванием специалист может получить от AI-SAST объяснение на естественном языке, связанные участки кода, цепочку вызовов и другие данные, на которых основан вывод.

Такой результат гораздо полезнее для последующей корреляции. Верхний уровень получает уже обоснованное срабатывание, которое можно сопоставить с критичностью приложения, его зависимостями и данными других средств анализа.

Часть триажа при этом имеет смысл выполнять еще внутри SASTAV, пока доступен технический контекст. Если известно, что уязвимый участок стороннего компонента недостижим из приложения, это можно учесть до передачи результата в ASOC или ASPM. Если опасный сценарий дополнительно подтвержден семантическим анализом, такое подтверждение, наоборот, дает основание повысить его приоритет.

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

Для интеграции с внешними системами SASTAV предоставляет полный набор API, через который можно получать результаты анализа и связанные с ними данные. Наружу можно передавать как исходные срабатывания, так и результаты их последующей обработки и триажа. SASTAV можно органично встроить в существующие ASOC- и ASPM-процессы.

Развитие ASPM не снижает требований к аналитике SAST. Чем больше источников сходится в одной системе, тем сильнее качество каждого из них влияет на итоговую оценку риска, контроль выпуска и приоритеты команд разработки. Здесь хорошо работает принцип GIGO (Garbage In, Garbage Out). Сложность платформы управления не компенсирует плохие исходные данные. Для зрелого процесса безопасной разработки важно не только собрать результаты в одном месте, но и передать наверх достаточно информации, чтобы каждый вывод можно было проверить и обосновать.

Один из сценариев совместного применения инструментов – уточнение риска уязвимости в сторонней зависимости. SCA выявляет компонент с известной уязвимостью. SAST помогает проследить пути вызовов, а AI-SAST – оценить условия использования уязвимой функциональности, включая проверки и ограничения, которые могут препятствовать опасному сценарию. Это позволяет точнее определить приоритет исправления: наличие уязвимого компонента еще не означает, что уязвимость можно эксплуатировать в конкретном приложении. После постобработки результаты передаются в систему управления рисками вместе с обоснованием и связанными фрагментами кода.

ИИ учится обманывать SAST

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

Команда SASTAV столкнулась с таким сценарием при разборе результатов проверок одного из проектов. Разработчики последовательно передавали отчеты SAST генеративному инструменту и с его помощью исправляли замечания. После нескольких итераций срабатывания исчезли, однако последующая проверка Red Team показала, что уязвимость сохранилась. При разборе выяснилось, что код изменился так, что прежнее детерминированное правило перестало обнаруживать проблему, хотя опасная логика осталась.

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

Чтобы не попадать в эту ловушку, SASTAV развивается сразу в нескольких направлениях, формируя экосистему. Обязательной основой остается детерминированный анализ: он обеспечивает массовые воспроизводимые проверки, поэтому в продукте продолжают развиваться анализ потоков данных и другие классические механизмы SAST. Надстройка AI-SAST дополняет их в сценариях, где для оценки риска недостаточно формальных признаков и требуется понимание семантического контекста. Помимо детерминированных и семантических проверок, важно контролировать сам процесс кодогенерации. Это отдельное направление, которое мы планируем усиливать.

Если генеративный инструмент изменил код так, что конкретное детерминированное правило больше не срабатывает, семантический анализ позволяет проверить, сохранилась ли сама опасная логика. И в обратную сторону – классический анализ снабжает AI-SAST структурными данными, на которых можно строить более устойчивый вывод. А найденную во внешней зависимости уязвимость можно дополнительно оценить с учетом того, как этот компонент фактически используется в приложении.

В результате разные механизмы не конкурируют за роль основного анализатора, а проверяют и уточняют выводы друг друга. Именно в этом SASTAV видит основу гибридного подхода к анализу кода.

Мысль в заключение

Проверка безопасности кода не сводится к поиску универсального анализатора, который должен закрыть все сценарии. Нужно сочетать методы с разной логикой работы: один находит проблему, другой проверяет ее достижимость или смысловой контекст, а итоговая оценка складывается уже из результатов нескольких методов анализа. AI-SAST хорошо вписывается в такую схему. Он помогает там, где формальных правил недостаточно, но не отменяет детерминированные проверки, а скорее делает их еще ценнее как дополнительный способ проверки.

Кстати, чем активнее ИИ участвует в написании и анализе кода, тем рискованнее полагаться лишь на единственный способ его проверки.

Источник: InformationSecurity