「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ブランチなどに直接変更を反映する際にプルリクエストを強制することと、ステータスチェックを必須化することが挙げられます。
特に、変更を反映するときにプルリクエストを経由する設定は変更が相互に確認されることを保証し、コードの信頼性を高めるために重要な役割を果たします。
設定方法
- GitHubで対象のリポジトリを開き、右上の「Settings」をクリックします。設定画面が開いたら「Branches」を選択し、Add branch rulesetボタンをクリックすると、新しいブランチ保護ルールを作成するための画面が開きます。
- 画面が切り替わると、ブランチ保護ルールの設定画面が表示されます。ここで新しいルールを作成する準備をします。
- 次に、保護したいブランチを選択します。まず
Target branches
セクションで対象のブランチを選びます。 include by pattern
を選択し、main
を入力します。これによりmain
ブランチにブランチ保護ルールを適用できます。ワイルドカードなどを使った柔軟な設定も可能です。 最初に触れませんでしたが、ルールセット(Ruleset Name)の名前は分かりやすくするために先ほど設定したブランチ名(例えばmain
)を使うと良いでしょう。- 続いてブランチルールを設定します。設定項目で「Require a pull request before merging」を有効にすることで、変更を反映するときにプルリクエストを必須にできます。これにより、変更がレビューされないままマージされることを防ぎます。
- 最後に、ルール名の直後にある
Enforcement status
をActive
に変更してルールセットを有効化してから、ページの下部にある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」を有効化
- GitHubのリポジトリにアクセスし、
Security
タブをクリックします。その中のDependabot alerts
を選択してみると、複数の脆弱性情報も表示されています。一覧表に表示されている項目をクリックすると、詳細な情報を確認できます。 Settings
タブをクリックします。Code security
を選択してDependabot version updatesを有効化します。- チェック対象を設定するYAMLファイルを
.github/workflows/dependabot.yml
というファイル名で作成します。パッケージ管理システムにnpmを使用しているためpackage-ecosystem
をnpm
に設定します。またschedule:
のinterval:
はdaily
に設定していますが、必要に応じてweekly
やmonthly
に変更できます。version: 2 updates: - package-ecosystem: "npm" # See documentation for possible values directory: "/" # Location of package manifests schedule: interval: "daily"
Commit changes...
をクリックして、ブラウザ上からコミットして変更を反映します。コミットが反映されるとGitHub Actionsが実行され、Dependabotが自動でプルリクエストを作成します。
このようにDependabotを有効化することで、依存関係のパッケージに新しいバージョンがリリースされた際に自動でプルリクエストが作成されるようになります。またGitHub Actionsで自動テストと組み合わせることで、バージョンアップによる影響を事前に確認ができるようになります。
Secret Scanningで機密情報を守ろう
GitHub上でソースコード管理をしていると、間違えてAPIキーやトークンなどの機密情報をリポジトリにコミットしてしまった経験はありませんか。そんなときに役立つのが「Secret Scanning」です。ここではSecret Scanningの概要から設定方法、メリットを分かりやすく解説します。
Secret Scanningとは
Secret ScanningはGitHubが提供するセキュリティ機能の1つです。この機能はリポジトリ内で公開されてしまったAPIキーやトークンといった機密情報を検出し、警告を出してくれます。
有効化する方法
- リポジトリ設定を開き、GitHubリポジトリのトップページで右上の「Settings」を開いて
Code security
を選択する - 表示された画面で
Secret scanning
のセクションまでスクロールし、Secret Scanning
のオプションを有効化する - リポジトリ内のコードに機密情報が含まれている場合は警告が表示される
実際に機密情報のファイルをコミットしてみる
前の手順でSecret Scanningを有効化しました。ここでは、実際に機密情報が誤ってコミットされた場合に、どのような警告が表示されるのかを確認します。
- まず、機密情報を含むファイルを作成してコミット&プッシュします。以下はAWSのアクセスキーとシークレットキーを含む
api_key.txt
を作成する例です。$ echo "AccessKeyId={{実際のアクセスキー}}\nSecretAccessKey={{実際のシークレットキー}}" > api_key.txt $ git add . $ git commit -m "Add api" $ git push origin main
- プッシュを実行すると以下のような警告メッセージが表示され、プッシュが拒否されます。
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などの機能を利用することで多段的に機密情報の漏洩を防ぐことができます。
おわりに
GitHubのリポジトリを安全に管理する3つの機能「ブランチ保護」「Dependabot」「Secret Scanning」について、それぞれ概要と設定方法、実際の動作例を解説しました。これにより、開発プロセスで機密情報の漏洩を未然に防ぎ、安心してプロジェクトを進める環境を整えることが可能になります。ぜひ、紹介した設定を自分のプロジェクトで試してみてください。