Обеспечение безопасности ваших Git-репозиториев: лучшие практики и недоверенные источники

Обеспечение безопасности ваших Git-репозиториев — это не только сохранение кода в тайне. Репозиторий может содержать секреты, исполняемые хуки, риски цепочки поставок, конфиденциальную историю и конфигурацию, влияющую на каждого разработчика, который его клонирует.

Хорошие практики безопасности Git помогают избежать утечки учетных данных, небезопасной автоматизации и случайного доверия к коду из неизвестных источников. Основы просты, но их необходимо последовательно применять.

Защитите секреты до того, как они попадут в Git

Самый безопасный секрет — тот, который никогда не попадает в репозиторий. Ключи API, закрытые ключи SSH, облачные учетные данные, пароли к базам данных, токены и файлы .env должны полностью оставаться за пределами Git.

Добавьте локальные файлы с секретами в .gitignore:

.env
.env.*
*.pem
id_rsa
id_ed25519

Будьте осторожны с .env.example. Этот файл часто полезен, но он должен содержать фиктивные значения-заполнители:

DATABASE_URL=postgres://user:password@localhost:5432/app
API_TOKEN=replace-me

Не вставляйте реальные значения "просто для тестирования". История Git запоминает старые версии, даже если вы удалите строку в более позднем коммите.

Если вы случайно закоммитили секрет, считайте его скомпрометированным. Удалите его из текущего дерева, смените учетные данные в сервисе, который их выдал, а затем решите, требуется ли очистка истории. Переписывание истории может помочь уменьшить будущее воздействие, но не гарантирует, что секрет никогда не был скопирован.

Командам также следует использовать сканирование секретов. Многие хостинговые Git-платформы предлагают сканирование распространенных шаблонов токенов. Локальные инструменты pre-commit могут выявлять ошибки раньше, до того, как push попадет на сервер.

Связанные операционные шаблоны см. в разделе освоение переменных окружения для конфигурации и секретов.

Ограничьте доступ и изменения веток

Безопасность репозитория начинается с контроля доступа. Давайте людям минимально необходимый доступ. Тот, кто только проверяет код, вероятно, не нуждается в правах администратора. Сервисный аккаунт CI, вероятно, не нуждается в разрешении на перезапись веток.

Регулярно проверяйте эти настройки:

• Администраторы и владельцы репозитория.
• Соавторы с правами на запись.
• Ключи развертывания и машинные пользователи.
• Персональные токены доступа, используемые автоматизацией.
• Вебхуки, получающие события репозитория.
• Правила защиты веток.

Защищенные ветки — один из самых полезных элементов управления. Для важных веток, таких как main, требуйте pull request'ы, проверки статуса и ревью перед слиянием. Отключите принудительные push'и, если у вашей команды нет очень конкретной причины их разрешать.

Подписанные коммиты или подписанные теги также могут помочь в средах с более высоким уровнем доверия. Сами по себе они не делают код безопасным, но могут доказать, что коммит или тег релиза были созданы ключом, который ваша команда распознает.

Используйте теги для релизов с осторожностью. Если процесс развертывания доверяет тегам, ограничьте круг лиц, которые могут их создавать или перемещать. Перемещенный тег релиза может запутать аудит и развертывания.

Будьте осторожны с недоверенными репозиториями

Клонирование кода из недоверенного источника — обычное дело. Запуск его немедленно — рискованная часть. Git-репозиторий может включать сценарии сборки, сценарии жизненного цикла пакетов, Makefile'ы, контейнеры, конфигурацию CI и инструкции, которые выполняют код на вашей машине.

Прежде чем что-либо запускать, проверьте репозиторий:

git clone --no-checkout https://example.com/project.git
cd project
git log --oneline -5
git status

Затем проверьте файлы высокого риска:

• Сценарии оболочки, такие как install.sh или bootstrap.sh.
• Сценарии пакетов в package.json.
• Файлы CI в .github/workflows/, .gitlab-ci.yml или аналогичных путях.
• Dockerfile'ы и compose-файлы.
• Makefile'ы.
• Манифесты зависимостей для конкретных языков.

Не запускайте команды настройки curl | bash из случайного README. Если проекту требуется установщик, загрузите его, прочитайте и, по возможности, запустите в изолированной среде.

Git-хуки заслуживают особого упоминания. Хуки в .git/hooks/ обычно не передаются как активные хуки при клонировании репозитория. Это хорошо. Но репозиторий может включать сценарии, которые устанавливают хуки для вас. Прочитайте эти сценарии перед их запуском, потому что хуки могут выполняться во время коммитов, слияний, перебазирований и push'ей.

Для неизвестного кода используйте изоляцию. Временная виртуальная машина, контейнер или изолированная среда разработки уменьшают радиус поражения, если сценарий ведет себя некорректно. Не монтируйте свои ключи SSH, облачные учетные данные или производственный kubeconfig в среду, используемую для недоверенного кода.

Содержите историю репозитория и файлы в чистоте

Безопасность обеспечивается проще, когда репозиторий аккуратен. Большие бинарные файлы, сгенерированные архивы, проданные секреты и старые дампы конфигурации усложняют проверку и увеличивают риск.

Используйте .gitignore для локальных файлов и .gitattributes для правил обработки файлов. Например:

*.sh text eol=lf
*.png binary
*.jpg binary

Если вашему проекту нужны большие файлы, подумайте, подходит ли Git Large File Storage. Стандартный Git не идеален для огромных артефактов сборки или медиафайлов. Их прямое хранение может замедлить клонирование и усложнить очистку конфиденциальных файлов.

Проверяйте pull request'ы на предмет изменений, критичных для безопасности, а не только логики приложения. Обращайте внимание на:

• Новые учетные данные или токены.
• Новые сетевые вызовы в сценариях.
• Изменения источников зависимостей.
• Новые разрешения CI.
• Изменения в сценариях развертывания.
• Широкие изменения .gitignore, скрывающие важные файлы.

Также обращайте внимание на подмодули. Они указывают на внешние репозитории и конкретные коммиты. Если ваш проект их использует, тщательно проверяйте URL-адреса подмодулей и обновления.

Когда привлекать профессионала

Привлекайте инженера по безопасности, DevOps-лида или ответственного за инциденты, если секрет был отправлен в публичный репозиторий, защищенная ветка была неожиданно принудительно запушена или неизвестный участник изменил CI или автоматизацию развертывания.

Вам также следует обратиться за помощью, если вы подозреваете, что история репозитория была подделана. Сохранение доказательств может быть важнее быстрой очистки, особенно в корпоративной среде.

Обеспечение безопасности Git-репозиториев сводится к дисциплинированному доверию. Держите секреты в тайне, ограничивайте доступ, защищайте важные ветки и проверяйте недоверенный код перед его запуском. Эти привычки предотвращают большинство проблем с безопасностью репозитория до того, как они перерастут в инциденты.