Я случайно задеплоил в прод конфиг с паролем «test123» — и он там жил три года

Эту историю я долго не хотел рассказывать. Не потому что она страшная — потому что она embarrassing. Но потом я прочитал пост на ithub.uno о том, что культура безопасности строится на открытости, а не на замалчивании. И решился.

Было это в 2019-м. Я настраивал GitLab CI для небольшого проекта — сервис рассылки уведомлений. В процессе отладки пайплайна мне нужен был быстрый тест. Я создал файл .env.test с заглушками: DB_PASSWORD=test123, API_KEY=dummy_key_for_testing, SMTP_PASSWORD=test123. Потом написал .gitlab-ci.yml, который деплоил приложение, и указал в нём cp .env.test .env — чтобы для CI это работало.

Commit. Push. Пайплайн прошёл. Всё работает.

Я написал нормальный продакшн конфиг, залил через GitLab Secrets как положено — и на этом моя работа с тем проектом закончилась. Меня перевели на другой.

Проект жил своей жизнью. Рассылки уходили. Никто не проверял, откуда именно берутся credentials.

Через три года я вернулся на тот проект для аудита. Открыл конфиг на сервере. Увидел DB_PASSWORD=test123. Мне понадобилось секунд тридцать, чтобы понять что произошло.

Оказывается, команда cp .env.test .env в пайплайне выполнялась после загрузки GitLab Secrets и перезаписывала их. Три года подряд, при каждом деплое, на сервер улетал файл с паролем test123.

Самое парадоксальное: база данных была доступна только изнутри приватной сети, поэтому этот пароль де-факто ни на что не влиял. Но это — счастливое стечение обстоятельств, а не правильная архитектура.

Я провёл полный security audit. Нашёл ещё две похожих проблемы — других инженеров, таких же «временных» решений, ставших постоянными. Написал документ «Как мы храним секреты» и внедрил pre-commit hook, который ищет в коде паттерны типа password=test, key=dummy, secret=123.

Но test123 в том конфиге я помню с фотографической точностью.

Три восклицательных знака. Заглавные буквы. Всё честно.

Разработчик сделал деплой. TODO не убрал — дедлайн, «потом». Потом не наступило.

Endpoint жил в проде тихо и незаметно два года. Через два года при проведении security audit penetration tester обнаружил его за тридцать секунд работы с Burp Suite. База данных на тот момент содержала информацию о 340,000 пользователей. Всё это время данные были доступны любому, кто знал URL.

Конца истории Денис не знает — его к тому времени уже не было в той компании. Знает только что был большой скандал и несколько уволенных.

В нашей команде после этой истории появился CI-шаг: grep по всему коду на паттерны TODO.*прод, TODO.*prod, REMOVE BEFORE, DEBUG ONLY. Если находит — пайплайн падает с ошибкой. Работает без единого ложного срабатывания уже полтора года.