Разработчик добавляет генерацию карточек, аватаров или превью для страниц. AI-помощник быстро предлагает обработчик изображений, принимает SVG, собирает картинку на сервере и возвращает результат. Снаружи это выглядит как обычная продуктовая функция, но внутри может появиться опасная обработка недоверенного формата.
Уязвимости в рендеринге изображений показывают, что проблема не ограничивается одной библиотекой. Если сервер обрабатывает SVG или похожий гибкий формат, он получает не просто картинку, а сложный документ с внешними ссылками, стилями и неожиданными путями исполнения. AI-кодогенерация может размножить небезопасный шаблон по нескольким репозиториям.
Задача AppSec — проверять не только наличие патча, но и сам паттерн: откуда приходят изображения, кто их контролирует, где выполняется рендеринг, какие системные вызовы доступны и что попадёт в журнал при ошибке.
Такой обзор нужен командам, которые принимают AI-сгенерированный код быстрее, чем успевают выстроить правила ревью. Обработчик изображения должен считаться серверной точкой риска, а не декоративной функцией.
Какие шаблоны искать в коде
Опасный паттерн часто выглядит безобидно: функция принимает пользовательский URL или SVG, передаёт его в генератор изображения и возвращает файл. Если нет проверки источника, типа, размера и разрешённых возможностей формата, обработчик становится входом в серверную среду.
AI-помощник может предложить удобный пример без ограничения формата и без изоляции рендеринга. Поэтому ревью должно искать не конкретную строку, а класс поведения.
- приём SVG из внешнего источника;
- рендеринг на сервере без изоляции;
- загрузка внешних ресурсов при обработке;
- нет ограничения размера и времени;
- ошибки отрисовка-процесса не попадают в SOC;
- обработчик доступен без ограничение частоты;
- нет отдельного теста на недоверенный файл.
Как закрыть риск без запрета функции
Не всегда нужно убирать генерацию изображений. Достаточно вынести рендеринг в изолированную среду, принимать только разрешённые типы, ограничить размер, отключить внешние обращения и обновить библиотеку. Для пользовательского SVG лучше использовать строгую очистку или конвертацию в безопасный промежуточный формат.
Приёмка AI-сгенерированного обработчика должна включать негативные тесты. Если тест проверяет только красивую картинку, он не видит безопасность.
- запретить недоверенный SVG там, где он не нужен;
- использовать разрешающий список MIME и расширений;
- вынести модуль отрисовки в песочницу;
- запретить внешнюю сеть при рендеринге;
- ограничить размер, время и память;
- добавить тесты на вредный формат;
- обновить зависимость и проверить все похожие точки обработки.
Какие события должны остаться в журнале
Расследование становится управляемым только тогда, когда событие можно восстановить без догадок. Для AI-системы важно хранить не только итоговый ответ, но и источник контекста, решение политики, вызванный инструмент, пользователя, устройство и причину разрешения или отказа.
Чувствительные поля лучше сохранять как метку класса, хеш и ссылку на источник, а не как полный текст. Так журнал помогает расследованию и не превращается в новую утечку.
- user_id и роль пользователя;
- device_id и доверенность устройства;
- source_system и класс источника;
- model_version и policy_id;
- resource_id и уровень чувствительности;
- action_type и итог операции;
- risk_score и главные признаки;
- сквозной_идентификатор для связи событий.
Проверка перед включением блокировки
Сначала контроль запускается в режиме наблюдения. Команда собирает нормальные и подозрительные сценарии, проверяет ложные срабатывания и только затем включает блокировку для критичных действий. Если сразу включить жёсткое правило, бизнес быстро потребует постоянные исключения.
Для каждого исключения нужны владелец, срок действия и причина. Исключение без срока почти всегда становится скрытым обходом политики.
- запустить правило в режиме наблюдения;
- проверить нормальный рабочий процесс;
- проверить подозрительный сценарий;
- разделить предупреждение и остановку;
- назначить владельца исключения;
- описать аварийный откат;
- пересматривать шумные правила каждую неделю.
Метрики, которые показывают пользу
Хорошая метрика показывает, стал ли риск заметнее и быстрее ли команда реагирует. Количество правил само по себе ничего не доказывает: десять шумных правил хуже одного точного контроля, который даёт доказательства и понятное действие.
Для AI-сценариев особенно полезно измерять связку из нескольких событий. Один запрос может быть нормальным, но запрос плюс доступ к секрету, новый внешний домен и создание токена уже должны менять приоритет.
- среднее время от сигнала до первичный разбор;
- доля событий с полным набором журналов;
- число подтверждённых инцидентов;
- количество постоянных исключений;
- скорость отзыва ключей;
- доля тестов без ручной доработки.
Карта ответственности
Владелец продукта отвечает за допустимый сценарий, SOC — за расследование, AppSec — за проверку кода и зависимостей, инфраструктурная команда — за сеть, ключи и журналы, а руководитель риска — за остаточный риск.
Если роли не определены заранее, первый инцидент превращается в переписку. Карта ответственности должна лежать рядом с описанием системы и обновляться после каждого изменения архитектуры.
- SOC определяет приоритет и собирает доказательства;
- AppSec проверяет код и настройки;
- владелец данных оценивает чувствительность;
- инфраструктура отзывает ключи и меняет сеть;
- юридическая функция оценивает уведомления;
- руководитель риска утверждает исключения.
Контроль AI-помощника при создании кода
Если обработчик изображения был предложен AI-помощником, ревью должно быть строже, а не мягче. Помощник может правильно собрать рабочую функцию и одновременно пропустить ограничения формата, сети и времени. Поэтому команда добавляет отдельный чек-лист для всех мест, где код принимает файлы, ссылки или изображения от пользователя.
Полезна простая политика: AI-сгенерированный код, который обрабатывает недоверенный ввод на сервере, не сливается без негативных тестов и проверки владельцем безопасности. Это не тормозит разработку, а делает ускорение управляемым.
- пометить обработчики недоверенных файлов;
- добавить негативные тесты в проверку изменений;
- сравнить AI-предложение с внутренним шаблоном;
- запретить внешнюю сеть при отрисовке;
- логировать ошибки модуля отрисовки;
- проверить похожие функции в соседних проектах;
- назначить владельца исправления.
