1Задача
Обходя проекты, мы нашли в папке клиентского телеграм-бота файл с ключами и строку с токеном прямо в исходнике. Вывод напрашивался сам: секреты лежат в коде, могли попасть в копии репозитория и в резервные копии, ключи надо срочно перевыпускать.
Так и записали — красным, с формулировкой «ключ в коде уже мог попасть в любую копию репозитория». Задача ушла в план как срочная.
Это была моя ошибка. Не в том, что проверил, а в том, что выводы сделал раньше проверки.
2Действия
На следующий день, взявшись чинить, мы наконец посмотрели на факты.
Первое. Папка с ключами целиком перечислена в списке исключений репозитория. Под контролем версий из неё ноль файлов. Значит ни файл с ключами, ни исходник бота в историю проекта не попадали и попасть не могли.
Второе. Бот берёт токен не из кода, а из отдельного файла настроек. Строка с токеном в исходнике была закомментирована — запасной вариант, оставшийся с отладки и никогда не исполнявшийся.
То есть настоящая картина такая: ключи лежат обычными файлами на рабочей машине владельца и не покидают её. Это стандартная практика, а не утечка.
3Решение
Мёртвая строка с токеном убрана — держать копию ключа в исходнике незачем даже под знаком комментария. Рядом положен образец файла настроек без значений, чтобы следующий разработчик видел список переменных, а не искал их по коду.
Оценка риска в плане переписана честно: ротация ключей нужна не «потому что утекло», а только если папку целиком кому-то передавали. Это один вопрос владельцу на минуту вместо срочной задачи на час.
И вывод, ради которого эта запись здесь. Преувеличенная тревога стоит дорого: она отнимает внимание у настоящих проблем и приучает не верить оценкам. Если пишете «красным» — сначала доведите проверку до конца. «Возможно, утекло» и «утекло» — разные утверждения, и второе нужно заслужить фактом.