セキュリティで保護された GitHub リポジトリを維持する方法

• 8 分

ここでは、GitHub リポジトリ管理者が使用できる重要ないくつかのセキュリティ ツールと手法について説明します。

セキュリティで保護された開発戦略の重要性

アプリケーションのセキュリティは重要です。 ニュース サービスでは、企業のシステムへのなんらかの侵害や、企業や顧客の非公開データの盗難に関する記事が頻繁に掲載されています。

では、セキュリティで保護された開発戦略を計画するときに考慮すべき問題は何でしょうか? アクセスできるべきではない人に情報が公開されないようにする必要があることは明らかですが、さらに重要なのは、情報が適切な場合にのみ、変更または破棄されるのを保証する必要があることです。

データにアクセスしている人を適切に認証し、そのための適切なアクセス許可があることを確認する必要があります。 履歴またはアーカイブのデータあるいはログを使用して、問題が発生した場合に証拠を見つけることができるようにする必要があります。

セキュリティで保護されたアプリケーションの構築とデプロイには、多くの側面があります。 考慮すべき 3 つの点を以下に示します。

• 一般知識の問題がある:多くの開発者や他のスタッフ メンバーは、セキュリティについて理解していると思い込んでいますが、理解していません。 サイバーセキュリティは絶えず進化する分野です。 継続的な教育とトレーニングのプログラムが不可欠です。

• コードを正しく、安全に作成する必要がある:コードが正しく作成され、必要な機能が安全に実装されるようにする必要があります。 また、その機能がセキュリティを考慮して設計されたことも確認する必要があります。

• アプリケーションが規則と規制に準拠している必要がある:そのコードが、必要な規則と規制に準拠していることを確認する必要があります。 コードの構築中にコンプライアンスをテストし、それから、デプロイ後であっても定期的に再テストする必要があります。

手順ごとのセキュリティ

セキュリティは、アプリケーションやシステムへ簡単に後から追加できるものではありません。 セキュリティで保護された開発は、ソフトウェア開発ライフサイクルのすべての段階に含まれる必要があります。 クリティカルなアプリケーションや、機密または高度な秘密情報を処理するアプリケーションでは、この概念はさらに重要です。

実際には、開発する内容に対してチームに責任を持たせるには、開発ライフサイクルで、プロセスをシフト レフトする、またはより早い段階で完了する必要があります。 手順を展開時の最終ゲートから前の手順に移動することで、誤りが減り、開発者はより迅速に作業を進めることができます。

これまで、アプリケーションのセキュリティ概念は、開発者にとって重視されていませんでした。 その理由は、教育やトレーニングの問題とは別に、組織においては機能を迅速に開発することが重視されてきたためです。

しかし、DevOps プラクティスの導入により、セキュリティ テストをパイプラインに統合することはより簡単になります。 セキュリティ テストは、セキュリティの専門家によって行われるタスクではなく、日常的な配信プロセスの一部にすぎません。

全体的に、手直しの時間を考慮した場合、開発ライフサイクル内の早い段階で DevOps プラクティスにセキュリティを追加することで、開発チームは早い段階で問題に対応することができます。 早い段階で問題に対応すると、品質の高いソフトウェアの開発にかかる全体的な時間を、実際に短縮することができます。

シフトレフトはプロセスの変更ですが、それは単一の制御や特定のツールのことではありません。 それは、セキュリティのすべてをより開発者中心のものとし、開発者へセキュリティに関するフィードバックを提供することです。

[セキュリティ] タブの機能

GitHub には、リポジトリ内や組織全体でデータをセキュリティで保護するために役立つセキュリティ機能が用意されています。 [セキュリティ] タブを見つけるには:

1. GitHub.com で、リポジトリのメイン ページに移動します。

2. リポジトリ名の下にある [セキュリティ] を選びます。

[セキュリティ] タブから、リポジトリとコードベースの脆弱性を回避するために役立つ機能を GitHub ワークフローに追加できます。 次のような機能が含まれています。

• セキュリティ ポリシー。リポジトリに SECURITY.md ファイルを追加することで、セキュリティ脆弱性を報告する方法をプロジェクトに指定できます。
• Dependabot アラート。お使いのリポジトリが脆弱な依存関係やマルウェアを使っていることが GitHub によって検出されたときに通知されます。
• セキュリティ アドバイザリ。お使いのリポジトリに含まれるセキュリティの脆弱性に関する情報を非公開で議論、修正、公開するために使用できます。
• コード スキャン。コード内の脆弱性やエラーの検出、トリアージ、修正を行うのに役立ちます。

詳細については、GitHub のセキュリティ機能に関する記事を参照してください。

次に、これらの機能の一部について調べ、ソフトウェア開発ライフサイクルのすべてのフェーズにおいて、セキュリティと運用の責任を分散する方法について学習します。

SECURITY.md でセキュリティ ポリシーを伝える

GitHub のコミュニティで相当な利点が得られますが、潜在的なリスクも伴います。 誰でも公式にバグ修正を提案できるということは、ある程度の責任を伴うことになります。 最も重要なのは、根本的なバグを修正できるようになる前にセキュリティ攻撃につながる可能性がある、情報の責任ある公開です。 セキュリティ問題について報告または対処しようとしている開発者は、懸念事項を責任を持って公開するために、リポジトリのルートにある SECURITY.md ファイルを探します。 このファイルの中にガイダンスを提供することで、最終的にはこれらの重大な問題の解決がより迅速になります。

SECURITY.md の詳細については、「Adding a security policy to your repository」 (リポジトリへのセキュリティ ポリシーの追加) を参照してください。

GitHub Security Advisories

GitHub Security Advisories を使用すると、リポジトリの保守担当者は、プロジェクト内でプライベートにセキュリティの脆弱性を検討して修正することができます。 共同で修正を行った後、リポジトリ メンテナはセキュリティ アドバイザリを公開して、セキュリティの脆弱性をプロジェクトのコミュニティに開示することができます。 リポジトリ メンテナがセキュリティ アドバイザリを公開することで、コミュニティはパッケージの依存関係を更新したり、セキュリティの脆弱性の影響を調べたりすることがより簡単になります。 GitHub では、公開されたアドバイザリは共通脆弱性識別子 (CVE) の一覧内に格納されます。 この一覧は、掲載された脆弱性が含まれたソフトウェアを使用している、影響を受けるリポジトリへ自動的に通知するために使用されます。 詳細については、「リポジトリ セキュリティ アドバイザリの概要」を参照してください。

.gitignore を使用して機密ファイルをリポジトリから除外する

開発者は、コミットに含まれるファイルを見落としがちです。 これらの見落とされたファイル (中間ビルド ファイルなど) は問題がないことがあります。 ただし、誰かが不注意で機密データをコミットするリスクが常にあります。 たとえば、悪意のあるアクターが使用することができる、API キーまたはプライベート構成データを、誰かがコミットしてしまう恐れがあります。 このリスクを回避するのに役立つ手法の 1 つは、.gitignore ファイルを作成して維持することです。 コミット用にファイルを集約するときにパスとパターンを無視するように、これらのファイルで git コマンド ライン ユーティリティなどのクライアント ツールに指示します。

次のサンプルでは、ファイルを無視する一般的なユース ケースをいくつか示します。

# User-specific files - Ignore all files ending in ".suo"
*.suo

# Mono auto generated files - Ignore all files starting with "mono_crash."
mono_crash.*

# Build results - Ignore all files in these folders found at any folder depth
[Dd]ebug/
[Rr]elease/
x64/
x86/

# Root config folder - Ignore this directory at the root due to leading slash
# Removing the slash would ignore "config" directories at all depths 
/config

# Ignore intermediate JS build files produced during TypeScript build at any 
# folder depth under /Web/TypeScript. This won't ignore JS files elsewhere. 
/Web/TypeScript/**/*.js

ご利用のリポジトリには、複数の .gitignore ファイルが含まれる場合があります。 設定は親ディレクトリから継承されます。新しい .gitignore ファイル内のフィールドをオーバーライドすると、そのフォルダーとサブフォルダーの親設定より優先されます。 ルートの .gitignore ファイルを維持するには多大な作業量がかかりますが、プロジェクト ディレクトリに .gitignore を追加すると、親とは別にしたほうが維持しやすい、そのプロジェクトに特定の要件 (無視することができないファイルなど) がある場合に役立ちます。

.gitignore の詳細については、「ファイルを無視する」を参照してください。 また、gitignore リポジトリでさまざまなプラットフォーム用に提供されているスターター .gitignore ファイルも確認してください。

機密データをリポジトリから削除する

.gitignore ファイルは、共同作成者が機密データをコミットしてしまうのを防止するのに役立ちますが、この手法はただの (強い) お勧めでしかありません。 開発者は、十分に動機付けされていれば、機密データを回避してファイルを追加することができます。また、時には .gitignore の構成が満たされておらず、(機密データの) ファイルが見落とされる恐れもあります。 プロジェクトの参加者は、リポジトリまたはその履歴の中に含めてはならないデータが含まれたコミットに対して、常に注意を払う必要があります。

ブランチ保護ルール

ブランチ保護ルールを作成して、1 つ以上のブランチに特定のワークフローを適用することができます。 たとえば、保護されたブランチにマージされるすべての pull request に対して、承認レビューまたは状態チェックの合格を要求することができます。

ブランチを保護するワークフローを使用して、次のことができます。

• 変更したコードがビルドできることを確認するためにビルドを実行する
• リンターを実行して、入力ミスや、内部コーディング規則に対する準拠をチェックする
• 自動テストを実行して、コードの動作変更を調べる
• その他

CODEOWNERS ファイルを追加する

CODEOWNERS ファイルをリポジトリに追加することにより、個々のチーム メンバーまたはチーム全体を、コード所有者としてリポジトリ内のパスに割り当てることができます。 その後、これらのコード所有者は、構成されているパス内のファイルに対する変更について、pull request をレビューする必要があります。

# Changes to files with the js extensions need to be reviewed by the js-owner user/group:
*.js    @js-owner

# Changes to files in the builds folder need to be reviewed by the octocat user/group:
/build/ @octocat

CODEOWNERS ファイルは、リポジトリのルート、docs フォルダー、または .github フォルダーに作成できます。