
はじめに:そのライブラリ、本当に安全ですか?
npm install
や pip install
で追加したそのライブラリ、本当に安全だと自信を持って言えますか?
便利なオープンソースの裏には、ある日突然「脆弱性」という名のセキュリティホールが見つかるかもしれません。そうなると、開発した大切なアプリケーションが、いとも簡単に攻撃者の手に渡ってしまう危険性も…。
でも、安心してください。
GitHubには、そんな脅威からあなたのリポジトリ(コードの保管場所)を自動で守ってくれる、優秀な警備システムのような機能が備わっています。
この記事では、数あるGitHubのセキュリティ機能の中から、特に重要で、かつ無料で始められる機能に絞って、何を・どの順番で設定すればよいかをステップバイステップで解説します。外部ツールを使わずに、GitHub公式の機能だけでセキュリティを高める方法を学びましょう。
この記事を読めば、まずは無料で・数クリックで設定できるDependabotから始め、あなたのリポジトリを格段に安全にする方法がわかります。
対象読者
- GitHub を使い始めたばかりの方
- ご自身の書いたコードや利用ライブラリの安全性に、漠然とした不安を感じている開発者の方
- チーム開発でコードの安全基準を統一したいと考えている方
- GitHub が提供する無料のセキュリティ機能について、手軽に・正しく知りたい方
目次
GitHubのセキュリティ機能
GitHubを守る!4人の頼れるセキュリティヒーロー
この記事では、あなたのリポジトリを守る4人の頼れるヒーローを紹介します。まずは全体像を掴みましょう。

- 【執事】Dependabot: プロジェクトの依存関係(ライブラリ)を24時間監視し、脆弱性が見つかると自動で修正案を提案してくれます。まずはこの執事を雇うことから始めましょう。
- 【門番】Branch Protection Rules:
main
ブランチなどの重要なブランチに、安全でないコードがマージされるのを防ぐ「鉄壁の門」です。 - 【探偵】Code Scanning: ソースコードそのものを静的解析し、潜在的なバグや脆弱性をコードが実行される前に発見してくれます。
- 【見張り番】Secret Scanning: リポジトリ内にパスワードやAPIキーなどの機密情報が紛れ込んでいないか、常に目を光らせてくれます。
これらの機能を利用することで、セキュリティ対策を開発の初期段階から自動的に組み込む「シフトレフト」というベストプラクティスを、自然に実践することができます!
💡ワンポイント:開発者を救う「シフトレフト」という考え方
開開発サイクルの終盤、リリース直前になってから重大な脆弱性が見つかり、冷や汗をかきながら修正対応に追われた…そんな経験は筆者にもあります。
「シフトレフト」とは、こうした「手戻り」という名の悪夢を避けるための、極めて実践的な考え方です。
開発工程を設計→実装→テスト→リリースの流れで捉えたとき、従来はテスト工程で行っていたセキュリティチェックを、もっと早い段階、開発者のコーディング中やコミット時にシフトさせることを指します。
これは、品質とセキュリティを、開発者自身が日々の開発プロセスに組み込む開発スタイルです。
シフトレフトは、料理に例えるなら「食材を切っている段階で腐っているものを見つける」ようなもの。全ての調理が終わってから気づくのに比べて、手戻りが圧倒的に少ないですよね?
なぜ、これがエンジニアにとって重要なのか?
- コスト削減: コーディング中にツールからの指摘を修正するのは数分です。しかし、リリース後に同じ問題が発覚すると、原因調査、影響範囲の特定、修正、テスト、再デプロイ…と、数日〜数週間の時間を奪われます。シフトレフトは、この無駄な時間とストレスを軽減できます。
- 本質的な開発への集中: レビューでセキュリティに関する機械的な指摘が減り、ロジックやアーキテクチャといった、人間にしかできない本質的な議論に時間を使えるようになります。
- 自身の市場価値向上: 安全なコードを当たり前に書けるエンジニアは、市場から高く評価されます。実際に私のチームでは、Dependabotを導入したことで、リリース前にLog4Shellのような重大な脆弱性を早期に発見し、未然に修正できた経験があります。
このように、シフトレフトは「やらされる」面倒な作業ではなく、未来の自分を助け、チーム全体の生産性を向上させるための賢い投資なのです。
セキュリティ機能比較サマリー(料金・対象リポジトリ)
今回紹介する4つの機能の概要と料金体系は、以下の通りです。多くは無料で利用できます。
機能名 | 概要 | パブリックリポジトリ | プライベートリポジトリ |
---|---|---|---|
Dependabot | 依存ライブラリの脆弱性を検知し、修正PRを自動作成。 | ✅ 無料 | ✅ 無料 |
Branch Protection | 特定ブランチへのマージルールを強制。 | ✅ 無料 | ⚠️ Proプラン以上 |
Code Scanning | ソースコード自体の脆弱性を静的解析(SAST)で発見。 | ✅ 無料 | ⚠️ GHASが必要 |
Secret Scanning | リポジトリ内の機密情報を検知。 | ✅ 無料 | ⚠️ GHASが必要 |
凡例:
- ✅ 無料: 追加費用なしで利用できます。
- ⚠️ Proプラン以上: 無料プランでは利用できず、有料プラン(Pro, Team, Enterprise)へのアップグレードが必要です。
- ⚠️ GHASが必要: 有料の GitHub Advanced Security (GHAS) ライセンスが必要です。
GitHub Advanced Security (GHAS) とは?
Code ScanningやSecret Scanning(プライベートリポジトリ向け)などの高度なセキュリティ機能を含む、有料のセキュリティ製品群です。主に企業向けのEnterpriseプランに含まれています。
最新の料金体系や各プランの無料枠については、必ずGitHub公式の料金ページで確認してください。
今日から始める!セキュリティ設定3ステップ
ここからは、具体的にどの機能をどの順番で有効にしていくべきかを、3つのステップで解説します。
ステップ1(最優先):【執事】Dependabotを有効にする
まずは、最も手軽で効果の高いDependabotから始めましょう。プロジェクトが利用するライブラリ(依存関係)を常に安全な状態に保ってくれます。
目的:
- 脆弱性スキャン (Dependabot alerts): 利用ライブラリに既知の脆弱性が発見された場合に即座に通知し、修正PRを自動作成します。
- バージョンアップ (Dependabot version updates): ライブラリの新バージョンがリリースされた際に、更新PRを自動作成し、技術的負債の蓄積を防ぎます。
具体的な使い方:
- リポジトリの 「Settings」 > 「Code security and analysis」 を開きます。
- [Dependabot alerts] の「Enable」ボタンをクリックします。これだけで脆弱性のスキャンと通知が始まります。
- [Dependabot security updates] の「Enable」ボタンをクリックします。これで脆弱性修正PRが自動で作成されるようになります。

高度なカスタマイズ (.github/dependabot.yml
):
もしバージョンアップの挙動を細かく制御したい場合は、.github/dependabot.yml
ファイルを作成します。
# .github/dependabot.yml
version: 2
updates:
- package-ecosystem: "npm" # npmパッケージを対象
directory: "/" # package.jsonがあるディレクトリ
schedule:
interval: "weekly" # 週に一度チェック
# 特定のライブラリの更新を無視する
ignore:
- dependency-name: "react"
versions: ["18.x"] # Reactのv18系は無視
# PRに自動でレビュアーを設定
reviewers:
- "my-org/my-reviewer-team"
# 複数の更新を1つのPRにまとめる
groups:
production-dependencies:
dependency-type: "production"
🔗公式ドキュメント
ステップ2:【門番】Branch Protectionで安全を強制する
Dependabotを有効にしたら、次にそのチェックが機能するように「ルール」を設定します。これがブランチ保護(Branch Protection)です。
目的:
main
ブランチなどに、「Dependabotの警告がないこと」や「後述するCode Scanningが成功すること」などをマージの必須条件として設定し、安全でないコードの混入を強制的に防ぎます。
利用手順:
- 「Settings」>「Branches」で、ブランチの保護ルールを作成または編集します。
- 「Require status checks to pass」を有効にします。
- 必須としたいチェック項目(例:DependabotやCode Scanningのチェック)を検索して選択します。

効果:
これにより、セキュリティチェックをパスしないPull Requestはマージできなくなり、開発プロセス全体の安全性が格段に向上します。
🔗公式ドキュメント
ステップ3(より高度な対策):【探偵】と【見張り番】を配備する
最後に、より高度なセキュリティ対策として、Code ScanningとSecret Scanningを有効にします。(※プライベートリポジトリでは有料プランが必要です)
【探偵】Code Scanning:コードの静的解析(SAST)
💡ワンポイント:静的解析(SAST)とは?
SASTは “Static Application Security Testing” の略です。プログラムを実行せずにソースコードそのものを分析し、潜在的なバグや脆弱性のパターンを見つけ出す手法です。
目的:
開発者が書いたコードを分析し、SQLインジェクションやクロスサイトスクリプティング(XSS)といった代表的な脆弱性をコードがマージされる前に検出します。
具体的な使い方:
- リポジトリの 「Security」 > 「Code scanning」 から 「Set up」 をクリックします。
- 「CodeQL Analysis」 の 「Default」 を選択すると、GitHubがリポジトリ内の言語を自動検出し、最適な設定を自動で行ってくれます。
- もし
Default
設定でスキャンがうまくいかない場合(ビルドが必要な言語など)は、Advanced
設定でビルド手順を定義する必要があります。詳細は公式ドキュメントを参照してください。

【見張り番】Secret Scanning:機密情報の漏洩防止
目的:
リポジトリのGit履歴全体をスキャンし、誤ってコミットされたAPIキーやパスワードなどの機密情報を検知します。さらにPush Protection(プッシュ保護)を有効にすれば、機密情報のリモートリポジトリへのプッシュを未然にブロックできます。
具体的な使い方:
- リポジトリの 「Settings」 > 「Code security and analysis」 を開きます。
- 「Secret scanning」と「Push protection」を有効にします(パブリックリポジトリではデフォルトで有効)。

検知後の対応フロー:
- プッシュがブロックされた場合: ターミナルの指示に従い、ローカルのコミットから機密情報を削除し、履歴を修正してから再度プッシュします。
- アラートが通知された場合:
- 【最優先】キーの無効化: 何よりも先に、漏洩したキーやトークンをサービス提供元の管理画面で直ちに無効化(Revoke)してください。 これが被害の拡大を防ぐ最も重要な行動です。
- 履歴からの完全削除: その後、GitHubの公式ドキュメントなどを参考に、Gitのコミット履歴から機密情報を完全に削除します。単に修正コミットを追加するだけでは、過去の履歴に情報が残り続けるため不十分です。 履歴の書き換えは複雑なため、慎重に作業してください。
filter-repo等Gitの履歴操作については、以下の記事で詳細に解説していますので、是非ご覧ください。
🔗公式ドキュメント
まとめ:未来の自分を救う、今日の5分
GitHubのセキュリティ機能は、あなたのコードを守るための強力な味方です。しかも、その多くが無料で、数クリックで有効にできます。
この記事を読み終えた今が、行動を起こす絶好のチャンスです。さっそく、ご自身のGitHubリポジトリを開き、まずはステップ1の「Dependabot」を有効にすることから始めてみませんか?
たった数分の設定が、未来の大きなセキュリティ事故を防ぎ、あなたを「信頼される開発者」へと導きます。ぜひ今日から、セキュアな開発環境の構築を始めてください!
この記事で学んだこと
- セキュリティの第一歩: まずは無料の「Dependabot」を有効にすること。
- 安全の仕組み化: 「Branch Protection」でセキュリティチェックを必須にすること。
- シフトレフトの重要性: 問題を早期に発見することが、開発者自身の時間とストレスを削減すること。
- インシデント対応の鉄則: 万が一キーが漏洩したら、まず「無効化」すること。
この記事で設定したセキュリティ機能を、ぜひあなたのチームにも共有してみてください!安全な開発文化を広めることが、プロダクト全体の価値を高めます。
さあ、あなたのMacを快適な開発環境にしましょう!!
参考資料
- GitHub Docs – GitHub Security