Секреты — pre-commit, detect-secrets и .env-гигиена

Агент с доступом к файлам и git — это новый класс риска: он может закоммитить ваш токен быстрее, чем вы заметите. У меня защита стоит в три слоя, и сработать должен любой из них.

Слой 1: правила для агента

В постоянных инструкциях агента — жёсткий запрет выводить содержимое .env-файлов. Никаких cat .env, никакого чтения файла целиком «для проверки». Проверить, что ключ установлен — можно, посчитав строки по маске. Увидеть значение — нельзя. Плюс список файлов, которые никогда не попадают в коммит: session-файлы мессенджеров, ключи, credentials.

Этот слой самый хрупкий — правила агент может неверно понять. Поэтому он не единственный.

Слой 2: железный хук

Pre-commit с detect-secrets работает на уровне git и не зависит от того, что там агент подумал. Любой коммит сканируется на паттерны секретов: длинные строки после token=, base64-подобные куски, известные форматы ключей. Нашёл — коммит заблокирован.

Настройка на десять минут, срабатывает годами. Из всех слоёв этот — самый дешёвый по усилиям на единицу пользы.

Слой 3: порядок действий при утечке

Самое важное знание — что делать, когда предыдущие слои не сработали. Правило одно, и оно неприятное: утёкший ключ отзывается немедленно, всегда.

Переписывание истории git не спасает: секрет остаётся в форках, кешах и у любого, кто успел склонировать. «Репозиторий же приватный» — тоже не спасает: приватный сегодня — случайно публичный завтра. Единственный настоящий фикс — новый ключ. Всё остальное — уборка следов, которую делают после отзыва, а не вместо.

Мелочь напоследок

Значения секретов не должны попадать и в логи. Мой гейтвей для Telegram, например, печатает «ключ найден», но никогда — сам ключ. Звучит очевидно; проверьте свои скрипты — почти у всех где-нибудь да логируется лишнее.