［開発者向け］GitHubがeBPFでデプロイの安全性を高める：循環依存を検知・防止する仕組みとは？

2026-04-18

はじめに

　GitHubのエンジニアリングブログが2026年4月16日、自社のデプロイシステムにおける循環依存の問題をeBPFを活用して解決した取り組みを公開しました。本稿では、GitHub社内のホスト型デプロイシステムが抱える循環依存リスクと、Linuxカーネル技術であるeBPFを用いてどのように検知・防止を実現したかを解説します。

参考記事

タイトル: How GitHub uses eBPF to improve deployment safety
著者: Lawrence Gripper、Aleksey Levenstein
発行元: GitHub Blog
発行日: 2026年4月16日
URL: https://github.blog/engineering/infrastructure/how-github-uses-ebpf-to-improve-deployment-safety/

要点

GitHubは自社コードをgithub.com上でホストしているため、障害時に自分自身のデプロイができなくなる「循環依存」問題を抱えている
循環依存には直接依存・隠れた依存・推移的依存の3種類があり、インシデントが発生するまで気づかれないケースが多い
eBPFのBPF_PROG_TYPE_CGROUP_SKBを用いてcGroupにデプロイスクリプトを隔離し、特定のアウトバウンド通信を選択的にブロックできる
DNS通信を傍受するeBPFプログラムと組み合わせることで、IPアドレスではなくドメイン名単位でブロックリストを管理できる
ブロックされたDNSリクエストとプロセスIDを紐づけ、問題のあるコマンドラインを特定してチームに通知する仕組みを実装した
本システムは6か月かけてロールアウトされ、現在は本番稼働中である

詳細解説

GitHubが抱える「自己参照」の問題

　GitHubは自社のソースコードをgithub.com上でホストしています。これはGitHub自身が最大の顧客でもあることを意味しますが、障害対応の観点では重大なリスクをはらんでいます。github.comがダウンした場合、ソースコードへのアクセス自体が失われるため、「GitHubを直すためにGitHubが必要」という最もシンプルな循環依存が生じます。

　GitHubブログによれば、この問題にはコードのミラーを維持することで対処しています。しかし根本的な課題は残ります。デプロイスクリプト自体がgithub.com等の内部サービスへの依存を新たに生み出してしまうケースを、いかにして防ぐかという問題です。

3種類の循環依存

　GitHubのエンジニアたちは、循環依存を3つのパターンに分類しています。

　直接依存は、デプロイスクリプトがGitHubからオープンソースツールの最新リリースを取得しようとするケースです。障害中はこのダウンロードが失敗し、スクリプトが完了できません。

　隠れた依存は、スクリプトが使用するツール自体がすでにディスクに存在しているにもかかわらず、起動時にアップデート確認のためgithub.comへ通信しようとするケースです。このような依存はレビュー時に見逃されやすく、インシデントが発生するまで発覚しないことが多い点が厄介です。

　推移的依存は、デプロイスクリプトが別の内部サービス（例：マイグレーションサービス）をAPI経由で呼び出し、その内部サービスがさらにGitHubから何かを取得しようとするケースです。障害の影響が複数のサービスをまたいで連鎖するため、原因の特定が難しくなります。

　従来はホストを管理する各チームがスクリプトをレビューして循環依存を特定していましたが、多くの依存関係はインシデントが起きるまで気づかれなかったとGitHubブログは述べています。

eBPFとcGroupによる選択的なネットワーク制御

　単純な解決策としてgithub.comへのアクセスをブロックすることが考えられますが、デプロイ対象のホストは顧客トラフィックを処理するステートフルなサーバーでもあります。全面的なブロックは本番リクエストの処理に影響を与えるため、採用できませんでした。

　ここでeBPFが有効な選択肢として浮上します。eBPF（extended Berkeley Packet Filter）は、Linuxカーネルに安全にカスタムプログラムをロードし、ネットワーキングなどのカーネル機能にフックできる技術です。本来はパケットフィルタリングから始まった技術ですが、現在は可観測性・セキュリティ・ネットワーク制御の幅広い用途に活用されています。

　GitHubのエンジニアが注目したのは BPF_PROG_TYPE_CGROUP_SKB プログラムタイプで、特定のcGroupからのネットワーク送信をフックできます。cGroupはDockerでも使われているLinuxのリソース管理・分離機能で、Dockerなしでも単独で利用できます。デプロイスクリプトのみをcGroup内に配置し、そのプロセスのアウトバウンド通信だけを制限することで、本番トラフィックには一切影響を与えない選択的なブロックが実現できます。実装にはGo言語向けのeBPFライブラリ cilium/ebpf が使用されています。

DNS傍受によるドメインベースのブロックリスト

　CGROUP_SKB はIPアドレス単位で動作するため、GitHub社内のシステム規模と変化の速さを考えると、IPアドレスのブロックリストを最新状態に保つことは現実的ではありませんでした。そこでeBPFのもう一つのプログラムタイプ BPF_PROG_TYPE_CGROUP_SOCK_ADDR を組み合わせています。

　このプログラムタイプはソケット作成時のシステムコールにフックし、接続先IPアドレスを書き換えることができます。GitHubはこれを利用して、cGroup内のDNS通信（ポート53宛て）をすべて自前のユーザースペースDNSプロキシに転送します。プロキシ側でリクエストのドメイン名をブロックリストと照合し、その結果をeBPF Mapsを通じて CGROUP_SKB プログラムに伝えることで、最終的な通信の許可・拒否を決定します。IPアドレスではなくドメイン名で管理できるため、維持コストが大幅に下がると考えられます。

プロセスとコマンドの特定による可視化

　さらに実用性を高める工夫として、ブロックされたDNSリクエストをどのコマンドが発したのかを特定する仕組みも実装されています。CGROUP_SKB プログラム内でDNSトランザクションIDとプロセスID（PID）を取得し、eBPF Mapsに記録します。DNSプロキシ側でトランザクションIDを参照することで問題のあるドメインを要求したプロセスを特定し、/proc/{PID}/cmdline を読み取ることで実際のコマンドラインまで取得できます。

　結果として、ブロック発生時には次のようなログが出力されます。

WARN DNS BLOCKED reason=FromDNSRequest blocked=true domain=github.com. pid=266767 cmd=”curl github.com”

　これにより、チームはどのコマンドが問題の原因かをすぐに把握でき、修正対応が容易になります。

本番稼働と得られた成果

　GitHubブログによれば、このシステムは6か月かけて段階的にロールアウトされ、現在は本番稼働中です。デプロイスクリプトへの問題のある依存が自動的に検出・フラグ付けされる体制が整い、GitHubの安定性向上とインシデント時の平均復旧時間（MTTR）の短縮につながったと報告されています。また、デプロイスクリプトのCPU・メモリ使用量の制限にcGroupを活用できる点も副次的なメリットとして挙げられています。

　本ブログでは以前、GitHubのCI/CDパイプラインにおけるセキュリティ課題として「GitHub Actionsのワークフローインジェクション攻撃」を取り上げました（→ https://jobirun.com/securing-github-actions-workflow-injection/）。今回のeBPFを用いたアプローチは、実行環境レベルでのネットワーク制御という異なる層からデプロイの安全性を高める取り組みだと考えられます。

まとめ

　GitHubは自社サービスへの循環依存という固有の課題に対し、eBPFとcGroupを組み合わせた独自のソリューションで対処しています。ホスト全体への影響を最小限に抑えつつ、デプロイプロセスのみに選択的なネットワーク制御を適用できる点が特徴的です。eBPFの実用的な活用事例として実装面でも参考になる内容で、GitHubは概念実証コードも公開しています。今後の改善にも注目したいところです。