Secrets Policy

Секреты и чувствительные данные

Что нельзя хранить в репозитории, PR, issue, комментариях и wiki

• пароли;
• токены (префиксы ghp_, github_pat_, sk-, AKIA… и подобные);
• JWT-ключи подписи и токены gRPC сервис-сервис;
• ключи доступа MinIO/S3;
• строки подключения с паролем;
• приватные ключи и сертификаты (*.pem, *.key, *.pfx);
• файлы htpasswd;
• содержимое .env.

Где живут значения

• На сервере: /opt/travelagency/docker/.env.
• В CI: GitHub Secrets (окружение dev).
• Локально: user-secrets (dotnet user-secrets).

В коде, конфигурации и примерах используются только плейсхолдеры (CHANGE_ME, <your-password>) и адреса в домене @example.com.

Перед пушем

gitleaks git --redact .

CI (джоб Secret scan) выполняет ту же проверку на каждый PR и push в main; проверка должна быть зелёной. В шаблоне PR есть галочка об отсутствии секретов в изменениях.

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

Утечкой считается попадание значения в коммит, лог, комментарий, issue или wiki.

1. Сначала ротировать значение: выпустить новое, старое отозвать.
2. Затем удалить упоминание или переписать историю.

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

Как это работает

gitleaks проверяет файлы и историю коммитов по набору регулярных выражений (известные форматы токенов и ключей) и по энтропии строк (длинные случайные строки похожи на секреты).

Пример: строка вида token = "ghp_…" (префикс и 36 случайных символов) совпадает с правилом для токенов GitHub, и проверка падает. Строка password = "CHANGE_ME" не совпадает ни с одним правилом и проходит.

Тестовые ключи, которые действительно нужны в репозитории, разрешаются точечно в .gitleaks.toml (конкретный файл, строка или значение), а не исключением целых папок.

См. также

• docs/COMMIT_CONVENTION.md, раздел «Секреты».