Инструменты статического анализа давно стали обязательной частью DevSecOps-конвейера. Они быстро проверяют код, хорошо масштабируются, дают повторяемый результат и позволяют находить типовые классы уязвимостей ещё до выхода продукта в эксплуатацию.
- 1. Введение
- 2. Где классический SAST остаётся незаменимым
- 3. Где начинается зона семантики
- 4. Почему нельзя просто заменить SAST прямым LLM-анализом
- 5. Как работает гибридный подход
- 6. От «напиши правило» к «опиши риск»
- 7. Какие проверки становятся доступнее
- 8. Что это даёт заказчику
- 9. Где AI-SAST не нужен
- 10. Выводы
Введение
Классический SAST хорошо работает там, где риск можно описать через технический паттерн: опасную функцию, небезопасный API, некорректную санитизацию (очистку, проверку и фильтрацию), источник и приёмник данных, стандартный taint-flow. Именно поэтому такие инструменты стали промышленной основой безопасной разработки: они подходят для регулярных проверок, интеграции в CI/CD и автоматического контроля качества кода.
Но у классического SAST есть естественная граница применимости. Он хорошо отвечает на вопрос: «Есть ли в коде технический паттерн, похожий на уязвимость?». Однако часть реальных рисков определяется не отдельной строкой кода, а контекстом: ролью пользователя, принадлежностью объекта, состоянием бизнес-процесса, связью между несколькими эндпоинтами или внутренними правилами конкретной организации.
Именно здесь появляются классы проблем, которые трудно описать только через сигнатуры, источники, приёмники и стандартные потоки данных: IDOR, нарушения контроля доступа, ошибки в бизнес-логике, insecure design (т. н. «небезопасный дизайн»), проблемы изоляции между клиентами. Такой код может выглядеть технически корректным, но при этом реализовывать опасный сценарий.
На первый взгляд кажется, что эту задачу можно полностью передать большой языковой модели: загрузить репозиторий и попросить найти слабые места. Но в промышленной эксплуатации такой подход быстро упирается в ограничения контекста, стоимости, повторяемости и доказательности результата.
Поэтому более зрелая архитектура выглядит иначе: детерминированный SAST остаётся фундаментом анализа, а ИИ-слой подключается там, где действительно нужна семантика.
Где классический SAST остаётся незаменимым
Классический SAST не теряет актуальности с появлением ИИ. Наоборот, в гибридной архитектуре он становится ещё важнее, потому что именно он обеспечивает промышленную основу анализа.
Его сильные стороны — скорость, масштабируемость и воспроизводимость. Один и тот же код при одинаковых настройках должен давать одинаковый результат. Для CI/CD это критично: Security Gate не может зависеть от случайности, настроения модели или вариативности ответа. Если проверка блокирует релиз, её результат должен быть объяснимым, повторяемым и технически проверяемым.
Классический SAST хорошо закрывает массовые проверки: стандартные CWE, типовые ошибки разработки, известные опасные конструкции, небезопасные вызовы, нарушения правил работы с данными. Он может быстро проходить большие кодовые базы, работать по расписанию, запускаться при каждом запросе на слияние (merge request) и давать стабильный сигнал для разработчиков и AppSec-команд.
Именно поэтому вопрос не в том, чтобы заменить классический SAST нейросетью. Такой подход был бы и технически, и экономически слабым. Вопрос в другом: как расширить возможности SAST там, где формального паттерна уже недостаточно.
Где начинается зона семантики
Реальные уязвимости не всегда выглядят как очевидно опасный код. Иногда проблема находится не в функции, не в строке и даже не в одном файле, а в сценарии.
Например, IDOR редко сводится к тому, что идентификатор объекта передаётся в URL. Сам факт передачи ID ещё не означает уязвимость. Важны другие вопросы: проверяется ли принадлежность объекта текущему пользователю, учитывается ли роль, есть ли граница между клиентами, можно ли получить доступ к объекту через альтернативный эндпоинт.
Похожая ситуация возникает с нарушениями контроля доступа. Код может содержать проверку авторизации, но она может быть неполной, выполняться не на том уровне или не учитывать конкретное действие пользователя. В одном месте доступ проверяется, в другом — нет. Формально всё выглядит корректно, но на уровне сценария появляется обход.
Ещё сложнее с insecure design и ошибками бизнес-логики. Например, действие можно выполнить в неправильном статусе объекта, обойти согласование через другой маршрут, повторно использовать одноразовую операцию или нарушить последовательность бизнес-процесса. В таких случаях уязвимость определяется не синтаксисом, а смыслом происходящего.
Классический SAST ищет технические конструкции. Но для таких сценариев важно понять отношения между пользователем, объектом, ролью, состоянием и действием. Это уже зона семантики.
Почему нельзя просто заменить SAST прямым LLM-анализом
Идея использовать LLM как единственный механизм анализа всего репозитория выглядит привлекательно только на уровне концепции. На практике она быстро сталкивается с несколькими ограничениями.
Первое ограничение — контекст. Даже большие контекстные окна не решают проблему анализа промышленных кодовых баз. Репозиторий может содержать миллионы строк кода, несколько языков, десятки сервисов, фреймворков и внутренних библиотек. Модель не может эффективно удерживать весь этот объём как единую, проверенную и структурированную картину.
Второе ограничение — стоимость. Полный анализ крупных репозиториев через LLM становится дорогим, особенно если речь идёт не об одноразовой проверке, а о регулярном использовании в CI/CD. Без предварительной фильтрации и подготовки контекста такая архитектура плохо масштабируется экономически.
Третье ограничение — повторяемость. Для промышленного AppSec важно, чтобы результат проверки был стабильным. Если один запуск находит проблему, а следующий при тех же условиях её не показывает, такой сигнал сложно использовать как основание для автоматического решения в Security Gate.
Четвёртое ограничение — доказательность. Недостаточно сказать, что «модель считает это уязвимостью». Нужно показать конкретные участки кода, объяснить путь данных, связать действие с риском, отделить подтверждённый сценарий от предположения и дать разработчику понятную основу для исправления.
Поэтому подход «передать весь код в LLM и ждать результата» не является промышленной заменой SAST. Он может быть полезен для исследовательских сценариев, ручной экспертизы или точечной проверки гипотез, но плохо подходит как основной механизм массового анализа кода.
Как работает гибридный подход
Гибридный SAST строится на другой логике. Детерминированный движок остаётся фундаментом: он разбирает код, строит структуры, анализирует связи между файлами и функциями, определяет потенциально значимые участки, находит технические паттерны и формирует первичный набор кандидатов.
Быстрые и формализуемые проверки закрываются классическим SAST. Это стандартные классы уязвимостей, типовые потоки данных, известные опасные конструкции, правила безопасной разработки, которые можно строго описать и воспроизвести.
ИИ-слой подключается не ко всему коду подряд, а к тем участкам, где действительно нужен дополнительный контекст. Его задача — не заменить детерминированный анализ, а помочь там, где требуется интерпретация: понять сценарий, проверить связь между пользователем и объектом, оценить роль бизнес-логики, учесть исключения и негативные критерии.
Такой подход снижает нагрузку на LLM, делает анализ экономически управляемым и повышает качество результата. Модель работает не в пустоте и не со всем репозиторием сразу, а внутри подготовленного контекста, который уже собран классическим анализатором.
В результате появляется более сильная архитектура: SAST обеспечивает масштаб, скорость и повторяемость, а ИИ-слой добавляет семантическую интерпретацию сложных сценариев.
От «напиши правило» к «опиши риск»
Один из самых важных эффектов гибридного подхода — изменение модели кастомизации.
В классическом SAST создание сложного правила часто требует отдельной инженерной экспертизы. Нужно знать язык описания правил конкретного движка, понимать структуру AST, описывать источники и приёмники данных, учитывать особенности фреймворка, тестировать правило и отдельно работать с ложными срабатываниями.
Это сильный, но дорогой путь. Он хорошо подходит для формализуемых проверок, но становится сложным, когда речь идёт о внутренних требованиях конкретной компании, нестандартных архитектурных ограничениях или уникальных бизнес-сценариях.
Гибридный подход позволяет сделать следующий шаг: описывать не только техническое правило, но и сам риск на естественном языке.
Например, эксперт может описать, что нужно найти нарушение авторизации в конкретном типе эндпоинтов, указать, какие проверки доступа считаются достаточными, какие случаи не нужно считать уязвимостью, какие роли и статусы объекта важны для анализа, какие внутренние фреймворки используются в компании.
Такое описание становится основой для проверки. ИИ-слой помогает интерпретировать сценарий, критерии подтверждения и негативные критерии, а детерминированная часть обеспечивает управляемую работу с кодом.
Это не отменяет инженерной дисциплины. Наоборот, хороший AI-SAST должен требовать доказательности: конкретные места в коде, объяснение сценария, указание причины, по которой находка подтверждается, и явное отделение реального риска от предположения.
Какие проверки становятся доступнее
Гибридный подход особенно полезен там, где уязвимость зависит от смысла сценария.
В случае IDOR важно понять, связан ли объект с текущим пользователем и проверяется ли эта связь перед выполнением действия. Недостаточно найти передачу идентификатора. Нужно понять, кто может запросить объект, кому он принадлежит и есть ли контроль доступа на уровне бизнес-операции.
В случае broken access control важно анализировать не только наличие проверки авторизации, но и её полноту. Проверка может быть реализована в middleware, сервисном слое, контроллере или внутреннем фреймворке. Иногда она есть, но не покрывает конкретное действие. Иногда один эндпоинт защищён, а другой позволяет выполнить тот же сценарий в обход.
В случае insecure design риск может быть связан с нарушением последовательности процесса. Например, пользователь может выполнить действие до согласования, повторить одноразовую операцию, изменить объект в закрытом статусе или обойти обязательный этап проверки через альтернативный маршрут.
В случае tenant isolation важно учитывать границы между клиентами или организациями. Код может корректно работать для одного пользователя, но не проверять принадлежность данных к нужному tenant. Такие проблемы сложно свести к одному универсальному паттерну, потому что модель владения данными часто зависит от архитектуры конкретного продукта.
Во всех этих случаях гибридный подход помогает анализировать не только конструкцию в коде, но и прикладной сценарий риска.
Что это даёт заказчику
Для заказчика ценность AI-SAST не в том, что «нейросеть ищет уязвимости». Такая формулировка слишком упрощает задачу. Реальная ценность — в расширении покрытия тех классов рисков, которые раньше было трудно автоматизировать.
Во-первых, появляется возможность проверять внутренние требования безопасности. У крупных организаций часто есть собственные правила: как должны работать роли, какие операции запрещены, какие статусы объекта критичны, какие архитектурные ограничения нельзя нарушать. Универсальный набор CWE не покрывает такие требования полностью.
Во-вторых, снижается порог входа в кастомизацию. Чтобы описать новый риск, не всегда нужен узкий специалист по DSL конкретного SAST-движка. В ряде сценариев достаточно, чтобы эксперт по безопасности, архитектор или владелец процесса описал риск, критерии подтверждения и негативные критерии на понятном языке.
В-третьих, повышается качество сигнала. Сложная находка должна быть не просто названием правила, а объяснённым сценарием: где находится проблема, почему она может быть опасной, какие условия должны выполняться и почему это не является ложным срабатыванием.
В-четвёртых, такой подход лучше подходит для зрелого Security Gate. Если на входе в систему управления уязвимостями попадает не поток разрозненных оповещений, а более осмысленный сигнал, дальнейшая приоритизация становится точнее. Команда лучше понимает, что действительно должно блокировать релиз, а что можно отложить или принять как допустимый риск.
Где AI-SAST не нужен
Важно подчеркнуть: AI-SAST не должен применяться ко всему подряд.
Если задача хорошо решается классическим SAST — её не нужно переносить в ИИ-слой. Массовые проверки, типовые CWE, стандартные опасные функции, простые потоки данных, правила кодирования и воспроизводимые технические паттерны эффективнее проверять детерминированно.
Использовать ИИ для таких задач — значит усложнять архитектуру, увеличивать стоимость и снижать предсказуемость без значимого выигрыша в качестве.
Зрелый подход состоит не в том, чтобы заменить весь анализ нейросетью, а в том, чтобы правильно разделить ответственность между слоями. Классический SAST отвечает за масштаб, скорость и повторяемость. AI-SAST — за сложные сценарии, контекстную интерпретацию и снижение порога кастомизации.
Выводы
ИИ не заменяет классический анализ кода. В промышленной архитектуре он должен работать не вместо SAST, а вместе с ним.
Классический SAST остаётся фундаментом: он быстро и воспроизводимо ищет технические паттерны, работает в CI/CD, масштабируется на большие кодовые базы и даёт стабильный сигнал для автоматических проверок.
AI-SAST добавляет следующий слой: помогает анализировать опасные сценарии, учитывать бизнес-контекст, описывать внутренние требования безопасности и проверять те классы рисков, которые сложно выразить только через сигнатуры и стандартные потоки данных.
Поэтому главный вопрос звучит не «SAST или ИИ». Правильный вопрос — какую часть анализа должен выполнять детерминированный движок, а где нужен семантический слой.
Коротко это можно сформулировать так: классический SAST ищет технические паттерны, а гибридный подход помогает находить опасные сценарии в логике приложения.
