SAST для BSL и ИИ: почему статический анализ кода и нейросеть надо связывать

Пятница, вечер, релиз в понедельник. Разработчик на внедрении ЗУП 3.1 у крупного заказчика получает задачу: сделать обработку, которая выгружает свод по сотрудникам во внешний сервис согласований. Времени в обрез. Он открывает облачный ассистент для разработки, описывает задачу словами и через минуту получает готовый модуль на BSL: запрос к регистру накопления, обход выборки, сборка JSON, отправка по HTTP. На тестовой базе всё отрабатывает, обработка уходит в хранилище конфигурации.

Через неделю на код-ревью ведущий разработчик находит три вещи. Текст запроса собирается конкатенацией строк, и наименование подразделения приходит в него из внешнего параметра без экранирования: это внедрение в язык запросов 1С. Чтобы «не возиться с правами», ассистент обернул чтение в УстановитьПривилегированныйРежим(Истина), и обработка видит все подразделения в обход RLS, а не только доступные пользователю. А при отладке в журнал регистрации пишется полный дамп выгрузки: ФИО, оклады, СНИЛС.

Ни одна из трёх проблем не синтаксическая. Тесты зелёные, обработка «работает». Просто «работает» и «безопасно» это разные оси, а ассистента просили только про первую.

Почему так выходит регулярно

Это не история про невнимательного джуна, это структурная особенность. Нейросеть генерирует BSL, оптимизируя правдоподобие и «скомпилировалось и запустилось», а не соблюдение инвариантов безопасности. Она не знает, что этот конкретный регистр содержит ПДн, что на справочнике подразделений висит RLS и что журнал регистрации не место для окладов.

Цифры это подтверждают. По отчёту Veracode за 2025 год, где проверяли код более чем сотни больших языковых моделей на 80 типовых задачах, около 45% сгенерированного кода не проходит проверки безопасности. Отдельная деталь прямо про наш случай: защититься от инъекции в лог (CWE-117) модели не смогли в 88% случаев. То есть сценарий «ассистент что-то пишет в журнал» почти гарантированно порождает уязвимость, и обработка из истории выше это ровно он.

Важнее общая динамика. Модели заметно научились писать синтаксически корректный, рабочий код, но безопаснее писать не стали: доля дефектов держится на месте и почти не зависит от размера и свежести модели. «Компилируется» растёт, «безопасно» стоит.

Встроенного языка 1С в выборке Veracode не было, там Java, JavaScript, Python и C#. Но считать BSL исключением нет оснований, скорее наоборот: обучающих примеров на BSL у моделей несоизмеримо меньше, чем на мейнстримных языках, поэтому модель ещё охотнее достраивает правдоподобное вместо корректного. На практике к дефектам безопасности добавляется свой 1С-набор: галлюцинации имён реквизитов и полей, битые GUID предопределённых элементов, обращения к несуществующим методам БСП, кривая СКД, запрос внутри цикла по выборке.

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

SAST для BSL уже есть, но живёт отдельно

Хорошая новость: статический анализ BSL это зрелая область. Есть открытые линтеры с сотнями диагностик, есть коммерческие SAST-платформы для BSL с отдельным профилем аудита безопасности, встроенные в CI, есть официальный статконтроль по стандартам вендора. Внедрение в запрос, привилегированный режим не по делу, небезопасные Выполнить и Вычислить, секреты прямо в коде, всё это ловится статически, детерминированно, по правилам.

И вот здесь ключевое отличие от модели. Статанализатор не вероятностный. Если правило говорит, что конкатенация внешнего значения в текст запроса это риск, оно сработает всегда, одинаково, на любом прогоне. Рядом с вероятностным генератором появляется независимый детерминированный оракул: один пишет, второй не верит на слово. Именно этой второй половины в типовом сценарии «ИИ пишет BSL» обычно и нет.

Плохая новость: SAST для BSL почти всегда запускается отдельно от того, кто и что пишет. Анализ идёт в CI, после коммита, по расписанию, на сервере сборки. К моменту, когда сканер подсветит инъекцию, код уже в хранилище, а иногда и на проде. Разработчик, сгенерировавший его, переключился на другую задачу. А сама нейросеть результат анализа не увидит вовсе: она отдала код и забыла про него. Петля разорвана, и именно в этот зазор проваливаются инъекции, обходы RLS и утечки в логи.

Закрыть зазор тем же ИИ, попросив его «проверь свой код на уязвимости», не выйдет. Модель, породившая дефект, ревьюит его теми же слепыми зонами: тот же пробел в знаниях даёт и ошибку, и уверенное «здесь всё в порядке». Из самопроверки независимой проверки не получается, для неё и нужен инструмент, стоящий вне модели.

Что значит связать статанализатор и нейросеть

Связать означает поставить статический анализ в тот же момент, где рождается код, а не через неделю на ревью. Как только ассистент предложил BSL, до того как код коснётся базы или хранилища, его прогоняет анализатор, а находки возвращаются обратно: нейросети, чтобы переписать, или разработчику, чтобы принять решение.

Чтобы петля работала, а не заваливала человека шумом, нужны две вещи.

Первая: приоритизация по серьёзности. Не все находки равнозначны. Аудит безопасности кода 1С по CVSS проставляет каждой проблеме числовой вес: внедрение в язык запросов на регистре с ПДн это высокий балл, придирка к стилю низкий. CVSS 3.1 даёт оценку от 0 до 10 и уровни (низкий, средний, высокий, критический), и по ним выстраивается политика: высокие блокировать, средние показывать предупреждением, низкие копить в отчёт. Приоритет по риску, а не по числу замечаний. Ассистент получает не абстрактный «плохой код», а конкретный ранжированный список того, что чинить первым.

Вторая: машиночитаемый формат. Если BSL-анализатор отдаёт находки в SARIF (открытый стандарт OASIS для результатов статического анализа), они без самописных парсеров ложатся и в петлю с ИИ, и в редактор разработчика, и в дашборд службы безопасности. Одну и ту же находку видит нейросеть, видит человек в IDE, видит ИБ: не три разных отчёта, а один источник правды. И вернуть её модели можно не размытым «перепиши, тут что-то не так», а структурированным «строка N, правило R, уровень высокий, вот причина».

В связке цикл выглядит так: ИИ сгенерировал, анализатор проверил, вернулись находки с оценкой CVSS в формате SARIF, ИИ переписал или человек принял решение, и только потом код идёт дальше. Инъекцию из истории выше ловят на генерации, а не на ревью через неделю.

Где это связывать: в управляемом шлюзе

Технически петлю можно собрать и скриптами. Но естественная точка, где её замкнуть, это шлюз между ИИ-ассистентом и базой 1С. Там уже проходит каждый запрос ассистента, там уже принимаются решения о доступе, туда логично встроить и проверку кода.

Feenlace MCP-1C это управляемый MCP-шлюз для 1С:Предприятия, один автономный бинарник на ваших серверах. Он подключает ИИ-ассистентов (Claude, ChatGPT и другие) к инфобазам через слой политик. Для нашей задачи важно вот что: SAST для BSL с оценкой по CVSS 3.1 и отчётами SARIF стоит в том же контуре, что и доступ; ролевые профили RBAC на самом шлюзе выдают ассистенту доступ по назначенной роли, а не ко всей базе целиком; полный аудит фиксирует каждое действие ИИ (кто спросил, к какой базе, что разрешено или заблокировано); а продовые базы держатся в жёстком read-only с fail-closed, так что сгенерированный код физически не запишет в прод через шлюз.

Всё это остаётся внутри периметра: код, данные, результаты анализа наружу не уходят. Как устроена локальная граница и почему данные не покидают контур, подробно разобрано в отдельной статье про on-premise-развёртывание 1С.

У истории есть и юридическое измерение. Уязвимый код, который пишет ФИО и СНИЛС в журнал или выгружает их вовне, это уже не техдолг, а зона ответственности по 152-ФЗ. С 30 мая 2025 года поправки в КоАП (закон 420-ФЗ) заметно подняли ставки: за первичную утечку штраф от 3 до 15 млн рублей в зависимости от объёма данных, за повторную оборотный штраф от 1% до 3% годовой выручки (не менее 20 млн рублей). Держать код, данные и их анализ в своём контуре и сокращать то, до чего вообще дотягивается ИИ, эту экспозицию снижает. Это не «соответствие из коробки» и не сертификат, это уменьшение поверхности риска, что при таких суммах уже немало.

С чего начать

Если вы пробуете подключать ИИ к 1С, ставьте статический анализ сразу в тот же контур, а не рядом с ним. Открытую (бесплатную, с открытым исходным кодом) редакцию Feenlace MCP-1C можно развернуть локально и посмотреть, как ассистент вообще работает с вашими базами внутри контура. Сам аудит безопасности BSL с оценкой по CVSS 3.1 и отчётами SARIF, то есть та половина связки, что проверяет код, доступен в старших редакциях. Без обещаний серебряной пули: статанализ не заменит ревью и не выловит логические дыры, но внедрение в запрос, лишний привилегированный режим и оклад в журнале он поймает в момент генерации, а не на проде. Подробности и сравнение редакций на feenlace.ru.