Файл .gitignore помогает исключить локальные файлы из обычного добавления в Git, но не удаляет API-ключи из коммитов и не блокирует их появление в коде. После вайбкодинга с Claude Code проект стоит проверить отдельно: найти секреты в файлах, посмотреть состав будущего коммита и проверить историю изменений. Ниже разберём, с чего начать перед публикацией на GitHub, какие задачи поручить агенту и что делать, если рабочий токен уже попал в репозиторий.
Что делает .gitignore и где заканчивается его защита?
API-ключ или токен даёт программе доступ к внешнему сервису. Например, сайт использует ключ для запросов к ИИ-модели. Если человек получит этот ключ, он сможет выполнять действия в пределах его разрешений, поэтому такой ключ нельзя хранить в открытом коде.
Git сохраняет изменения проекта в коммитах, из которых складывается история репозитория. Файл .gitignore подсказывает Git, какие новые файлы пропускать при обычном добавлении. Но если Git уже отслеживает файл, новое правило игнорирования не прекращает это отслеживание. Секрет также останется в предыдущем коммите, даже если удалить его из текущей версии.
Представим рабочую ситуацию: предприниматель просит Claude Code подключить ИИ к форме на сайте. Для проверки агент записывает ключ в файл настроек. Позже в проект добавляют .env в .gitignore, но ключ лежит в другом файле или уже попал в историю. Правило для .env эту проблему не решает.
Поэтому перед публикацией нужно проверить и файлы, и историю. В русскоязычном руководстве по Claude Code отдельно описаны скиллы и хуки — инструменты, через которые можно организовать повторяемые проверки проекта. Само наличие таких инструментов ещё не означает, что проверка секретов настроена (GitHub — sfrangulov/claude-code-handbook-ru).
Как проверить проект перед публикацией на GitHub?
Начните с локальной проверки, пока репозиторий ещё не опубликован. Если не уверены, какие изменения сейчас подготовлены к коммиту, выполните git status. Команда покажет состояние файлов, но не определит, есть ли внутри секреты.
- Найдите файлы с настройками. Проверьте .env и его варианты, config.json, secrets.yml, резервные копии и файлы с примерами запросов. Такой набор файлов упоминается и в описании навыка secret-scanning-git-repositories (Смыслокод — «754 готовых навыка безопасности Claude Code в 2026»).
- Посмотрите, что уже отслеживает Git. Команда git ls-files покажет список файлов в индексе, то есть среди файлов, которые Git учитывает для следующего коммита. Наличие .env в этом списке требует отдельного внимания, даже если имя есть в .gitignore.
- Проверьте будущий коммит. Команда git diff --cached показывает подготовленные изменения. Просматривайте результат локально: в выводе могут оказаться сами ключи. Не пересылайте его целиком в чат или задачу подрядчику.
- Запустите сканер секретов по рабочим файлам и отдельно по истории Git. Убедитесь, что выбранный инструмент поддерживает оба режима: проверка текущей папки не заменяет просмотр старых коммитов.
- Разберите каждое срабатывание. Укажите, где лежит находка, относится ли она к действующему доступу и какое исправление требуется. В отчёт включайте путь и тип секрета, без его полного значения.
Поиск по словам token, secret, api_key и password помогает найти подозрительные места. Однако ключ может лежать в переменной с другим именем, а слово token встречается и в безопасных примерах. Используйте текстовый поиск как дополнительную проверку, а каждую находку оценивайте по контексту.
Отдельно проверьте код, который браузер получает при открытии сайта. Перенос ключа в переменную окружения не гарантирует защиту: сборка может подставить её значение в браузерный код. Рабочий секрет должен оставаться на сервере, а доступ к серверной функции требует своей проверки. Эту часть разбирает материал о том, как проверить права доступа после вайбкодинга с Claude Code.
Что поручить Claude Code и как закрепить проверку?
Агенту полезно дать узкую задачу с понятным результатом. Просьба «проверь безопасность проекта» оставляет слишком много вариантов: Claude Code может заняться зависимостями и пропустить историю Git. Укажите область проверки и запрет на вывод значений секретов.
Пример задания: «Проверь рабочие файлы, изменения для коммита и историю Git на API-ключи и токены. Не выводи значения секретов и не отправляй содержимое подозрительных файлов во внешние сервисы. Сначала покажи план и список инструментов. В отчёте укажи путь, тип находки и действие для исправления. Без подтверждения ничего не удаляй, не меняй историю и не отправляй в репозиторий».
Такой запрос задаёт порядок работы, но сам по себе не гарантирует, что секрет останется локально. Если агент использует внешнюю модель, чтение файла может включить его содержимое в контекст запроса. Поэтому первый проход по потенциальным секретам лучше выполнять локальным сканером, а агенту передавать отчёт без значений ключей.
После первичной проверки закрепите порядок в проекте. В CLAUDE.md можно записать правило: не помещать рабочие ключи в исходники, использовать безопасные заглушки в примерах и запускать проверку перед коммитом. Но текстовая инструкция не блокирует ошибку технически.
Для блокировки настройте Git-хук перед коммитом: он должен запускать локальный сканер и прерывать коммит при находке или ошибке запуска. Проверьте его на заведомо тестовой строке, которую распознаёт выбранный сканер. Затем уберите тестовую строку и повторите проверку. Хук можно обойти или не установить на другом компьютере, поэтому проверку также полезно запускать автоматически при отправке изменений в репозиторий.
Что делать, если API-ключ уже попал в коммит?
Если рабочий секрет оказался в репозитории, который доступен другим людям, начните с отзыва или замены ключа в сервисе, где его выпустили. Удаление строки из кода не прекращает действие ключа. Пока старый доступ работает, копия файла или коммита сохраняет ценность для постороннего.
- Отзовите старый ключ и выпустите новый с разрешениями, которые нужны приложению. Проверьте доступные журналы использования на незнакомые действия.
- Перенесите новый секрет в серверные настройки окружения. В файле примера оставьте только название переменной и явно вымышленное значение.
- Если Git отслеживает локальный .env, команда git rm --cached .env уберёт его из индекса, сохранив файл на диске. Добавьте правило в .gitignore и проверьте результат через git status.
- Отдельно решите вопрос с историей. Её очистка требует согласования с теми, кто работает с репозиторием: после переписывания истории их локальные копии потребуют внимания. Старые копии и выгрузки при этом не исчезнут.
Если ключ ещё не попал в коммит, уберите его из подготовленных изменений и повторите проверку. Но если вы уже передали значение в чат, приложили к задаче или показали в публичном логе, одной правки файла недостаточно: такой доступ тоже стоит заменить.
При передаче проекта на доработку зафиксируйте результат проверки: какие области проверили, какие доступы заменили и где работает автоматический контроль. Это конкретная задача для технического аудита после вайбкодинга, с результатом, который владелец бизнеса может принять по отчёту и повторному запуску проверки.
Типичные ошибки при проверке секретов
- Проверять только .env. Ключи встречаются в исходниках, настройках сборки, примерах команд и резервных копиях. Задайте сканеру область проверки явно.
- Считать закрытый репозиторий хранилищем секретов. У него есть участники, интеграции и локальные копии. Рабочие ключи лучше вынести из истории кода.
- Заменять ключ звёздочками только в последнем коммите. Предыдущее значение остаётся в истории, а сам доступ продолжает работать до отзыва.
- Просить агента вывести все найденные токены. Тогда секреты появятся ещё и в переписке. Для отчёта достаточно пути, типа находки и статуса исправления.
- Отключать проверку из-за ложного срабатывания. Разберите конкретный пример и добавьте узкое исключение, которое не скрывает остальные файлы.
Перед ближайшей публикацией откройте git status, проверьте будущий коммит и запустите локальный поиск секретов по файлам и истории. Если найдёте рабочий ключ, сначала решите вопрос с его отзывом, затем исправьте проект. Завершите работу повторной проверкой и тестом автоматической блокировки коммита: так у вас останется проверяемый порядок действий для следующих правок Claude Code.
