対象：GitHubの「リポジトリ誤公開」やシークレット流出が怖くて、自前のGitサーバー（bare git や Gitea/Forgejo/GitLab）で運用すべきか迷っている個人開発者・小規模運営者。ここでは攻撃手順は扱わず、どちらが自分の構成で安全かという判断だけを扱います。
当サイトの視点：自前運用は『代償とセット』でなければ成立しない
当サイト自身も自前のGitサーバーで運用しています。ただし理由は「誤公開が怖いから」だけではなく、被害範囲（爆発半径）の分離——1つのサービスが侵害されても他へ波及させない——が主目的です。そして自前にする以上、別サーバへのオフサイトバックアップ・秘密をgitに一切入れない運用・依存CVEの自動監視を必ずセットで実践しています。自前運用の安全性は「GitHubを使わないこと」ではなく「肩代わりが消えた分を自分で埋めること」で決まります。
1. 自前運用が本当に消せるリスク
あなたの不安には正しい根拠があります。GitHubの代表的な「公開事故」は、自前運用なら構造的に起こりえません。
公開リポジトリは、世界中の自動スキャンbotに常時クロールされています。.env やAPIキーを誤ってコミットすると、人が気づくより先にbotが拾い、数分で悪用されることが珍しくありません（実例 → 公開リポ経由でキーが漏れ不正課金された話 ／ .env が丸ごと公開された話）。自前運用は、この公開面そのものを無くせます。「プライベートのつもりが公開だった」「削除したはずの秘密が公開フォークに残っていた」という事故のクラスが、設計上発生しません。これは曖昧な気休めではなく、実在する利点です。
2. 代わりに自分が背負うもの（盲点）
ここが本題です。GitHubは見えないところで多くの防御を標準で肩代わりしていました。自前にすると、それらは自分でやらない限り存在しません。
GitHubが肩代わりしていた
- 秘密混入をコミット時にブロック（push protection）
- 依存CVEの自動通知（Dependabot）
- サーバ本体の運用・パッチ・TLS
- 2要素認証・細かな権限・監査ログ
- 高い可用性・冗長なバックアップ
自前では自分の仕事になる
- コミット前の秘密検出フックを自分で入れる
- 依存CVE監視を自分で回す（cron）
- Gitサーバの脆弱性も自分で塞ぐ
- 鍵管理＝事実上の全権アクセス制御
- 消えたら終わり——復元できる備えを自分で
とくに見落としがちなのが2つあります。1つは、あなたが一番恐れている「秘密の流出」を、実はGitHubの方が機械で止めてくれているという逆説です。GitHubのpush protectionは、APIキーらしき文字列を含むコミットをそもそも拒否します。素の自前gitには、その安全網がありません。誤公開は消えても、誤コミットは消えない——だから自前にするなら、コミット前の秘密検出フックは必須です。
もう1つは、Gitサーバ本体が攻撃対象になることです。GitLabのような多機能サーバには過去に深刻な脆弱性（認証なしの遠隔コード実行＝RCE級）が複数あり、パッチを放置した自前サーバは、それ自体が侵入口になります。機能が多いほど攻撃面は広い。素のbare git＋SSHが最も攻撃面が小さく、GitLab/Gitea等は便利な反面、自分でパッチを追い続ける負担が増えます。
3. 自前を「GitHubより安全」にする条件
自前運用を、気休めでなく本当に安全にするための最小セットです。これらを満たして初めて、GitHubより安全だと言えます。
コミット前にシークレットを止める
Gitサーバ本体を最小化＆パッチ
別の場所へオフサイトバックアップ＋復元テスト
鍵を分離し、最小権限・非rootで
依存のCVE監視を自前で回す
4. どっちを選ぶべきか
「自前＝玄人」でも「GitHub＝素人」でもありません。運用を続けられるかで決めます。
自前が向く（条件を満たすなら）
- 誤公開・公開bot悪用の面そのものを無くしたい
- サーバのパッチ・バックアップを自分で続けられる
- コードを第三者に預けたくない／被害範囲を分離したい
- 秘密検出フックと依存監視をセットで導入できる
GitHubの方が安全なことも
- パッチ・バックアップを継続する余力がない → 放置した自前は最も危険
- push protection / Dependabot の自動防御に頼りたい
- 可用性・冗長バックアップを自分で用意できない
- プライベートリポの管理を徹底できる（誤公開は設定運用で防げる）
要は、自前運用は**「GitHubが肩代わりしていた仕事を、自分が引き受ける」契約**です。引き受けて実行するなら、誤公開という大きな事故クラスを消せる強力な選択。引き受けたつもりで放置するなら、パッチ漏れのサーバ＋秘密の誤コミット＋復元できないバックアップという、GitHubより悪い状態になりえます。サプライチェーン経由の混入（xz-utilsバックドアのような）も、預け先がどこであれ依存監視を続けることが防衛線になります。
当サイト自身はどうしているか
当サイトは自前のGitサーバー（素の bare git＋SSH）で運用し、プッシュと同時に別サーバのバックアップへも自動で飛ぶように配線しています。秘密（鍵・パスワード・接続情報）はgitにもドキュメントにも一切書かない運用を徹底し、依存のCVE監視は pnpm audit を毎デプロイ前＋日次で回しています。つまり「GitHubを使わない」こと自体が目的ではなく、誤公開のクラスを消しつつ、消えた肩代わりを全部自分で埋める——その両方をやって初めて、自前運用は安全だと考えています。
次に読む
よくある質問
Q自前のGitサーバーはGitHubより安全ですか？
一概に安全とは言えません。自前運用は『リポジトリの誤公開』という事故クラスを構造的に消せる一方、サーバのパッチ・バックアップ・コミット前の秘密検出といった、GitHubが肩代わりしていた責任が自分に移ります。代償を払う前提なら良い選択、放置すればGitHubより危険になります。
QGitHubの何が怖くて自前にする人が多いのですか？
主に『プライベートのつもりが公開設定になっていた』『公開リポにAPIキーをコミットして数分で悪用された』という事故です。公開リポは世界中の自動スキャンbotに常時クロールされるため、秘密の流出は即・実害に直結します。自前運用はこの公開面そのものを無くせます。
Q自前にするなら最低限なにをすべきですか？
①コミット前にシークレットを検出するフック（gitleaks等）②Gitサーバ本体とOSのパッチ＋攻撃面の最小化③別の場所へのオフサイトバックアップと復元テスト④鍵の分離・非root・最小権限⑤依存のCVE監視を自前で（osv-scanner/pnpm audit）。これらをやって初めて『GitHubより安全』が成立します。