Phantom Secrets: Undetected Secrets Expose Major Corporations

Недавно мы затронули тему появления секретов в неожиданных местах, таких как бинарные файлы. Сегодня мы обсудим обнаружение секретов в удаленных ветках публичных репозиториев. В статье от Aqua исследователи рассказали, как они обнаружили около 18% пропущенных секретов в 50 000 публичных репозиториях, используя команду git clone --mirror вместо стандартного git clone. Авторы подробно объясняют разницу между выполнением этих двух команд и углубляются в нюансы кэширования на платформах управления исходным кодом (SCM).

Почему же ветки на самом деле не удаляются и извлекаются через git clone —mirror?

Если коротко, то удаленные ветки в Git не удаляются полностью, так как они могут быть полезны для восстановления данных или истории изменений. Это связано с тем, что Git, по своему замыслу, должен сохранять максимальную доступность и возможность восстановления данных даже после их удаления на локальном уровне. Когда вы удаляете локальную ветку, удаленные ветки могут оставаться в виде "висячих" ссылок на удаленном репозитории. Эти ссылки могут быть извлечены при использовании команды git clone --mirror, так как она клонирует все ссылки, включая те, которые были удалены локально. У этого явления даже есть оспариваемая CVE-2022-24975 (GitBleed).

Вывод достаточно простой: секрет, который однажды попал в репозиторий, можно считать автоматически скомпрометированным. Для многих использование данного подхода не будет чем-то новым. Соответственно, используйте функции защиты от случайных коммитов (push protection) от ваших SCM и pre-commit хуки, чтобы избегать появления секретов в репозиториях. Если это всё же произошло, то, согласно статье, техподдержка может помочь. Кстати, вслед за статьей Gitleaks и TruffleHog добавили поддержку сканирования через --mirror. Также советуем почитать рекомендации от GitHub - "Best practices for preventing data leaks in your organization".

А как эту проблему решаете Вы?

#secrets

Security Wine (бывший - DevSecOps Wine)

Phantom Secrets: Undetected Secrets Expose Major Corporations

Недавно мы затронули тему появления секретов в неожиданных местах, таких как бинарные файлы. Сегодня мы обсудим обнаружение секретов в удаленных ветках публичных репозиториев. В статье от Aqua исследователи рассказали, как они обнаружили около 18% пропущенных секретов в 50 000 публичных репозиториях, используя команду git clone --mirror вместо стандартного git clone. Авторы подробно объясняют разницу между выполнением этих двух команд и углубляются в нюансы кэширования на платформах управления исходным кодом (SCM).

Почему же ветки на самом деле не удаляются и извлекаются через git clone —mirror?

Если коротко, то удаленные ветки в Git не удаляются полностью, так как они могут быть полезны для восстановления данных или истории изменений. Это связано с тем, что Git, по своему замыслу, должен сохранять максимальную доступность и возможность восстановления данных даже после их удаления на локальном уровне. Когда вы удаляете локальную ветку, удаленные ветки могут оставаться в виде "висячих" ссылок на удаленном репозитории. Эти ссылки могут быть извлечены при использовании команды git clone --mirror, так как она клонирует все ссылки, включая те, которые были удалены локально. У этого явления даже есть оспариваемая CVE-2022-24975 (GitBleed).

Вывод достаточно простой: секрет, который однажды попал в репозиторий, можно считать автоматически скомпрометированным. Для многих использование данного подхода не будет чем-то новым. Соответственно, используйте функции защиты от случайных коммитов (push protection) от ваших SCM и pre-commit хуки, чтобы избегать появления секретов в репозиториях. Если это всё же произошло, то, согласно статье, техподдержка может помочь. Кстати, вслед за статьей Gitleaks и TruffleHog добавили поддержку сканирования через --mirror. Также советуем почитать рекомендации от GitHub - "Best practices for preventing data leaks in your organization".

А как эту проблему решаете Вы?

#secrets

hottg.com/sec_devops/610

4.9K viewsRustam Guseynov, Jul 24, 2024 at 06:01