本文へスキップ
ITDセキュリティ対策プラットフォーム
目的から探す
検索
対策・学習10分で読める

自前のGitサーバーとGitHub、セキュリティ的にどっちが安全か

リポジトリの誤公開が怖くて自前のGitサーバーを検討する人向けに、自前運用で消せるリスクと、代わりに背負うパッチ・バックアップ・秘密スキャンを整理し、GitHubより安全にする条件を解説します。

本文を読む
#Git#セルフホスト#シークレット管理#サプライチェーン#サーバー
公開日
更新日
目次

対象：GitHubの「リポジトリ誤公開」やシークレット流出が怖くて、自前のGitサーバー（bare git や Gitea/Forgejo/GitLab）で運用すべきか迷っている個人開発者・小規模運営者。ここでは攻撃手順は扱わず、どちらが自分の構成で安全かという判断だけを扱います。

当サイトの視点：自前運用は、GitHubが担っていた作業を自分で続けることが前提

当サイト自身も自前のGitサーバーで運用しています。ただし理由は「誤公開が怖いから」だけではなく、被害範囲の分離（1つのサービスが侵害されても他へ広げない）が主目的です。そして自前にする以上、別サーバへのオフサイトバックアップ・秘密をgitに一切入れない運用・依存CVEの自動監視を必ずセットで実践しています。自前運用の安全性は「GitHubを使わないこと」ではなく「GitHubが代わりに行っていた作業を自分で行うこと」で決まります。

1. 自前運用が本当に消せるリスク

あなたの不安には正しい根拠があります。GitHubの代表的な「公開事故」は、自前運用なら構造的に起こりえません。

0
誤公開ボタンが存在しない
0
公開フォークへの秘密残留
即時
公開リポの秘密はbotに悪用される

公開リポジトリは、世界中の自動スキャンbotに常時クロールされています。.env やAPIキーを誤ってコミットすると、人が気づくより先にbotが拾い、数分で悪用されることが珍しくありません（実例 → 公開リポ経由でキーが漏れ不正課金された話 ／ .env が丸ごと公開された話）。自前運用は、この公開面そのものを無くせます。「プライベートのつもりが公開だった」「削除したはずの秘密が公開フォークに残っていた」という事故のクラスが、設計上発生しません。これは曖昧な気休めではなく、実在する利点です。

2. 自前運用で自分が負う作業

ここが本題です。GitHubは見えないところで多くの防御を標準で肩代わりしていました。自前にすると、それらは自分でやらない限り存在しません。

GitHubが肩代わりしていた

  • 秘密混入をコミット時にブロック（push protection）
  • 依存CVEの自動通知（Dependabot）
  • サーバ本体の運用・パッチ・TLS
  • 2要素認証・細かな権限・監査ログ
  • 高い可用性・冗長なバックアップ

自前では自分の仕事になる

  • コミット前の秘密検出フックを自分で入れる
  • 依存CVE監視を自分で回す（cron）
  • Gitサーバの脆弱性も自分で塞ぐ
  • 鍵管理＝事実上の全権アクセス制御
  • データが消えたら戻せないので、復元の準備を自分で
GitHubが標準で守ってくれていたこと（左）と、自前では自分でやらないと存在しないこと（右）。

とくに見落としがちなのが2つあります。1つは、あなたが一番恐れている「秘密の流出」を、実はGitHubの方が機械で止めてくれているという逆説です。GitHubのpush protectionは、APIキーらしき文字列を含むコミットをそもそも拒否します。素の自前gitには、その仕組みがありません。誤公開はなくなっても、誤コミットはなくならない。だから自前にするなら、コミット前の秘密検出フックは必須です。

もう1つは、Gitサーバ本体が攻撃対象になることです。GitLabのような多機能サーバには過去に深刻な脆弱性（認証なしの遠隔コード実行＝RCE級）が複数あり、パッチを放置した自前サーバは、それ自体が侵入口になります。機能が多いほど攻撃面は広い。素のbare git＋SSHが最も攻撃面が小さく、GitLab/Gitea等は便利な反面、自分でパッチを追い続ける負担が増えます。

3. 自前を「GitHubより安全」にする条件

自前運用を、気休めでなく本当に安全にするための最小セットです。これらを満たして初めて、GitHubより安全だと言えます。

1

コミット前にシークレットを止める

gitleaks 等の pre-commit フックを入れ、APIキー・.env・秘密鍵を含むコミットを自動でブロックする。GitHubのpush protectionの代わり。
2

Gitサーバ本体を最小化＆パッチ

攻撃面の小さい bare git＋SSH を基本に。多機能サーバを使うなら、その脆弱性（CVE）を自分で追い、即パッチする運用を組む。
3

別の場所へオフサイトバックアップ＋復元テスト

サーバが消えても困らないよう、別系統の保管先へ自動バックアップ。「取れている」だけでなく、実際に復元できるかを一度試す。
4

鍵を分離し、最小権限・非rootで

ホストごとに別のSSH鍵（1本漏れても全サーバーには入られない）。サーバは非rootで動かし、到達できる面を減らす。
5

依存のCVE監視を自前で回す

Dependabotが無い分、osv-scanner や pnpm audit を CI/cron で継続実行する（→ CVEに後れを取らないしくみ）。

4. どっちを選ぶべきか

「自前＝玄人」でも「GitHub＝素人」でもありません。運用を続けられるかで決めます。

自前が向く（条件を満たすなら）

  • 誤公開・公開bot悪用の可能性そのものを無くしたい
  • サーバのパッチ・バックアップを自分で続けられる
  • コードを第三者に預けたくない／被害範囲を分離したい
  • 秘密検出フックと依存監視をセットで導入できる

GitHubの方が安全なことも

  • パッチ・バックアップを継続する余力がない → 放置した自前は最も危険
  • push protection / Dependabot の自動防御に頼りたい
  • 可用性・冗長バックアップを自分で用意できない
  • プライベートリポの管理を徹底できる（誤公開は設定運用で防げる）

要は、自前運用はGitHubが肩代わりしていた仕事を、自分が引き受けることです。引き受けて実行するなら、誤公開という大きな事故クラスを消せる強力な選択。引き受けたつもりで放置するなら、パッチ漏れのサーバ＋秘密の誤コミット＋復元できないバックアップという、GitHubより悪い状態になりえます。サプライチェーン経由の混入（xz-utilsバックドアのような）も、預け先がどこであれ依存監視を続けることが防御になります。

当サイト自身はどうしているか

当サイトは自前のGitサーバー（素の bare git＋SSH）で運用し、プッシュと同時に別サーバのバックアップへも自動で送られるように設定しています。秘密（鍵・パスワード・接続情報）はgitにもドキュメントにも一切書かない運用を徹底し、依存のCVE監視は pnpm audit を毎デプロイ前＋日次で回しています。つまり「GitHubを使わない」こと自体が目的ではなく、誤公開のクラスを消しつつ、GitHubが行っていた作業を全部自分で行う。その両方をやって初めて、自前運用は安全だと考えています。

次に読む

よくある質問

Q自前のGitサーバーはGitHubより安全ですか？
A

一概に安全とは言えません。自前運用は『リポジトリの誤公開』という事故クラスを構造的に消せる一方、サーバのパッチ・バックアップ・コミット前の秘密検出といった、GitHubが肩代わりしていた責任が自分に移ります。その作業を続ける前提なら良い選択、放置すればGitHubより危険になります。

QGitHubの何が怖くて自前にする人が多いのですか？
A

主に『プライベートのつもりが公開設定になっていた』『公開リポにAPIキーをコミットして数分で悪用された』という事故です。公開リポは世界中の自動スキャンbotに常時クロールされるため、秘密の流出は即・実害に直結します。自前運用はこの公開面そのものを無くせます。

Q自前にするなら最低限なにをすべきですか？
A

①コミット前にシークレットを検出するフック（gitleaks等）②Gitサーバ本体とOSのパッチ＋攻撃面の最小化③別の場所へのオフサイトバックアップと復元テスト④鍵の分離・非root・最小権限⑤依存のCVE監視を自前で（osv-scanner/pnpm audit）。これらをやって初めて『GitHubより安全』が成立します。