「GitHub」にブランチ保護、Dependabot、Secret Scanningを設定してみよう

2025年2月18日(火)
石本 達也
第3回の今回は、GitHubのリポジトリを安全かつ効率的に管理する「ブランチ保護」「Dependabot」「Secret Scanning」について解説します。

はじめに

「GitHub」はソフトウェア開発において多くの人々に利用されているプラットフォームですが、単なるコードの共有ツールとして使うだけでは、その本当の力を活かしきれません。そこで、GitHubを使って安全で効率的なリポジトリ運用を目指す方法を解説します。

この記事では、「ブランチ保護」「Dependabot」「Secret Scanning」の3つの機能に注目します。これらは、リポジトリのセキュリティと品質を向上させるための重要なツールであり、初心者から中級者の方々にとっても簡単に導入できるものです。

本記事を読むことで、以下のことができるようになります。

  • ブランチ保護: 不適切なコードや誤操作による変更を防ぎ、開発プロセスを強化*1
  • Dependabot: ライブラリやパッケージの依存関係を自動的に管理し、セキュリティリスクを最小化*2
  • Secret Scanning: コード内に含まれる機密情報(APIキーやトークンなど)の漏洩を防ぐ*3

チーム開発や個人プロジェクトでも、これらの機能を取り入れることでコード管理の安心感と効率を高めることが期待できます。それでは、これらの機能の具体的な設定方法と活用方法を見ていきましょう。

*1: https://docs.github.com/ja/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/managing-a-branch-protection-rule
*2: https://docs.github.com/ja/code-security/dependabot/working-with-dependabot
*3: https://docs.github.com/ja/code-security/secret-scanning/introduction/about-secret-scanning

ブランチ保護を設定してみよう

安全な開発フローを構築するために「ブランチ保護ルール」は非常に役立つ機能です。この機能はパブリックリポジトリであれば無料で利用でき、意図しない変更や誤操作を防ぎ、チーム全体で効率的で安全な開発を進めることが可能です。

ブランチ保護ルールとは

ブランチ保護ルールは、特定のブランチへの操作を制御するための機能です。チーム開発におけるコードの質の保証に大きな役割を果たします。この機能には複数のオプションがありますが、主にmainブランチなどに直接変更を反映する際にプルリクエストを強制することと、ステータスチェックを必須化することが挙げられます。

特に、変更を反映するときにプルリクエストを経由する設定は変更が相互に確認されることを保証し、コードの信頼性を高めるために重要な役割を果たします。

設定方法

  1. GitHubで対象のリポジトリを開き、右上の「Settings」をクリックします。設定画面が開いたら「Branches」を選択し、Add branch rulesetボタンをクリックすると、新しいブランチ保護ルールを作成するための画面が開きます。
  2. 画面が切り替わると、ブランチ保護ルールの設定画面が表示されます。ここで新しいルールを作成する準備をします。
  3. 次に、保護したいブランチを選択します。まずTarget branchesセクションで対象のブランチを選びます。
  4. include by patternを選択し、mainを入力します。これによりmainブランチにブランチ保護ルールを適用できます。ワイルドカードなどを使った柔軟な設定も可能です。
    最初に触れませんでしたが、ルールセット(Ruleset Name)の名前は分かりやすくするために先ほど設定したブランチ名(例えばmain)を使うと良いでしょう。
  5. 続いてブランチルールを設定します。設定項目で「Require a pull request before merging」を有効にすることで、変更を反映するときにプルリクエストを必須にできます。これにより、変更がレビューされないままマージされることを防ぎます。
  6. 最後に、ルール名の直後にあるEnforcement statusActiveに変更してルールセットを有効化してから、ページの下部にあるCreateボタンをクリックします(「Dependabotを活用しよう」以降を読み進める前に、ブランチ保護ルールをActiveからDisabledに変更した方がスムーズです)。

これで作成したルールセットが有効になり、mainブランチに対してプルリクエスト時のステータスチェックを必須化できます。設置が有効になったことを確認するために、mainブランチに新しいファイルを追加してプッシュしてみましょう。

$ echo 'Branch Protection' > protected.txt
$ ls
LICENSE       README.md     hello.txt     protected.txt tool.txt
$ git add .
$ git commit -m "Add protected.txt"
$ git push origin main
Enumerating objects: 4, done.
Counting objects: 100% (4/4), done.
Delta compression using up to 10 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 300 bytes | 300.00 KiB/s, done.
Total 3 (delta 1), reused 0 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (1/1), completed with 1 local object.
remote: error: GH013: Repository rule violations found for refs/heads/main.
remote: Review all repository rules at https://github.com/VirtualTech-DevOps/devops-tools/rules?ref=refs%2Fheads%2Fmain
remote: 
remote: - Changes must be made through a pull request.
remote: 
To https://github.com/VirtualTech-DevOps/devops-tools.git
 ! [remote rejected] main -> main (push declined due to repository rule violations)
error: failed to push some refs to 'https://github.com/VirtualTech-DevOps/devops-tools.git'
push declined due to repository rule violationsというエラーメッセージが表示され、プッシュが拒否されました。これは、ブランチ保護ルールによってmainブランチへの変更がプルリクエストを経由して行われるようになったためです。

設定後の効果と注意点

ブランチ保護ルールを導入することで、意図しない変更やバグの追加を防ぎ、プロジェクト全体の安定性を高めることができます。また、チーム内でのコードレビューが促進されるためコード品質が向上し、信頼性の高いプロジェクト運営につながります。しかし、手続きが増えることで作業の効率性に影響が出る可能性もあるため、この点には注意が必要です。

このようなルールを運用する際はチーム全体にルールの意図や重要性を共有し、共通理解を得ることがスムーズな導入の鍵となります。適切に運用することで、チーム全体の開発フローを安全で効率的なものに変えることができます。

Dependabotを活用しよう

GitHubを使ったプロジェクト管理において、依存関係の更新はとても重要なポイントです。ここでは、Dependabotを活用して依存関係を自動で管理し、セキュリティや保守性を向上させる方法を解説します。

Dependabotとは

DependabotはGitHubが提供する機能で、プロジェクトの依存関係を自動で最新状態に保つサポートをしてくれます。例えば、ライブラリやフレームワークに脆弱性が見つかった場合はDependabotが自動で通知し、修正の提案をします。

もし、このようなツールを使わない場合は依存関係を手動で確認して更新する必要があり、大量の時間と手間がかかるだけでなく、重要な脆弱性を見落とすリスクもあります。

  • 依存関係の自動更新: 新しいバージョンがリリースされた際にプルリクエストを生成
  • セキュリティ修正の提案: 脆弱性が見つかったパッケージを素早く特定し、修正を促進

Dependabotを有効化してプルリクエストを確認する流れ

Dependabotを設定し、プルリクエストが生成されるまでを確認します。

バージョンの古いWebアプリケーションを準備
対象となるWebアプリケーションを作成します。Express.js*4を使用して簡単なWebアプリケーションを構築する流れを説明します。ただし、実際にアプリケーションを動かすわけではありません。そのため、必要な依存パッケージをインストールし、package.json*5を作成するまでの手順に絞って進めます。

*4: https://expressjs.com/
*5: https://www.npmjs.com/package/express?activeTab=versions

$ cd devops-tools
$ npm init -y
$ npm install express@3.0.0

作業ディレクトリとして、前回で作成したdevops-toolsを使用します。npm initコマンドはpackage.jsonを作成するために使用されます。対話形式でも設定できますが、ここでは-yオプションを使用し、デフォルト設定で作成しています。

また、npm installコマンドでexpressを指定し、後ろに「@3.0.0」を付けることでバージョン3.0.0のインストールを行っています。

{
  "name": "devops-tools",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "dependencies": {
    "express": "^3.0.0"
  }
}

次に、GitHubのリポジトリを作成し、リモートリポジトリにプッシュします。

$ git add .
$ git commit -m "Add express"
$ git push -u origin main

Dependabotの「Dependabot version updates」を有効化

  1. GitHubのリポジトリにアクセスし、Securityタブをクリックします。その中のDependabot alertsを選択してみると、複数の脆弱性情報も表示されています。一覧表に表示されている項目をクリックすると、詳細な情報を確認できます。
  2. Settingsタブをクリックします。Code securityを選択してDependabot version updatesを有効化します。
  3. チェック対象を設定するYAMLファイルを.github/workflows/dependabot.ymlというファイル名で作成します。パッケージ管理システムにnpmを使用しているためpackage-ecosystemnpmに設定します。またschedule:interval:dailyに設定していますが、必要に応じてweeklymonthlyに変更できます。
    version: 2
    updates:
      - package-ecosystem: "npm" # See documentation for possible values
        directory: "/" # Location of package manifests
        schedule:
          interval: "daily"
  4. Commit changes...をクリックして、ブラウザ上からコミットして変更を反映します。コミットが反映されるとGitHub Actionsが実行され、Dependabotが自動でプルリクエストを作成します。

このようにDependabotを有効化することで、依存関係のパッケージに新しいバージョンがリリースされた際に自動でプルリクエストが作成されるようになります。またGitHub Actionsで自動テストと組み合わせることで、バージョンアップによる影響を事前に確認ができるようになります。

Secret Scanningで機密情報を守ろう

GitHub上でソースコード管理をしていると、間違えてAPIキーやトークンなどの機密情報をリポジトリにコミットしてしまった経験はありませんか。そんなときに役立つのが「Secret Scanning」です。ここではSecret Scanningの概要から設定方法、メリットを分かりやすく解説します。

Secret Scanningとは

Secret ScanningはGitHubが提供するセキュリティ機能の1つです。この機能はリポジトリ内で公開されてしまったAPIキーやトークンといった機密情報を検出し、警告を出してくれます。

有効化する方法

  1. リポジトリ設定を開き、GitHubリポジトリのトップページで右上の「Settings」を開いてCode securityを選択する
  2. 表示された画面でSecret scanningのセクションまでスクロールし、Secret Scanningのオプションを有効化する
  3. リポジトリ内のコードに機密情報が含まれている場合は警告が表示される

実際に機密情報のファイルをコミットしてみる

の手順でSecret Scanningを有効化しました。ここでは、実際に機密情報が誤ってコミットされた場合に、どのような警告が表示されるのかを確認します。

以下の手順はSecret Scanningの動作を確認するためのものであり、機密情報のコミットはリスクを伴います。同じ手順を試す際は自己責任で行ってください。

  1. まず、機密情報を含むファイルを作成してコミット&プッシュします。以下はAWSのアクセスキーとシークレットキーを含むapi_key.txtを作成する例です。
    $ echo "AccessKeyId={{実際のアクセスキー}}\nSecretAccessKey={{実際のシークレットキー}}" > api_key.txt
    $ git add .
    $ git commit -m "Add api"
    $ git push origin main
  2. プッシュを実行すると以下のような警告メッセージが表示され、プッシュが拒否されます。
    Enumerating objects: 5, done.
    Counting objects: 100% (5/5), done.
    Delta compression using up to 10 threads
    Compressing objects: 100% (3/3), done.
    Writing objects: 100% (3/3), 346 bytes | 346.00 KiB/s, done.
    Total 3 (delta 1), reused 0 (delta 0), pack-reused 0
    remote: Resolving deltas: 100% (1/1), completed with 1 local object.
    remote: error: GH013: Repository rule violations found for refs/heads/main.
    remote: 
    remote: - GITHUB PUSH PROTECTION
    remote:   —————————————————————————————————————————
    remote:     Resolve the following violations before pushing again
    remote: 
    remote:     - Push cannot contain secrets
    remote: 
    remote:     
    remote:      (?) Learn how to resolve a blocked push
    remote:      https://docs.github.com/code-security/secret-scanning/working-with-secret-scanning-and-push-protection/working-with-push-protection-from-the-command-line#resolving-a-blocked-push
    remote:     
    remote:     
    remote:       —— Amazon AWS Access Key ID ——————————————————————————
    remote:        locations:
    remote:          - commit: (省略)
    remote:            path: api_key.txt:1
    remote:     
    remote:        (?) To push, remove secret from commit(s) or follow this URL to allow the secret.
    remote:        https://github.com/(省略)
    remote:     
    remote:     
    remote:       —— Amazon AWS Secret Access Key ——————————————————————
    remote:        locations:
    remote:          - commit: (省略)
    remote:            path: api_key.txt:2
    remote:     
    remote:        (?) To push, remove secret from commit(s) or follow this URL to allow the secret.
    remote:        https://github.com/(省略)
    remote:     
    remote: 
    remote: 
    To https://github.com/VirtualTech-DevOps/devops-tools.git
     ! [remote rejected] main -> main (push declined due to repository rule violations)
    error: failed to push some refs to 'https://github.com/VirtualTech-DevOps/devops-tools.git'
    この警告は、Secret Scanning*6が有効化されたリポジトリで機密情報を含むコミットを検出した際に表示されます。GitHubのWeb上で直接コードを編集しようとした場合も同様の警告が表示されます。下図のようにPush Protection機能により機密情報のプッシュが未然に防がれます。
    万が一、警告を無視して機密情報をプッシュした場合でも、GitHubやサポートされているサービスプロバイダーから通知が届きます。例えば、AWSのアクセスキーが漏洩した場合は数分以内に該当するキーが無効化されます。

開発者がそれぞれ心がけることも大切ですが、Secret Scanningなどの機能を利用することで多段的に機密情報の漏洩を防ぐことができます。

*6: https://docs.github.com/ja/code-security/secret-scanning/introduction/supported-secret-scanning-patterns

おわりに

GitHubのリポジトリを安全に管理する3つの機能「ブランチ保護」「Dependabot」「Secret Scanning」について、それぞれ概要と設定方法、実際の動作例を解説しました。これにより、開発プロセスで機密情報の漏洩を未然に防ぎ、安心してプロジェクトを進める環境を整えることが可能になります。ぜひ、紹介した設定を自分のプロジェクトで試してみてください。

日本仮想化技術株式会社
Sierやベンチャー企業を経て、現在は日本仮想化技術でDevOps支援サービス「かんたんDevOps」のDev側を担当。「DevOpsを通じて開発者体験を最大化する」をミッションに理想的な開発環境の実現を目指して技術調査や仕組み作りを行っている。

連載バックナンバー

システム開発技術解説
第3回

「GitHub」にブランチ保護、Dependabot、Secret Scanningを設定してみよう

2025/2/18
第3回の今回は、GitHubのリポジトリを安全かつ効率的に管理する「ブランチ保護」「Dependabot」「Secret Scanning」について解説します。
システム開発技術解説
第2回

「GitHub」にリポジトリを作成してみよう

2025/1/28
第2回の今回は、DevOpsツールの中でも重要な役割を果たす「GitHub」について解説します。
システム開発技術解説
第1回

なぜ、DevOpsの実践にツールが必要となるのか

2025/1/7
本連載では、OSSを題材にDevOpsの開発サイクルを実践的に学ぶ方法を解説していきます。第1回の今回は、その基本概念とツールの重要性について解説します。

Think ITメルマガ会員登録受付中

Think ITでは、技術情報が詰まったメールマガジン「Think IT Weekly」の配信サービスを提供しています。メルマガ会員登録を済ませれば、メルマガだけでなく、さまざまな限定特典を入手できるようになります。

Think ITメルマガ会員のサービス内容を見る

他にもこの記事が読まれています