- В марте нашли критичные уязвимости в Spring AI и ONNX.
- В Spring AI всплыли SQL‑инъекции и JSONPath‑инъекции в сценариях работы с БД и данными.
- В ONNX можно обойти проверку доверия при загрузке моделей черезonnx.hub.load.
- Для ИТ,ИБ это сигнал не только «пропатчить», а навести порядок в ИИ‑стеке: инвентаризация, правила для ИИ‑проектов, отдельный контур безопасности.
Уязвимости в Spring AI и ONNX: как дыры в ИИ‑фреймворках превращаются в утечки данных и чужие модели
Вместо длинной преамбулы
ИИ‑фреймворки привыкли воспринимать как что‑то «про математику».Где‑то внутри крутятся модели, рядом лежат.onnx‑файлы, а сверху над этим аккуратный API.
В реальных системах всё веселее.Весной в обзорах уязвимостей сразу всплыли критичные баги в Spring AI и ONNX: SQL‑инъекции, JSONPath‑инъекции и обход проверки доверия при загрузке моделей.То есть классика старого доброго веба тихо переезжает в слой ИИ, который во многих компаниях живёт в режиме пилотов и «у нас там ничего критичного».
Если вы отвечаете за ИТ, ИБ или цифровую трансформацию, это хороший момент взглянуть на свои ИИ‑проекты не как на игрушки, а как на нормальные боевые системы.
Что нашли в Spring AI и ONNX, по‑человечески
Без ныряния в каждую CVE по строчке, соберём общую картинку.
Spring AI помогает прикрутить LLM и прочие модели к приложениям на базе Spring.Под капотом у него есть работа с базами и данными. В свежих уязвимостях всплыли:
- SQL‑инъекция в сценариях, где Spring AI ходит в базу (например, через интеграцию с MariaDB). Можно подмешать свой SQL и вытащить лишнего.
- JSONPath‑инъекция: если выражение собирают из пользовательского ввода без нормальной фильтрации, появляется возможность читать или править чужие данные в ИИ‑приложении.
Переводим на нормальный язык: рискуют логи запросов, истории диалогов, результат генераций, профили пользователей и всё, что живёт рядом с этим функционалом. Плюс многопользовательские системы, где один клиент может подсмотреть данные другого.
ONNX — это про формат моделей и удобную загрузку черезonnx.hub.loadи подобные штуки.В одной из свежих дыр оказалось, что проверку доверия при загрузке модели можно обойти и подсунуть не тот артефакт, на который вы рассчитывали.
Дальше всё зависит от вашей архитектуры:
- где‑то это «просто» подмена модели (другая логика, другие веса, странное поведение сервиса),
- где‑то начинается веселье посерьёзнее: в цепочке вокруг модели могут быть конвертеры и обработчики, в которых при удачном стечении обстоятельств возможен уже и RCE.
В итоге у нас два симптома:Spring AI показывает, что ИИ‑обвязка может дырявить данные,ONNX напоминает, что модели — такой же поставляемый артефакт, как бинарь или контейнер.
Где такие штуки обычно прячутся в компании
Часто на вопрос «у нас Spring AI или ONNX есть?» ответ звучит примерно так: «ну, наверное, где‑то у разработчиков, но в прод это точно не попадало».
Раскопки обычно показывают другое.
Spring AI чаще всего всплывает в:
- внутренних ассистентах для сотрудников (поиск по документам, помощь в заявках, подсказки в CRM);
- экспериментальных сервисах, которые тихо доросли до критичных: начинали как прототип «для двух отделов», а теперь на них опирается половина компании;
- интеграциях между классическим Spring‑приложением и внешними/внутренними LLM.
ONNX встречается в:
- рекомендательных и скоринговых сервисах, которые никто не трогал годами, но они продолжают крутиться в проде;
- пайплайнах MLOps, где команда данных использует ONNX как общий язык между разными фреймворками;
- покупных продуктах, где ONNX живёт внутри, а снаружи вы видите просто «коробочное решение» с красивым интерфейсом.
То есть не обязательно вы лично «разрешали» Spring AI и ONNX.Решение могло родиться в ML‑команде, у интеграторов или у вендора.В проде при этом всё уже работает и трогать страшно.
Почему это история не только для CISO
С точки зрения ИБ классический план понятен: найти, пропатчить, закрыть риски.Но для CDTO/CTO здесь есть более широкий пласт задач.
1. Выделить ИИ‑инфраструктуру в отдельный объект
Пока ИИ‑фреймворки лежат в одной куче с «прочими библиотеками», они всегда проигрывают в приоритете.Нужна отдельная полка в архитектуре и регламентах: Spring AI, ONNX, LLM‑шлюзы, хабы моделей и подобные вещи.
Простой эффект:
- появляется отдельная зона ответственности,
- появляются явные правила,
- НКО и «быстрые пилоты» не пролетают мимо стандартов только потому, что это ИИ и «мы тут экспериментируем».
2. Провести инвентаризацию ИИ‑стека, а не «поймать конкретную CVE»
Список «где у нас Spring AI и ONNX» — полезная штука, но этого мало.Нужен нормальный каталог:
- какие ИИ‑фреймворки и хабы используются;
- кто владелец каждой штуки (команда, человек, роль);
- какие данные через них проходят;
- где они стоят: прод, тест, песочница, пилот.
Без этого любая новая уязвимость превращается в квест «пойди туда, не знаю куда».
3. Переключить режим для ИИ‑проектов
Пока ИИ‑инициативы живут в режиме «сначала покажем value, потом будем думать про безопасность», ИБ и архитектура всегда будут подключаться в последний момент.
Удобный рубеж: как только ИИ‑сервис полез в реальные данные клиентов или сотрудников, он переезжает в ту же лигу, что CRM, биллинг и прочие взрослые системы.Со всеми вытекающими: требования, ревью, мониторинг, патчи.
4. Поменять взаимодействие CDTO/CTO — CISO — ML/Dev
Сейчас выбор фреймворков часто принимает команда разработки или ML, а безопасность подключается затем, когда «уже всё работает, не ломайте».
Задача на управленческом уровне — договориться:
- какие ИИ‑компоненты считаются стратегическими (Spring AI, ONNX, прокси к LLM, реестры моделей);
- кто их согласует;
- по каким минимальным требованиям (обновляемость, политика CVE, логирование, возможность ограничить права и т.п.) их пропускают в прод.
Чек‑лист по Spring AI и ONNX «на неделю»
Если хочется что‑то сделать, можно взять минимальный план.
- Найти проекты, где он используется: по зависимостям, по репозиториям, через короткий опрос ключевых команд.
- Для каждого проекта ответить на два вопроса:какие данные доступны через этот сервис (БД, логи, файловые хранилища, внешние API);есть ли там многопользовательский сценарий (один клиент/подразделение может случайно увидеть данные другого).
- Запланировать обновление Spring AI до версий с закрытыми уязвимостями. Если обновить «здесь и сейчас» страшно, хотя бы выделить ответственных и дедлайны.
- Добавить в автотесты базовые проверки на инъекции (SQL и JSONPath) для сервисов, где есть взаимодействие с данными через Spring AI.
- Найти все места, где:используетсяonnx.hub.loadили похожая логика загрузки моделей;есть автоматическое обновление моделей «из облака» или из хаба.
- Ограничить источники моделей:завести белы�� список репозиториев и допустимых моделей;отключить автоматическую загрузку из неизвестных мест.
- Для решений от вендоров:запросить у них позицию по уязвимости и план обновлений;задать прямые вопросы про валидацию моделей и логи операций.
- Добавить ИИ‑фреймворки и хабы в общий перечень критичных компонентов, за которыми следят при появлении новых уязвимостей.
- Назначить конкретного человека/роль, которая отвечает за мониторинг уязвимостей именно в ИИ‑стеке, чтобы это не терялось между ОС и веб‑сервисами.
- Описать минимальные требования к ИИ‑проектам в документах: архитектурных принципах, стандартах по ИБ и DevSecOps.
Вместо вывода
Первые ИИ‑кейсы живут на энтузиазме: «сделали ассистента, всем понравилось, поехали дальше».Через пару лет к этому добавляются более приземлённые истории: утечки, уязвимости, вопросы регуляторов.
Spring AI и ONNX в мартовских выпусках по безопасности — хороший маркер, что ИИ‑слой дорос до нормальной взрослой жизни.Разница только в том, что под этим слоем теперь проходят логины клиентов, договоры, чаты сотрудников и всё, что раньше аккуратно лежало по разным системам.
Лучший момент привести ИИ‑инфраструктуру в чувство — пока на неё ещё не прилетел свой большой публичный инцидент.Заодно это хороший способ показать бизнесу, что ИИ в компании — не только про красивые демо, но и про внятную инженерную и управленческую работу.
