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