Для инди-разработчиков и малых операторов, опасающихся «случайно публичного репозитория» GitHub и инцидентов с утечкой секретов, взвешивающих, запускать ли самохостинговый Git-сервер (bare git или Gitea/Forgejo/GitLab). Здесь нет шагов атаки — лишь решение, что безопаснее для вашей конфигурации.
Взгляд этого сайта: самохостинг работает, только если вы берёте на себя то, что делал GitHub
Сам этот сайт запускает самохостинговый Git-сервер. Но причина не только в том, что «случайная выставленность страшна», — это разделение масштаба последствий: одна скомпрометированная служба не должна каскадировать на другие. И поскольку мы самохостим, мы всегда включаем в связку резервные копии вне площадки на отдельный сервер, отказ от хранения секретов в git и автоматический мониторинг CVE зависимостей. Безопасность самохостинга приходит не из «не использования GitHub», а из того, что вы сами делаете работу, которую раньше делал GitHub.
1. Что самохостинг действительно убирает
Ваша тревога имеет обоснование. Классические «публичные инциденты» GitHub просто не могут случиться на самохостинговом сервере.
Публичные репозитории непрерывно сканируются автоматическими ботами. Закоммитьте .env или API-ключ по ошибке — и боты подхватят его раньше, чем заметит человек — эксплуатация за минуты обычна (реальные случаи → ключ утёк через публичный репозиторий, и пошли мошеннические счета · весь .env наружу). Самохостинг убирает эту публичную поверхность. «Должен был быть приватным, но стал публичным», «секрет, который вы думали удалить, висит в публичном форке» — эти классы не могут возникнуть по дизайну. Это не расплывчатое утешение; это реальное преимущество.
2. Работа, которую вы берёте на себя при самохостинге
Это суть. GitHub по умолчанию выполнял много защиты за вас, вне поля зрения. Самохостите — и этой защиты не существует, пока вы её не построите.
GitHub это выполнял
- Блокирует коммиты секретов (push protection)
- Автооповещения о CVE зависимостей (Dependabot)
- Эксплуатация сервера, патчинг, TLS
- 2FA, тонкий доступ, журналы аудита
- Высокая доступность, избыточные резервные копии
Теперь это ваша работа
- Добавить хук pre-commit для обнаружения секретов
- Самостоятельно прогонять мониторинг CVE зависимостей (cron)
- Патчить собственные уязвимости Git-сервера
- Управление ключами = фактически весь контроль доступа
- Потерянные данные не вернуть, если не подготовить восстановление
Две особенно легко упустить. Первая — парадокс: утечку секрета, которой вы боитесь сильнее всего, GitHub фактически останавливает за вас, машинно. Push protection GitHub отклоняет коммиты, содержащие то, что похоже на API-ключ. У голого самохостингового git такой проверки нет. Случайная выставленность ушла, но случайный коммит — нет, поэтому, если вы самохостите, хук pre-commit для секретов обязателен.
Вторая — сам Git-сервер становится мишенью. Богатые функциями серверы вроде GitLab имели множество серьёзных уязвимостей (неаутентифицированное удалённое выполнение кода, т. е. класс RCE), и незапатченный самохостинговый сервер становится входом. Больше функций — больше поверхности атаки. Простой голый git + SSH имеет наименьшую поверхность; GitLab/Gitea удобны, но добавляют бремя самостоятельной погони за патчами.
3. Как сделать самохостинг безопаснее GitHub
Минимальный набор, делающий самохостинг по-настоящему — а не косметически — безопасным. Только с этим «безопаснее GitHub» становится правдой.
Останавливайте секреты до коммита
Минимизируйте и патчите Git-сервер
Резервные копии вне площадки + проверенное восстановление
Отдельные ключи, наименьшие привилегии, не root
Самостоятельно прогоняйте мониторинг CVE зависимостей
4. Что выбрать?
Самохостинг — не «профи», а GitHub — не «любитель». Решайте по тому, сможете ли вы продолжать его эксплуатировать.
Самохостинг подходит (если соответствуете планке)
- вы хотите убрать саму поверхность публичной выставленности
- вы можете продолжать патчить и резервировать сервер
- вы не хотите, чтобы код держала третья сторона / хотите ограничить масштаб последствий
- вы можете внедрить хук для секретов и мониторинг зависимостей как связку
GitHub может быть безопаснее
- нет возможности продолжать патчить/резервировать → заброшенный самохостинг — самое опасное
- вы хотите опереться на push protection / Dependabot автозащиту
- вы не можете сами обеспечить доступность / избыточные резервные копии
- вы можете строго управлять приватными репозиториями (выставленность предотвратима дисциплиной)
Короче говоря, самохостинг означает взять на себя работу, которую GitHub делал за вас. Возьмите её и делайте — и вы уберёте большой класс инцидентов. Возьмите и забросьте — и можете оказаться хуже GitHub: незапатченный сервер, ошибочно закоммиченный секрет и резервная копия, которую не восстановить. А отравление цепочки поставок (как бэкдор в xz-utils) защищается непрерывным мониторингом зависимостей, где бы ни жил ваш код.
Что делает сам этот сайт
Этот сайт запускает самохостинговый Git-сервер (простой голый git + SSH) и устроен так, что каждый push также копируется в резервную копию на отдельном сервере. Секреты (ключи, пароли, строки подключения) никогда не идут в git или документы, а мониторинг CVE зависимостей прогоняется через pnpm audit перед каждым развёртыванием и ежедневно. «Не использовать GitHub» — не цель; цель — убрать класс случайной выставленности и при этом самому делать всю работу, которую раньше делал GitHub. Только сделав и то, и другое, делаешь самохостинг безопасным.
Читать дальше
- Глоссарий: файлы .env и секреты
- Инциденты: ключ утёк через публичный репозиторий · весь .env наружу
- Стеки: машинный мониторинг CVE зависимостей с osv-scanner · не отставать от CVE
- Цепочка поставок: когда один npm install опустошает ваши учётные данные (как приватные репозитории становятся публичными копиями и почему всё решает область действия токена)