Руководство
Как просканировать код, сгенерированный ИИ, на утёкшие секреты
Сканируйте снимок репозитория, проверяйте утечки во фронтенд и отдельно смотрите историю Git. Что находит vetkit и что делать, если учётные данные утекли.
· 5 мин чтения · Команда vetkit
Чтобы просканировать код, сгенерированный ИИ, на утёкшие секреты, запустите сканер секретов по той версии репозитория, которую собираетесь выпустить, проверьте указанные файлы и строки и отзовите все раскрытые учётные данные. В vetkit Security Quick Scan включает обнаружение секретов в репозитории; история Git и утечка ключей на стороне браузера требуют отдельных проверок. Чистый отчёт покрывает только те файлы и проверки, которые действительно были выполнены.
1. Выберите область сканирования
Сгенерированный код может содержать скопированные учётные данные, реалистичный плейсхолдер или код, который раскрывает ключ только при сборке приложения. Это разные проблемы. Прежде чем интерпретировать результат, решите, какие доказательства вам нужны:
| Вопрос | Подходящая проверка | Ограничение |
|---|---|---|
| Есть ли учётные данные в просканированных файлах репозитория? | Secrets (gitleaks), входит в Security Quick Scan | Обнаружение по шаблонам в чекауте, а не доказательство того, что учётных данных нет нигде |
| Были ли учётные данные удалены из текущих файлов, но остались в коммитах? | Отдельный анализатор secrets-history, если он доступен в выбранной области аудита | Ограниченная глубина истории; не входит в Quick Scan |
| Может ли конфигурация сборки раскрыть ключ провайдера браузерам? | Проверки LLM-приложений для поддерживаемых паттернов кода плюс ваша собственная проверка сборки | Не входит в Quick Scan; аудит исходного кода не проверяет ваши развёрнутые ассеты |
2. Просканируйте нужную версию репозитория
- Подключите репозиторий в vetkit, затем выберите Security Quick Scan или доступную область аудита, которая включает обнаружение секретов.
- Проверьте репозиторий и целевой ref. Сканирование удалённого репозитория не видит несохранённые буферы редактора и локальные файлы, которые вы не запушили. Не коммитьте подозрительный секрет только ради того, чтобы его можно было просканировать.
- Дождитесь завершения и, прежде чем читать находки, проверьте результаты анализаторов на ошибки и пропущенные проверки. Недоступный сканер — это не пройденная проверка.
Если вы работаете через ассистента, руководство по MCP для Claude Code и Cursor объясняет, как выбрать репозиторий и посмотреть результаты аудита. Используйте в промптах плейсхолдеры; никогда не вставляйте настоящие учётные данные в ассистента, чтобы спросить, действительны ли они.
3. Разберите каждую находку
Прочитайте правило, критичность, путь к файлу и номер строки. Находки vetkit по секретам используют замаскированные фрагменты; чтобы отличить настоящие учётные данные от синтетических тестовых данных, посмотрите исходный код у себя. Общие шаблоны могут давать ложные срабатывания, а незнакомые форматы — пропускаться. Само по себе совпадение не говорит, действительны ли учётные данные до сих пор.
В первую очередь займитесь учётными данными, которые дают доступ к облачным ресурсам, репозиториям, публикации пакетов или продакшн-данным. Запишите затронутый сервис и ответственного за исправление, не копируя секрет в тикет, скриншот или чат. Не отклоняйте находку только потому, что ассистент называет значение примером.
4. Проверьте утечку в браузер и историю
Ключ может оставаться вне Git и всё равно попасть к пользователям через фронтенд-сборку. Проверьте использование публичных переменных окружения, вызовы SDK провайдеров и конфигурацию бандлера, а затем изучите сгенерированные браузерные ассеты в собственном контролируемом окружении. Примеры — в руководстве об API-ключах во фронтенде. Сканирование репозитория не собирает ваше приложение с секретами для деплоя автоматически и не изучает бандлы живого сайта.
Если учётные данные могли быть закоммичены раньше, включите отдельную проверку истории, если её допускает область аудита. По умолчанию её окно — не более 500 коммитов, и оно может быть меньше, если история в чекауте более поверхностная. Это не исчерпывающий поиск по каждой ветке, форку или копии репозитория.
5. Отреагируйте и просканируйте снова
- Отзовите или ротируйте раскрытые учётные данные у их провайдера. Удаление строки или переписывание коммита не делает скопированный ключ недействительным.
- Перенесите замену в подходящее серверное хранилище секретов или среду выполнения. Убедитесь, что она не может попасть в браузерный бандл или в логи.
- Проверьте записи о доступе и использовании у провайдера на неожиданную активность. Любую чистку истории согласуйте с соавторами репозитория; ротация всё равно необходима.
- Запустите новое сканирование по исправленной версии и повторите нужные проверки сборки или истории. Сохраните целевую версию аудита вместе с записью об исправлении.
Источники и ограничения
Проверено 1 ноября 2026 года по конфигурации Quick Scan в vetkit и реализациям анализаторов gitleaks, secrets-history и LLM-приложений. Quick Scan запускает posture, gitleaks и OSV; он не включает все анализаторы полного аудита. Интеграция gitleaks по умолчанию пропускает файлы больше 5 МБ, а сканирование подчиняется ограничениям на репозиторий, файлы и время. Смотрите покрытие и предупреждения конкретного запуска.
Документация описывает процесс аудита, а публичный каталог проверок документирует собственные правила. Этот каталог — не полный список сторонних сигнатур gitleaks. Это руководство описывает шаги обнаружения и исправления; ни чистое сканирование, ни высокий балл не гарантируют, что приложение безопасно.