GitHubメンテナ必見、今週中に有効化すべき6つのセキュリティ設定
GitHubで公開リポジトリや社内リポジトリを管理している開発者にとって、セキュリティ設定は後回しになりがちだ。コードを書くのに忙しく、設定画面をじっくり見ている余裕はない、という声も多い。だが無料で使える基本設定を有効にするだけで、攻撃のハードルは劇的に上げられる。
GitHub Security Labが2026年7月1日に公開した記事では、30分で完了する6つの設定が紹介されている。どれも無料で即効性がある。2025年には公開GitHub上で2,865万件のシークレット（APIキーやトークン）が新たに漏洩し、前年比34%増という過去最大の増加幅を記録した。AI支援のコミットではこれが約2倍のペースで起きている。
以下、実際に有効にする手順と効果を解説する。
脆弱性報告の受け皿を整える最初の2ステップ
誰かがプロジェクトの脆弱性を見つけたとき、その報告先が用意されていなければ、善意の報告者は公開Issueに投稿するか、個人の連絡先を探すしかない。前者は修正前に攻撃手法を公開することになり、後者は連絡そのものが届かないリスクがある。これを防ぐのがSECURITY.mdとプライベート脆弱性報告（PVR）の2つだ。
SECURITY.mdの役割と書き方
SECURITY.mdはリポジトリのルートに配置するファイルで、脆弱性の報告方法を明示する。記載内容はシンプルでよい。連絡用のメールアドレス、対象とする脆弱性の範囲、報告者が知っておくべき前提事項があれば書く。
GitHub Security Labの記事では、systemdプロジェクトのセキュリティポリシーが参考例として挙げられている。24時間対応の体制を前提とせず、再現手順の期待値を明確にしている点が実務的だ。この構造を借りて連絡先を差し替えれば、10分程度で作成できる。
プライベート脆弱性報告（PVR）の有効化
SECURITY.mdが「どこに報告するか」を示すのに対し、PVRは「報告を非公開で受け付ける場」を提供する。設定はリポジトリの「Settings → Security」にあるチェックボックスを1つオンにするだけだ。
PVRを有効にすると、研究者は公開されない形で脆弱性を報告できる。メンテナはそれを非公開のままトリアージし、修正完了後に情報を公開するタイミングを自分で決められる。この2つをセットで導入すれば、コミュニティに対して「セキュリティに真剣に取り組んでいる」というシグナルを最も早く送れる。
上の図は、SECURITY.mdの有無で脆弱性報告の流れがどう変わるかを整理したものだ。左側（Before）では報告が公開Issueに向かい、修正前に攻撃手法が晒される。右側（After）では非公開チャネルを通じて修正後に公開できる。
シークレット漏洩と依存関係のリスクを自動でブロックする
コードを書いているとき、APIキーやデータベースの接続文字列をうっかりコミットしてしまった経験はないだろうか。GitGuardianの2026年版レポートによれば、2025年に公開GitHubへ流出した新規シークレットは2,865万件で、前年比34%増。IBMの2025年レポートでは、データ侵害の平均コストは世界で444万ドル、米国では1,022万ドルに達している。
シークレットスキャニングとプッシュ保護
シークレットスキャニング（secret scanning）は、リポジトリにコミットされたAPIトークンや秘密鍵を検知する機能だ。さらにプッシュ保護（push protection）を有効にすると、ローカルでのコミット時にシークレットが含まれている場合、リモートリポジトリにプッシュされる前にブロックする。
この機能は公開リポジトリとプライベートリポジトリの両方で使える。シークレットがローカル環境を離れた時点で、リポジトリへのアクセス権を持つ全員がそれを閲覧できる状態になる。プッシュ前に止めることが何より重要だ。
Dependabotと依存関係レビュー
プロジェクトのコードは自分が書いた部分だけで完結しない。数十から数百の外部パッケージに依存している。Dependabotは、依存パッケージに既知の脆弱性（CVE）が見つかった際にアラートを出す。依存関係レビュー（dependency review）は、プルリクエスト内で追加・更新されるパッケージと、それらに関連する勧告の有無を表示する。
この2つを有効にすると、package.jsonの差分をひとつずつ手作業で確認する必要がなくなり、レビュー時間は2分程度に短縮される。
シークレットスキャニングのプッシュ保護が有効だと、誤ってAPIキーを含んだコミットを作成しても、リモートリポジトリへ到達する前にローカルでブロックされる。設定の有無でリスクが大きく変わる。
コードスキャニングで実装レベルの脆弱性を検出する
コードスキャニング（code scanning）は、リポジトリのコードに対して静的解析を実行し、SQLインジェクション、コマンドインジェクション、危険なデシリアライゼーションなど、実際のバグにつながるパターンを検出する。
GitHubが提供するCodeQLはその解析エンジンだ。2019年にオープンソース向けに無料化され、現在はリポジトリの「Security and Quality」タブからワンクリックでデフォルト設定を適用できる。デフォルト設定はプロジェクトの使用言語に応じて適切なクエリパックを自動選択し、全プルリクエストに対して実行される。
コードスキャニングを敬遠する理由として「設定が面倒そう」という印象があるが、デフォルト設定を使う限り、追加の設定作業は不要だ。GitHub Actionsのワークフローを通じて、プルリクエストごとに自動で解析結果が表示される。
ブランチ保護で全対策を実効的にする
ここまで紹介した5つの設定は、いずれも検知や通知を行うものだ。しかし、検知された問題がマージを止められなければ、タブに積まれたアラートを見ないまま本番に反映されてしまう。この「検知だけで終わらせない」役割を担うのがブランチ保護ルール（branch protection）である。
デフォルトブランチに対して「プルリクエスト必須」「最低1件の承認を要求」というルールを設定するだけで、以下のシナリオを防げる。認証情報が漏洩して悪意のあるプッシュが行われるケース、混乱したコントリビューターが意図せずメインブランチに直接プッシュするケース、深夜に疲れた自分が確認なしで本番へプッシュしてしまうケース。これらはいずれも現実に起きうる。
ブランチ保護は、Dependabotのアラートやコードスキャニングの指摘がマージをブロックする仕組みとしても機能する。検知結果が単なる通知で終わらず、実際の開発フローに組み込まれることで初めて、他の5設定が本来の効果を発揮する。
ブランチ保護を有効にすると、プルリクエストとレビューが必須になる。コードスキャニングやDependabotのアラートも、このゲートを通じて初めてマージを止める力を持つ。
この記事のポイント
- SECURITY.mdとPVRで脆弱性報告の非公開チャネルを確保する
- シークレットスキャニングのプッシュ保護でAPIキー流出をローカル段階で防ぐ
- Dependabotと依存関係レビューで外部パッケージの脆弱性を自動監視する
- コードスキャニングのデフォルト設定はワンクリックで即効性がある
- ブランチ保護ルールがなければ他の設定は「通知に留まり」実効力を持たない
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験