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

При этом 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 хорошо вписывается в такую схему. Он помогает там, где фор- мальных правил недостаточно, но не отменяет детерминированные проверки, а скорее делает их еще ценнее как дополнительный способ проверки. Кстати, чем активнее ИИ участвует в написании и анализе кода, тем риско- ваннее полагаться лишь на единствен- ный способ его проверки. l • 71 БЕЗОПАСНАЯ РАЗРАБОТКА www.itsec.ru АДРЕСА И ТЕЛЕФОНЫ SHIFTLEFT SECURITY см. стр. 86 NM Реклама