КиберЩит
ИИ-активы в репозитории: как закрыть секреты до публикации кода
📋 Кратко
Репозиторий с ИИ-компонентом хранит не только исходный код. В нём могут находиться модели, адаптеры, промпты, наборы данных, конфигурации, ноутбуки и токены доступа. Разбираем, как составить реестр активов, проверить секреты до публикации, закрыть опасные отправки и отреагировать на уже найденную утечку.
🔍 Что считать ИИ-активом в репозитории
ИИ-актив — любой артефакт, который участвует в работе ИИ-системы. Это не только файл с весами модели. В репозитории также лежат адаптеры, промпты, конфигурации инференса, обучающие данные, ML-библиотеки, ноутбуки и пайплайны.
Часть активов находится за пределами репозитория. Модель может храниться в объектном хранилище. Датасет может находиться во внешнем сервисе. А MCP-сервер может быть описан в JSON-файле клиентской конфигурации.
Такой состав трудно увидеть обычной проверкой кода. Классический анализ смотрит на исходники, зависимости, секреты или работающее приложение. Он не всегда показывает связи между моделью, агентом, хранилищем и внешним провайдером.
Практический шаг: создайте список путей, внешних адресов, владельцев и назначений всех ИИ-артефактов проекта.
🧩 Какие активы требуют отдельной проверки
Модель содержит веса или ссылку на них. При загрузке файла может выполняться код, а происхождение модели может оставаться неподтверждённым. Поэтому проверяйте источник, версию, контрольную сумму и статус подписи.
Адаптер LoRA меняет поведение базовой модели. Для него нужно знать исходную модель и совместимость версий. Отдельный риск появляется, если адаптер существует без понятной базовой модели.
Датасет может содержать персональные сведения, учётные данные или коммерческую информацию. Он также может включать данные с неясной лицензией. Промпт хранит постоянную инструкцию модели, поэтому незаметная правка промпта меняет поведение системы.
Векторное хранилище содержит документы для ответа модели. Агент сам выбирает инструмент и может получить лишние полномочия. MCP-сервер предоставляет инструменты агенту, а его описание может содержать скрытые указания или незакреплённую версию.
Ноутбук .ipynb сохраняет код и результаты выполнения. В выводе ячейки могут остаться секреты. Пайплайн обучения или выкладки получает доступ к сети, учётным данным и каталогу моделей.
Практический шаг: разделите реестр на модели, адаптеры, данные, промпты, хранилища, агентов, MCP-серверы, библиотеки, ноутбуки и пайплайны.
🔐 Какие секреты нельзя публиковать
Секретом считается значение, которое открывает доступ к системе или данным. К этой группе относятся ключи API, токены доступа, пароли, приватные ключи и файлы окружения .env.
Проверяйте также учётные данные облачных хранилищ и идентификаторы внутренних сервисов. Сам идентификатор не всегда является паролем. Но он показывает внутреннюю структуру и помогает связать код с закрытой инфраструктурой.
Секрет может появиться в исходнике, конфигурации, ноутбуке, журнале эксперимента или сохранённом выводе команды. Он также может попасть в архив релиза и артефакт сборки.
Не храните значения секретов в коде. Используйте менеджер секретов или защищённые переменные окружения. В репозитории оставляйте только пример конфигурации без рабочих значений.
Практический шаг: добавьте шаблон конфигурации без секретов и проверьте все файлы .env, ноутбуки, журналы и архивы перед отправкой.
🛠️ Как обнаружить секрет до отправки изменений
Первая контрольная точка находится на рабочем компьютере. Предкоммитная проверка смотрит новые и изменённые файлы до появления коммита. Она помогает остановить ошибку рядом с моментом создания.
Такой контроль не заменяет проверки в CI/CD. Пользователь может пропустить локальный хук, изменить его настройки или отправить старый коммит. Поэтому репозиторий должен повторять проверку на сервере.
Автоматический поиск использует шаблоны. Они находят знакомые форматы токенов, ключей и паролей. Для неизвестных секретов применяют оценку энтропии. Высокая энтропия означает случайную строку, но сама по себе не доказывает утечку.
Третий сигнал — проверка действительности ключа. Она показывает, работает ли значение сейчас. Такой тест проводят осторожно, с минимальными правами и без передачи секрета в лишние системы.
Автоматические проверки дают ложные срабатывания. Случайная строка может быть тестовой, а похожий на ключ фрагмент может быть примером документации. Для исключений нужен понятный владелец, причина и срок пересмотра.
Практический шаг: включите предкоммитную проверку для разработчиков и обязательное сканирование каждого запроса на слияние.
📚 Почему удаления из коммита недостаточно
Удаление строки из последнего коммита не удаляет её из истории Git. Значение остаётся в предыдущих коммитах и может попасть в форки, кэши CI/CD или журналы сборки.
Секрет также может сохраниться в артефакте релиза. Например, его копирует архив, сохранённый вывод ноутбука или временный файл пайплайна. Поэтому проверка только текущего состояния ветки создаёт неполную картину.
Сканируйте всю историю репозитория. Проверяйте ветки, теги и доступные ссылки на старые изменения. Отдельно просматривайте кэш сборок и опубликованные артефакты.
История Git имеет значение и для ИИ-активов. Старая версия промпта может содержать внутренние инструкции. Предыдущий датасет может включать персональные сведения. Удалённый файл модели может остаться в истории или в кэше.
Практический шаг: запустите сканирование полной истории, веток, тегов, кэшей CI/CD и архивов релиза.
⚙️ Как выстроить проверку в CI/CD
Проверка должна идти несколькими слоями. Первый слой анализирует изменённые файлы до коммита. Второй запускается для каждого запроса на слияние. Третий проверяет всю историю и выбранные артефакты.
Защита отправки блокирует публикацию, если проверка находит секрет. Современные средства могут искать универсальные секреты по признакам, даже когда значение не подходит под известный шаблон.
Блокировка отправки не должна быть единственным контролем. Проверяйте также состав ИИ-активов. Реестр должен показывать путь или адрес, тип актива, версию, дайджест, источник, статус подписи, лицензию и уровень риска.
Для модели и адаптера фиксируйте контрольную сумму. Для внешнего источника отмечайте, подтверждена ли версия. Статус «не проверялось» нельзя трактовать как отсутствие подписи. Он означает, что проверка не дошла до актива.
Пайплайн должен проверять конфигурации инференса, ноутбуки и журналы экспериментов. Он также должен проверять ссылки на внешние сервисы и каталоги моделей.
Практический шаг: сделайте публикацию невозможной, пока проверки секретов и состава ИИ-активов не завершились успешно.
🛡️ Как хранить секреты после исправления
Рабочее значение секрета не должно находиться в исходном коде. Храните его в менеджере секретов или в защищённой переменной окружения. В коде оставляйте только имя переменной или ссылку на запись.
Разделяйте значения для разработки, тестирования и выпуска. Не копируйте рабочий токен в ноутбук для эксперимента. Не сохраняйте его в выводе ячейки и журнале пайплайна.
Давайте сервису только необходимые права. Агенту не нужен доступ ко всем инструментам. Пайплайну обучения не нужен полный доступ к каждому хранилищу.
Для ИИ-системы важно контролировать не только токены провайдера. Внутренние инструкции, промпты, данные и конфигурации тоже требуют владельца и правил доступа. Их публикация может раскрыть логику продукта или чувствительные сведения.
Проверяйте секреты перед созданием артефакта. После сборки проверяйте сам архив или пакет. Так вы ловите значения, которые появились не в исходнике, а на этапе генерации.
Практический шаг: перенесите рабочие значения в менеджер секретов и запретите сохранение секретов в логах, ноутбуках и артефактах.
🚨 Что делать при найденной утечке
Найденный секрет считают потенциально скомпрометированным. Сначала заблокируйте или отзовите его. Затем выпустите новый ключ с теми же задачами и минимальными правами.
После замены определите период возможной компрометации. Проверьте журналы доступа и действия, выполненные с этим ключом. Ищите обращения к хранилищам, провайдерам ИИ, внутренним сервисам и каталогам моделей.
Затем удалите значение из истории Git и связанных артефактов. Проверьте форки, кэши CI/CD, журналы сборки и архивы релиза. Удаление не заменяет отзыв, потому что копия могла быть доступна до очистки.
Зафиксируйте инцидент. Запишите найденный файл, ветку, время обнаружения, период действия ключа, выполненные меры и владельца проверки.
Не помещайте найденное значение в отчёт или задачу. Храните только безопасный идентификатор, тип секрета и ссылку на закрытую запись инцидента.
Практический шаг: подготовьте короткую инструкцию реагирования и назначьте владельца для каждого типа ключа и ИИ-актива.
✅ Чек-лист перед публикацией репозитория
Финальная проверка должна проходить перед публикацией кода, пакета или архива. Она подтверждает не только отсутствие строк с ключами. Она также показывает, что команда понимает состав ИИ-системы.
- Составлен реестр моделей, адаптеров, данных, промптов и конфигураций.
- Отмечены агенты, MCP-серверы, векторные хранилища и внешние провайдеры.
- Проверены ключи API, токены, пароли, приватные ключи и файлы .env.
- Просканированы изменённые файлы до коммита.
- Каждый запрос на слияние прошёл проверку секретов.
- Проверена полная история Git, включая ветки и теги.
- Проверены кэши CI/CD, журналы и артефакты релиза.
- Подтверждены версии, дайджесты и источники моделей и адаптеров.
- Для найденных ключей выполнена проверка действительности с минимальными правами.
- Ложные срабатывания имеют владельца, причину и срок пересмотра.
- Рабочие значения хранятся в менеджере секретов или защищённом окружении.
- Публикация блокируется при активном или неизвестном секрете.
Критерий блокировки должен быть простым. Любой активный секрет, неизвестный источник модели, неподтверждённый доступ или непроверенный архив останавливает публикацию.
Реестр активов полезен не только перед первым выпуском. Он обновляется при добавлении агента, модели, адаптера, набора данных или внешнего провайдера.
Практический шаг: сохраните чек-лист в процессе выпуска и требуйте подтверждение каждой контрольной точки.
🔮 Почему реестр активов становится обязательным
ИИ-система состоит из связанных компонентов. Агент использует инструменты. Модель обращается к данным. Векторное хранилище влияет на ответ. Пайплайн связывает обучение, публикацию и доступы.
Плоский список файлов не показывает эти связи. Он не объясняет, какой агент использует конкретный MCP-сервер. Он также не показывает, какой промпт относится к модели и где лежит источник данных.
Реестр описывает актив единообразно. Для него фиксируют имя, путь или адрес, тип, версию, дайджест, источник, подпись, лицензию, проект и уровень риска.
Статусы проверки тоже нужно разделять. Подтверждённая подпись означает совпадение подписи. Контрольная сумма показывает совпадение слепка. Статус «не проверялось» означает отсутствие результата, а не отсутствие проблемы.
Такой подход закрывает главный пробел: команда видит не только код, но и всю ИИ-систему вокруг него.
Практический шаг: обновляйте реестр при каждом изменении ИИ-компонента и не выпускайте актив без владельца, источника и статуса проверки.
📚 Читайте также
- Приватность в частном облаке: полное руководство по защите данных
- Как восстановить облако после атаки и не вернуть злоумышленника
- QKD или постквантовая криптография: выбор защиты для компании
- Удалённый секрет в Git: почему облачный ключ всё ещё опасен
- Защита АСУ ТП: как доказать соответствие требованиям безопасности
📖 Термины
CI/CD · Git · Supply Chain Attack · Безопасность ИИ · Секреты