Безопасность и секреты

Что отвечать

Provenance: подпись доказывает что коммит создал владелец ключа, а не кто-то с твоим именем в `user.name`/`user.email` (эти поля Git вообще не проверяет). Без подписи легко закоммитить от чужого имени: `git -c user.name='Linus Torvalds' -c user.email='torvalds@...' commit`. GPG/SSH-подпись + публикация ключа в GitHub дают значок Verified в UI и проверку через `git verify-commit`. Защищает от impersonation и supply-chain атак.

Что хотят услышать

Senior должен: - назвать конкретный риск без подписи: коммит «как кто-то другой» тривиально, нужны только две строки в `git -c` - различить GPG (старый стандарт, нужен gpg-agent) и SSH-signing (с Git 2.34+, проще: тот же ssh-ключ что для push) - показать настройку: `git config user.signingkey <key>` + `git config commit.gpgsign true` + `git config gpg.format ssh` для SSH-варианта - назвать что GitHub помечает Verified только когда коммит подписан **и** ключ опубликован в профиле автора - упомянуть `git verify-commit <sha>` и `git log --show-signature` для локальной проверки - сказать что в высоко-чувствительных репо нужно требовать signed-commits через branch protection

Подводные камни

• ✗ Думать что `user.name`/`user.email` это аутентификация - это просто текст в коммите, никто не проверяет
• ✗ Положить приватный GPG ключ без passphrase для удобства - утечка ключа = подделка всех коммитов
• ✗ Включить signed-commits в branch protection и забыть про CI-бота, который коммитит без ключа - заблокирует автоматику

Follow-up

• ? Как настроить SSH-signing вместо GPG?
• ? Что произойдёт если коммит подписан, но ключ не в профиле GitHub?
• ? Как требовать signed-commits в branch protection не сломав CI?

Что отвечать

`.gitignore` это **только инструмент дисциплины**: не даёт Git'у tracking'ать новые файлы по шаблону. Не помогает если файл уже tracked (`git rm --cached` нужен), не сканирует **содержимое**, не ловит секрет в логе или комментарии. Secret scanning (GitHub Advanced Security, gitleaks, trufflehog) сканирует **diff** на regex/энтропия-паттерны: AWS-ключи, Slack-токены, приватные ключи, JWT. Работает в pre-commit hook или в CI - ловит до push'а.

Что хотят услышать

Senior должен: - назвать три уровня защиты: pre-commit hook (быстрая обратная связь), CI-сканер (защита от обхода hook'а), post-commit notification от провайдера (GitHub auto-revokes leaked tokens) - сказать что gitleaks/trufflehog можно встроить в pre-commit framework и в GitHub Action одним конфигом - упомянуть что GitHub Secret Scanning имеет partner-программу для популярных провайдеров (AWS, Stripe, Slack) - они автоматом отзывают токен при обнаружении - назвать что `.gitignore` всё равно нужен как первый барьер - не tracked = не попадёт в blob - но не основная защита - сказать что secret в **истории коммита**, который scanner нашёл, требует ротации + filter-repo, не просто delete

Подводные камни

• ✗ Положиться только на .gitignore - не защищает от случайного `git add -f` или от опечатки в шаблоне
• ✗ Сканировать только последний коммит в CI - старая утечка не найдётся, нужен `gitleaks detect` на всю историю
• ✗ Думать что secret scanning заменяет KMS/vault - он реагирует на утечку, vault её предотвращает

Follow-up

• ? Как настроить gitleaks в pre-commit hook?
• ? Что делает GitHub Advanced Security при обнаружении AWS ключа?
• ? Чем `trufflehog` отличается от `gitleaks` на практике?

Что отвечать

Нет. `git rm --cached` удаляет файл из index и из следующего коммита, но **прошлые коммиты не трогает** - blob с секретом остаётся достижимым через `git log -- secret.env` и `git show <старый-sha>:secret.env`. Лечится только переписыванием истории: `git filter-repo --invert-paths --path secret.env` + force-push всех веток. И, главное, **ротация секрета**. Удаление из истории не лечит утечку, лечит только ротация.

Что хотят услышать

Кандидат должен: - чётко сказать «нет» и объяснить почему: blob остался в objects, виден через `git show <старый-sha>:secret.env` - назвать filter-repo как инструмент чистки истории, не filter-branch (deprecated) - подчеркнуть что ротация это **главное**, чистка истории это вторично - секрет уже утёк, его видели/скачали/закэшировал GitHub - сказать что GitHub кэширует force-push'нутые коммиты и они остаются доступны по прямой ссылке `/<repo>/commit/<old-sha>` ещё долго - упомянуть что forks хранят свою копию истории - даже после твоей чистки, секрет остаётся в forks

Подводные камни

• ✗ Сказать «git rm --cached удалил из истории» - не удалил, только из следующего коммита
• ✗ Сделать filter-repo и не ротировать секрет - утечка не закрыта
• ✗ Думать что force-push в main снёс старые SHA на GitHub - не снёс, они доступны по прямой ссылке

Follow-up

• ? Какой `git show` найдёт удалённый из последнего коммита файл в истории?
• ? Что произойдёт с forks после filter-repo + force-push?
• ? Какой порядок действий при утечке секрета в публичный репо?

Что отвечать

Шаги: удалить ключ из настроек GitHub/GitLab/Bitbucket (revoke на сервере → push сломается у того кто украл), сгенерить новый пары ключей (`ssh-keygen -t ed25519 -C "..."` - ed25519 короче и быстрее RSA), добавить публичный в платформу, обновить `~/.ssh/config` если используется. Если ключ использовался для signed-commits - дополнительно ревокнуть подпись (в GitHub: `Settings → SSH and GPG keys → Revoke`), иначе старые коммиты продолжат показывать Verified.

Что хотят услышать

Senior должен: - назвать «revoke на платформе» как первое действие - это сразу обрывает доступ - рекомендовать ed25519 (`ssh-keygen -t ed25519`) как современный дефолт: короче, быстрее, безопаснее RSA-2048 - сказать про hardware-ключи (YubiKey, Secure Enclave) для особо чувствительных аккаунтов - приватная часть никогда не покидает железо - упомянуть `ssh-add --apple-use-keychain` (macOS) или ssh-agent + systemd-user-service для удобного passphrase-кэширования - назвать что для CI лучше deploy-keys (per-repo read-only) или OIDC-federation (GitHub Actions → AWS) вместо постоянных long-lived SSH-ключей

Подводные камни

• ✗ Сгенерировать новый ключ, забыть удалить старый из платформы - утёкший ключ всё ещё работает
• ✗ Использовать RSA-1024 или DSA в 2026 - устаревшие алгоритмы, многие платформы их уже отклоняют
• ✗ Хранить приватный ключ без passphrase «для удобства» - утечка ноутбука = моментальная компрометация

Follow-up

• ? Чем deploy-key отличается от user-ключа?
• ? Как использовать YubiKey для git-ssh без passphrase?
• ? Почему OIDC federation предпочтительнее long-lived ключей для CI?

Что отвечать

`.gitignore` влияет только на **untracked** файлы. Tracked файлы Git продолжает отслеживать, потому что они уже в index. Чтобы перестать tracking'ать без удаления локально: `git rm --cached <file>` (уберёт из index, оставит на диске), затем коммит, затем `.gitignore` будет работать. Для целого каталога: `git rm --cached -r <dir>`. Помни что **прошлые коммиты с файлом остаются** - содержимое в истории.

Что хотят услышать

Кандидат должен: - объяснить почему `.gitignore` игнорируется для tracked файлов: иначе случайное добавление паттерна снесло бы файл из коммита - дать правильный workflow: `git rm --cached <file>` + коммит + `.gitignore` - назвать `git check-ignore -v <file>` как способ проверить какое правило в `.gitignore` срабатывает (или не срабатывает) - упомянуть `.git/info/exclude` как локальный (не-shared) аналог `.gitignore` - не попадает в коммит, удобно для личных .DS_Store или IDE-конфигов - подчеркнуть что историю файла это не чистит - blob остаётся достижимым

Подводные камни

• ✗ Думать что добавление в `.gitignore` сразу остановит tracking - не остановит для уже tracked
• ✗ Сделать `git rm <file>` вместо `git rm --cached <file>` - удалит файл с диска
• ✗ Использовать `.gitignore` для секретов - не помогает после первого коммита

Follow-up

• ? Что покажет `git check-ignore -v src/secret.env`?
• ? Чем `.git/info/exclude` отличается от `.gitignore`?
• ? Как одной командой untrack целый каталог `node_modules/` без удаления с диска?