Безопасная разработка: Часть 2 — Секреты в коде

Секрет — любые данные, которые дают доступ к ресурсу: пароль базы данных, API-ключ платёжной системы или облака, токен бота, приватный SSH-ключ. Если такой секрет попал в Git, удаление в следующем коммите ничего не исправляет: Git хранит всю историю, и старая версия файла доступна каждому, у кого есть копия репозитория. Автоматические сканеры постоянно просматривают публичные репозитории, поэтому ключ, попавший в публичный коммит, нужно считать скомпрометированным сразу.

Если секрет уже утёк

Порядок действий важнее инструментов:

1. Отозвать или сменить секрет у поставщика: создать новый ключ, старый деактивировать, пароль базы данных сменить. Это единственный шаг, который действительно закрывает доступ.
2. Проверить журналы доступа сервиса, к которому относился ключ: не использовал ли его кто-то посторонний.
3. Сменить связанные доступы. Если утёк пароль, который использовался в нескольких местах, его меняют везде.
4. Только после этого чистить историю репозитория. Проект Git рекомендует для этого git filter-repo вместо устаревшего git filter-branch:

# удалить файл из всей истории
git filter-repo --path config/secrets.yml --invert-paths

# заменить строки из файла replacements.txt во всех коммитах
git filter-repo --replace-text replacements.txt

После переписывания истории нужна принудительная отправка в удалённый репозиторий, а все участники должны заново клонировать проект. Копии, которые уже разошлись — форки, локальные клоны, кеши CI, — чистка не затрагивает. Поэтому она не заменяет первый шаг, а только убирает следы.

Где хранить секреты

• В разработке — в файле .env, который перечислен в .gitignore. В репозиторий кладут .env.example с именами переменных и пустыми значениями, чтобы коллеги знали, что нужно заполнить.
• В CI/CD — в защищённых переменных проекта: masked и protected в GitLab, secrets в GitHub Actions.
• На серверах — в окружении сервиса или в отдельном хранилище секретов, но не в коде и не в Docker-образе.

Если .env уже попал в репозиторий, одного добавления в .gitignore мало: файл нужно убрать из индекса командой git rm --cached .env — и, конечно, сменить всё, что в нём было.

Gitleaks

Gitleaks ищет в репозиториях и каталогах пароли, ключи и токены по набору регулярных выражений для сотен форматов. Лицензия MIT, актуальная версия на сентябрь 2026 года — 8.30.1. Автор объявил инструмент завершённым: новые функции больше не добавляются, выходят только исправления безопасности, а разработка продолжается в новом проекте Betterleaks.

Основные режимы работы:

gitleaks git -v     # проверить всю историю текущего репозитория
gitleaks dir .      # проверить файлы в каталоге без учёта истории

Команды detect и protect из старых версий объявлены устаревшими, хотя пока работают.

Проверка перед каждым коммитом: pre-commit

Фреймворк pre-commit запускает проверки автоматически при каждом git commit. Установка и подключение Gitleaks:

pip install pre-commit

Файл .pre-commit-config.yaml в корне проекта:

repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.30.1
    hooks:
      - id: gitleaks

pre-commit install          # подключить хук к репозиторию
pre-commit run --all-files  # проверить все файлы сразу после подключения
pre-commit autoupdate       # обновить версии хуков

Если Gitleaks найдёт секрет, коммит не состоится. Проверку можно пропустить переменной SKIP=gitleaks, поэтому локальный хук — удобство для разработчика, а не гарантия.

TruffleHog

TruffleHog решает ту же задачу, но умеет проверять найденное: для многих типов ключей он обращается к API поставщика и сообщает, действует ли ключ. Лицензия AGPL-3.0, актуальная версия — 3.97.5.

trufflehog git https://git.example.ru/team/project.git --results=verified

Флаг --results=verified оставляет в отчёте только ключи, подтверждённые как действующие. Такие находки требуют немедленной смены секрета.

Проверка на сервере

Раз локальную проверку можно отключить, её повторяют в пайплайне — первой задачей, до сборки и тестов. Для GitHub Actions у Gitleaks есть готовое действие gitleaks-action; в GitLab CI и Gitea Actions достаточно задачи, которая запускает gitleaks git в каталоге проекта. Такая задача должна останавливать пайплайн при любой находке.

У GitHub есть и собственная защита — push protection. Для личных аккаунтов она включена по умолчанию и не даёт отправить секрет в публичный репозиторий. Защита на уровне репозитория, которая действует и для закрытых проектов, требует платной функции GitHub Secret Protection и включается администратором.

Типичные ошибки

• Удалить файл новым коммитом и считать проблему решённой. Секрет остаётся в истории.
• Чистить историю вместо смены ключа. Копии репозитория уже существуют.
• Печатать секреты в журналах CI. Команда echo $TOKEN для отладки выводит ключ в журнал сборки; защищённые переменные маскируются, но полагаться только на это не стоит.
• Передавать секреты в Docker-образ через ARG или ENV. Они сохраняются в слоях образа; правильный способ — секреты BuildKit.
• Один и тот же ключ для разработки и продакшена. Утечка тестового окружения открывает доступ к рабочему.