GitHubのセキュリティを強化する10のベストプラクティス
2024年2月5日
0 分で読めます編集者注：2024年2月5日
セキュリティを取り巻く状況は常に変化しています。そのため、現在開発者やセキュリティチームが直面するリスクとその対処方法を反映するよう、この記事を更新しました。
コードが中心となるデジタル環境が急速に進化するなか、コードベースの保護はますます重要になっています。開発者コミュニティでは、コード共有とバージョン管理のプラットフォームとしてGitHubが広く利用されています。しかし、これだけ普及しているGitHubも、開発者が日々直面するさまざまなセキュリティ課題と無縁ではありません。不正アクセスから機密データ漏えいのリスクまで、コードと開発ワークフローを強化するには、開発者がGitHubのセキュリティに関するベストプラクティスを実践することが重要です。
このチートシートでは、GitHubのセキュリティを強化するために実践できる10のベストプラクティスをご紹介します。1ページの資料をダウンロードして、厳選した10項目の詳しい解説をご覧ください。
GitHubで2要素認証を有効化し、必須にする
2要素認証（2FA）は、本人確認のために2種類の認証要素をユーザーに求めるセキュリティプロトコルです。通常は、本人が知っているもの（パスワードなど）と、本人が持っているもの（電話など）を組み合わせます。この多層的なアプローチにより、不正なユーザーがデータにアクセスすることは格段に難しくなります。これは、アプリケーションセキュリティやコードセキュリティに欠かせない対策です。
GitHubには、知的財産や機密性の高いコードが数多く保管されています。開発者やDevOpsの担当者にとって、コードリポジトリのセキュリティと、取り組んでいるオープンソースプロジェクトの完全性を守ることは極めて重要です。2FAを導入すると、セキュリティがさらに強化され、パスワードが漏えいした場合でも、攻撃者が不正にアクセスすることを難しくできます。
GitHubで2FAを有効にするには、次の手順に従います。
GitHubアカウントにログインします。
右上のプロフィール画像をクリックし、Settingsをクリックします。
サイドバーでSecurityをクリックします。
Enable two-factor authenticationボタンをクリックします。
認証アプリを使うか、SMSを受信するかを選択し、画面の指示に従って設定します。
最後に、リカバリーコードが発行されます。2FAの認証方法を利用できなくなった場合に必要となるため、安全な場所に保管してください。
組織のGitHubリポジトリで2要素認証（2FA）を必須にすることは、セキュリティ強化に欠かせないステップです。2FAを必須にすると、リポジトリにアクセスするすべてのチームメンバーに、認証アプリやSMSで受け取る一時コードなど、追加の認証を求めることができます。この追加のセキュリティ対策により、特にパスワードが侵害された場合の不正アクセスのリスクを大幅に低減できます。2FAを必須にすることでコードベースを保護し、安全な開発環境を維持するための積極的な取り組みを示せます。これは、堅牢なアクセス制御のベストプラクティスにも沿ったものです。
リポジトリへのアクセスを制限する
アプリケーションセキュリティやコードセキュリティにおいて、GitHubリポジトリへのアクセスを制限することは不可欠です。ソースコードの閲覧、編集、管理ができるユーザーを効率的に管理できます。これにより、コードの完全性を維持できるだけでなく、潜在的なセキュリティ脅威からも保護できます。
最小権限の原則（PoLP）とは、ユーザーに業務の遂行に必要な最小限のアクセス権のみを付与するというコンピューターセキュリティの考え方です。この原則は、GitHubリポジトリにも適用する必要があります。
リポジトリにPoLPを適用することで、次のようなリスクを軽減できます。
機密データの誤公開：アクセスを制限すると、書き込み権限を持つ人が減り、機密データが誤ってリポジトリにプッシュされる可能性を抑えられます。
悪意のある攻撃：コードベースへのアクセスを制限することで、攻撃者が侵入できる経路を減らせます。
意図しない変更：書き込み権限や管理者権限を持つ人を減らすことで、バグやビルドの失敗につながる意図しないコード変更の可能性を抑えられます。
GitHubでは、リポジトリに対してRead、Triage、Write、Maintain、Adminの複数のアクセスレベルを設定できます。それぞれのレベルでユーザーが実行できる操作は異なります。たとえば、Read権限のユーザーはリポジトリの閲覧とフォークのみ可能ですが、Admin権限のユーザーはリポジトリの設定、チーム、インテグレーションを管理できます。
共同作業者には、役割の遂行に必要な最小限のアクセス権のみを付与しましょう。必要に応じて、後からアクセスレベルを引き上げることもできます。
GitHubで認証情報をコードや設定ファイルとして保存しない
認証情報をGitHubリポジトリに直接保存すると、機密情報が不正アクセスにさらされ、重大なセキュリティリスクとなります。このリスクを軽減するために、環境変数を利用したり、バージョン管理対象のリポジトリ外に設定ファイルを保存したりするなど、安全な方法で機密情報を管理しましょう。認証情報をハードコードする代わりに、外部の変数やファイルをコードから参照することで、機密データと公開されるコードベースを明確に分離し、意図しない情報漏えいのリスクを抑えられます。
開発中は、Snyk Codeを使ってコードにハードコードされた認証情報やシークレットを検出できます。Snyk Code IDE pluginは、コードをコミットする前に潜在的なセキュリティ問題を発見するのに役立つツールです。
さらに、GitLeaksやGit-secretsのような専用ツールも、セキュリティ強化に欠かせません。GitLeaksはリポジトリをスキャンしてシークレットやAPIキーを検出し、情報漏えいにつながるデータが見つかるとすぐに警告します。GitLeaksをCI/CDパイプラインやコミット前のフックに組み込めば、迅速な修正が可能になります。もう一つの有用なツールであるGit-secretsは、コミット、ブランチ、ステージング済みファイルをスキャンして、機密データに該当する所定のパターンを検出し、シークレットの誤登録を防ぎます。該当するパターンが検出されたコミットを拒否するように設定することで、Git-secretsは意図しない情報漏えいを防ぐ強力な対策となり、GitやGitHubのリポジトリのセキュリティを強化します。
これらのツールを開発ワークフローに組み込むことで、GitやGitHubのリポジトリに認証情報を保存することに伴うセキュリティリスクを、より積極的に特定・軽減できます。定期的なスキャンと自動チェックにより、機密情報が漏えいする可能性を大幅に減らし、潜在的なセキュリティ脅威からコードベースを保護できます。
シークレットが検出された場合は、速やかに影響を受けるリポジトリ内の範囲を評価し、特定してください。侵害された認証情報を削除または置き換え、関連するキーやパスワードをローテーションし、チームメンバーにインシデントを知らせます。無効化や置き換えだけでは不十分な場合は、BFG Repo-CleanerなどのツールでGitの履歴を書き換え、機密データを削除することも検討できます。ただし、履歴がローカルマシンやリポジトリのフォークにコピーされている可能性がある点に注意してください。
リポジトリをSnykに接続して脆弱性をスキャンする
アプリケーションセキュリティやコードセキュリティのベストプラクティスの一つは、GitHubリポジトリを開発者向けセキュリティツールのリーディング企業であるSnykに接続することです。このインテグレーションにより、コードベース、コンテナイメージ、オープンソースの依存関係、Infrastructure as Codeの設定を自動でスキャンして脆弱性を検出できます。
GitHubリポジトリをSnykアカウントに接続する手順は簡単です。まずSnykアカウントにサインインし、Integrationsページに移動します。GitHubインテグレーションをクリックし、SnykがGitHubリポジトリにアクセスできるよう、画面の手順に従って認証します。
Snykでは、GitHubリポジトリを次の4種類の方法でスキャンできます。
Snyk Open Source: オープンソースの依存関係をスキャンし、既知の脆弱性を検出します。サードパーティ製パッケージの問題を見つけて修正するために役立つ、オープンソースセキュリティに欠かせないツールです。また、依存関係のライセンスも確認できるため、適切なライセンスコンプライアンスの判断に役立ちます。
Snyk Code: コードベースをスキャンし、セキュリティ上の脆弱性やコード品質の問題を検出します。コードに潜むセキュリティ上の欠陥を特定し、アプリケーションセキュリティの向上を支援します。
Snyk Container: Dockerコンテナイメージをスキャンして脆弱性を検出します。Dockerイメージを安全にデプロイできるようにする、コンテナセキュリティの重要な要素です。
Snyk Iac: Infrastructure as Codeの設定をスキャンします。Kubernetes、Terraform、CloudFormationなどのクラウドインフラストラクチャ設定における脆弱性を検出して修正するため、継続的なモニタリングと修復を提供します。
新しいプルリクエストをスキャンする
GitHubリポジトリをSnykに接続して包括的な脆弱性スキャンを行うだけでなく、新しいプルリクエスト（PR）をリアルタイムでスキャンできるプラットフォームの機能も活用することが重要です。Snykのプルリクエストスキャン機能を使えば、開発中に持ち込まれるセキュリティ上の脆弱性を先回りして特定し、対処できます。開発者がPRで変更を提案すると、Snykは変更されたコードベース、オープンソースの依存関係、コンテナイメージを自動でスキャンし、コードがデフォルトブランチにマージされる前に潜在的な脆弱性を明らかにします。
この先回り型のアプローチにより、開発チームは開発ライフサイクルの早い段階でセキュリティ問題を修正できます。これにより、本番環境に脆弱性が持ち込まれるリスクを軽減します。
SnykをGitHubのワークフローにシームレスに統合することで、コードベースのセキュリティを強化し、ソフトウェア開発プロセス全体で継続的なセキュリティを重視するDevSecOps文化を醸成できます。リポジトリをSnykに接続してプルリクエストスキャンを有効にすれば、防御をさらに強化し、安全なコードだけがデフォルトブランチにマージされるようにできます。
SECURITY.mdファイルを追加する
必須のREADME.mdファイルに加えて、SECURITY.mdファイルを用意することも、プロジェクトのセキュリティ態勢を強化する重要なステップです。この専用ファイルを重要なセキュリティ情報の集約場所として活用することで、透明性を高め、コントリビューターや関係者に明確な指針を示せます。
脆弱性の開示ポリシー
セキュリティ上の問題を発見した人が報告するための明確な手順を定め、連絡先（多くの場合「security@」形式のメールアドレス）を指定します。このポリシーにより、責任ある開示を促し、外部の人がセキュリティ上の懸念を安全に報告できるようになります。また、脆弱性への対応における協力的な取り組みも促進します。
セキュリティ更新ポリシー
新たに特定されたセキュリティ脆弱性に関する情報を、プロジェクトがどのように周知するかを明記します。ユーザーへの通知に利用するチャネルと、問題に速やかに対処するためにユーザーが取るべき手順を含めます。明確な更新ポリシーがあれば、ユーザーは常に最新情報を把握し、デプロイ環境を保護するために必要な対応を取ることができます。
セキュリティに関する設定
プロジェクトをデプロイする際に、セキュリティ態勢に影響を及ぼす可能性のある設定を明示します。このセクションは、セキュリティ対策の設定に関する実践的なガイドとなり、デプロイ環境全体のセキュリティを高めるためにユーザーが選択できる項目を理解するのに役立ちます。
既知のセキュリティ上の課題と今後の改善
認識されているものの、まだ対処されていないセキュリティ上の課題を明示します。また、検討中ではあるものの未実装の今後のセキュリティ改善についても共有します。こうした取り組みは透明性と協力の文化を育み、コントリビューターがプロジェクトのセキュリティ向上に積極的に参加することを促します。
SECURITY.mdファイルは、プロジェクトに安全でオープンな環境を確立するうえで重要な役割を果たします。責任あるセキュリティ対策の基盤となるだけでなく、コントリビューターやユーザーにとって貴重な情報源となり、最終的には、よりレジリエントで安全なプロジェクトエコシステムの実現に貢献します。
ブランチ保護ルールを使用する
ブランチ保護ルールは、DevSecOpsワークフローに不可欠なセキュリティレイヤーを提供し、コードベースの機密性の高い部分に対する不正または誤操作による変更を防ぎます。このセクションでは、ブランチ保護ルールとは何か、GitHubで設定してコードベースのセキュリティを強化する方法を説明します。
GitHubのブランチ保護ルールは、リポジトリ管理者がコード品質を維持し、コラボレーションを管理するために設定できる一連の制御機能です。コード変更をブランチにマージする方法を正確に設定し、適用できます。これはアプリケーションセキュリティとコードセキュリティの重要な要素です。最小権限の原則を適用し、許可されたユーザーだけがコードベースを変更できるようにします。
ブランチ保護ルールで適用できる制御機能には、次のようなものがあります。
マージ前にプルリクエストのレビューを必須にする：保護対象のブランチにマージする前に、少なくとも1人の別のユーザーが変更をレビューして承認するようにします。
マージ前にステータスチェックの合格を必須にする：コードをマージする前に、必要なCIテストがすべて合格していることを確認できます。
一致するブランチへのプッシュを制限する：保護対象のブランチにプッシュできるユーザーまたはチームを指定できます。
直線的なコミット履歴を必須にする：コミット履歴を整理し、理解しやすい状態に保ちます。
ブランチ保護ルールの設定手順
GitHubでブランチ保護ルールを設定するには、次の手順に従います。
GitHubリポジトリに移動し、Settingsタブを開きます。
左側のサイドバーで、Branchesをクリックします。
Branch protection rulesの下にあるAdd ruleをクリックします。
Branch name patternフィールドに、保護するブランチの名前を入力します。
Protect matching branchesの下で、適用する要件を選択します。前述のオプションから選択できます。
Createをクリックして、新しいブランチ保護ルールを保存します。
ブランチ保護ルールを効果的に活用すると、コードベースのセキュリティと信頼性を大幅に高められます。Snykで使用しているほとんどのリポジトリでは、セキュリティ上の理由からmainブランチに直接プッシュできず、PRを使用する必要があります。これはブランチ保護ルールによって適用されています。
SSHトークンと個人キーをローテーションする
SSHトークンと個人キーを定期的にローテーションすることは、GitHubリポジトリのコードセキュリティを強化するうえで欠かせないプラクティスです。このセクションでは、その方法と、アプリケーションセキュリティ、コンテナセキュリティ、DevSecOpsにおいて重要な理由を説明します。
SSHトークンと個人キーのローテーションは、GitHubリポジトリへの不正アクセスを防ぐための先回りしたセキュリティ対策です。悪意のある攻撃者にSSHトークンや個人キーを奪われると、コードベースに甚大な被害をもたらすおそれがあります。これらの認証情報を定期的にローテーションすれば、攻撃者がリポジトリへのアクセスを維持しにくくなり、オープンソースのセキュリティを強化できます。
SSHトークンと個人キーのローテーション方法
GitHubでは、簡単な手順でSSHトークンと個人キーをローテーションできます。手順は次のとおりです。
GitHubアカウントにログインします。
Settings、Developer settings、Personal access tokensの順に移動します。
Generate new tokenをクリックします。
トークンの説明を入力し、このトークンに付与するスコープ（権限）を選択します。
Generate tokenをクリックします。
新しいトークンを生成したら、使用しているすべての場所で古いトークンを置き換えてください。
トークンとキーのローテーションを自動化する
多数のリポジトリや大規模なDevOps環境を抱えるチームにとって、SSHトークンとキーを手動でローテーションするのは大変な作業です。このプロセスを自動化すれば、一貫性を保ちながら時間を節約できます。GitHub ActionsやJenkinsなどのCI/CDパイプラインツールを活用して、ローテーションを自動化できます。
SSHトークンと個人キーのローテーションは、GitHubリポジトリのセキュリティを維持するために欠かせないプラクティスです。目的は作業を煩雑にすることではなく、コードを安全に保ち、不正アクセスを防ぐことです。
依存関係を自動更新する
最新かつ安全なコードベースを維持することは、アプリケーションセキュリティ、コードセキュリティ、コンテナセキュリティ、DevSecOpsにおいて極めて重要です。その重要な要素の1つが、依存関係を定期的に更新することです。古いサードパーティ製ライブラリからセキュリティ脆弱性が見つかることは少なくありません。そのため、セキュリティ侵害のリスクを最小限に抑えるには、依存関係を自動更新する戦略が重要です。このセクションでは、サードパーティ製ライブラリを更新する重要性と、Snykなどのツールを使ってそのプロセスを自動化する方法を解説します。
サードパーティ製ライブラリを再利用すれば、開発者は一から作り直す必要がなくなるため、ソフトウェア開発に欠かせない存在です。しかし、適切に管理しなければ、セキュリティチェーンの弱点になりかねません。古くなったライブラリに、最新バージョンで修正されていない脆弱性が含まれていると、深刻なセキュリティリスクを招くおそれがあります。
依存関係を手動で更新するのは、特に大規模なプロジェクトでは大変で、時間もかかります。そこで役立つのが自動化です。
Snykで依存関係の更新を自動化する
Snykは、依存関係に含まれる脆弱性の特定と修正を支援する強力なツールです。脆弱性スキャン機能に加えて、依存関係の更新プロセスも自動化できます。
GitHubと連携すると、Snykはリポジトリをスキャンし、古くなった依存関係や脆弱性のあるライブラリのバージョンを検出します。その後、依存関係を更新するプルリクエスト（PR）をGitHubで作成するため、更新内容を効率的にレビューしてマージできます。
GitHubをSnykアカウントに接続したら、組織レベルのIntegration SettingsまたはProject SettingsでAutomatic dependency upgrade pull requestsオプションが有効になっていることを確認してください。
これでSnykがリポジトリを監視し、古くなった依存関係に対するPRを作成するため、コードベースを安全かつ最新の状態に保ちやすくなります。
依存関係の更新を自動化することは、すべての開発者とDevOps担当者が取り入れるべきベストプラクティスです。アプリケーションのセキュリティを高めるだけでなく、長期的には時間と労力も節約できます。Snykなどのツールを活用して、サードパーティ製ライブラリのセキュリティ脆弱性に先手を打ち、健全で安全なコードベースを維持しましょう。
機密データにはプライベートリポジトリを使用する
GitHubのようなプラットフォームで機密データを管理する方法を理解することは不可欠です。機密データを保護する最も簡単な方法の1つは、プライベートリポジトリを使用することです。このセクションでは、パブリックリポジトリとプライベートリポジトリの違いと、プライベートリポジトリを使うべき状況について説明します。
GitHubには、パブリックリポジトリとプライベートリポジトリの2種類があります。
パブリックリポジトリ：その名のとおり、誰でも閲覧できます。GitHubユーザーなら誰でも、パブリックリポジトリを閲覧、クローン、フォークできます。ただし、変更をプッシュできるのはリポジトリのコラボレーターのみです。オープンな環境がコラボレーションとオープンソース開発を促進します。
プライベートリポジトリ：プライベートリポジトリを閲覧できるのは、リポジトリのオーナーと、オーナーが明示的に追加したコラボレーターのみです。プライベートリポジトリのURLを知っていても、必要な権限がなければ内容を閲覧できません。
プライベートリポジトリを使うべき状況
パブリックリポジトリはオープンソースプロジェクトや共同開発に適していますが、機密データの保管には向いていません。次のような場合は、プライベートリポジトリの使用を検討してください。
機密データの保護：コードベースにAPIキーやパスワードなどの機密データ、またはその他の秘密情報が含まれる場合は、プライベートリポジトリに保存してください。許可されたコラボレーターだけがデータにアクセスできるようになります。
プロプライエタリなコード：コードベースが独自のもので、一般公開すべきでない場合は、プライベートリポジトリを使用しましょう。業務アプリケーションや有料ソフトウェア製品では、よくあるケースです。
開発段階：プロジェクトが開発の初期段階にあり、まだ一般公開の準備ができていない場合は、プライベートリポジトリに保管するのが最適です。開発中にプロジェクトへのアクセスを管理できます。
パブリックリポジトリの作成を無効にする
セキュリティを強化し機密情報を保護するため、パブリックリポジトリを必要としない組織は、パブリックアクセスを完全に無効にすることを検討してください。この先回りした対策により、誤って公開リポジトリが作成されるのを防ぎ、データ漏えいのリスクを軽減できます。Your Organizations、Settings、Member Privilegesの順に移動してプライベートリポジトリの設定を適用すれば、許可されたユーザーだけがリポジトリにアクセスできます。データ保護のベストプラクティスに沿うだけでなく、リポジトリ管理も効率化され、組織のコードをより安全に管理できる環境が整います。
機密データにはプライベートリポジトリを使用することが、GitHubセキュリティの重要なベストプラクティスです。機密データやプロプライエタリなコードを保護し、コードセキュリティとDevSecOpsの実践を強化できます。
GitHubアプリを賢く使う
GitHubアプリを使うときは、慎重に選ぶことが大切です。さまざまな組織が開発したアプリには便利な機能が数多くありますが、利用を始める前に、次の重要な点を確認しましょう。
権限の確認：安易に権限を付与しないでください。本当に必要な権限だけを付与しましょう。アクセス権を必要最小限にすることで、不要なリスクを抑えられます。
アクセス権について考える：広範なアクセス権が必要な場合は、その必要性を厳しく検討してください。状況が悪化した場合に起こりうる影響を評価しましょう。リスクを慎重に見極めることが重要です。
開発元を確認する：アプリを開発環境に導入する前に、十分な確認を行い、開発元の信頼性を確かめましょう。新しいチームメンバーを採用するように、信頼できるかどうかを見極めることが大切です。
セキュリティを確認する：アプリのセキュリティは、コードを守る最前線の防御と考えましょう。対策に不備があれば、コードが脆弱になるおそれがあります。堅牢な防御を確保するため、セキュリティプロトコルを詳しく確認してください。
定期的に確認する：定期的な整理と見直しは欠かせません。アプリが引き続き必要か、信頼できるかを定期的に評価しましょう。コード環境を整然と保つための取り組みです。
コードのセキュリティは決して軽視できません。常に警戒を怠らず、慎重に選択し、アプリケーションの安定性と安全性を守りましょう。
まとめ
ここまで、現代のソフトウェア開発においてGitHubが果たす重要な役割と、強力なセキュリティのベストプラクティスを導入する重要性を見てきました。紹介した10のガイドラインは、GitHubリポジトリとプロジェクトを保護するための強固な基盤となります。それぞれのプラクティスが相互に補完し、多様な脅威や脆弱性に対する堅牢な防御を構築します。
開発者やDevOpsのプロフェッショナルの皆さんには、これらのセキュリティのベストプラクティスをぜひ実践していただきたいと思います。セキュリティは特定のチームや個人だけの責任ではありません。ソフトウェア開発と運用のあらゆる側面に浸透する、全員の取り組みです。
DevSecOpsでよく言われるように、「セキュリティは全員の責任」です。アプリケーション、データ、そしてユーザーを可能な限り安全に保つために、全員で取り組みましょう。
継続的な学びを大切にし、GitHub環境のセキュリティをさらに強化できる新しいプラクティス、ツール、プロセスを常に取り入れていきましょう。
安全なコーディングを！セキュリティを万全に保ちましょう。
