Пост канала
- видео
Git как поверхность атаки: что остаётся после удаления секрета? 👋 Приветствую в мире цифровой безопасности! В первой части разобрали очевидный сценарий: секрет случайно попал в коммит. Кажется, что достаточно удалить файл и сделать новый commit. Но Git так не работает. ⏺Старый коммит никуда не исчезает. Если объект всё ещё доступен в истории или на него ссылается другая ветка, тег, fork или reflog, содержимое можно найти снова. Удалённый .env не становится автоматически секретным. ⏺Проверить, что осталось в локальном репозитории, можно через историю: git log --all --full-history -- .env А для поиска недостижимых объектов: git fsck --full --no-reflogs --unreachable ⏺Но искать конкретный ключ по всей истории вручную неудобно. Здесь и пригодятся TruffleHog и Gitleaks. Первый можно запускать по Git-истории, второй удобно встроить прямо в CI, чтобы проверка происходила до попадания изменений дальше по пайплайну. ⏺Есть ещё важный момент: обнаружение секрета не означает, что проблема решена. Если AWS key или токен уже попал в удалённый репозиторий, сначала нужно считать его скомпрометированным и отозвать. Переписывание Git-истории убирает данные из определённых объектов, но не отменяет уже произошедшее раскрытие. ⏺Поэтому нормальная защита строится в несколько слоёв: проверка истории, сканирование новых изменений, секреты вне Git и автоматическая ротация при обнаружении утечки. Git отлично помнит то, что разработчик уже успел забыть. 🤖Бесплатный ChatGPT
Открыть в MAX- Просмотры
- 344
- ER
- —
- Реакции
- —