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

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

安全な開発戦略の重要性

アプリケーションのセキュリティは重要です。 ニュース サービスには、企業のシステムやプライベート企業のシステムや、盗まれた顧客データの侵害に関する記事が頻繁に含まれています。

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

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

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

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

• コードは正しく安全に作成する必要があります。コードが正しく作成され、必要な機能が安全に実装されていることを確認する必要があります。 また、機能がセキュリティを念頭に置いて設計されていることを確認する必要があります。

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

すべての手順でのセキュリティ

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

実際には、チームが開発した内容に責任を持つには、プロセスを 左にシフトするか、開発ライフサイクルの早い段階で完了する必要があります。 デプロイ時の最終ゲートから前の手順にステップを移動することで、間違いが少なくなり、開発者はより迅速に移動できます。

アプリケーションセキュリティの概念は、以前は開発者にとって焦点を当てなかった。 教育とトレーニングの問題とは別に、組織が機能の迅速な開発を重視しているためです。

ただし、DevOps プラクティスの導入により、セキュリティ テストはパイプラインに簡単に統合できます。 セキュリティ スペシャリストによって実行されるタスクではなく、セキュリティ テストは日常の配信プロセスの一部である必要があります。

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

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

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

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

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

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

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

• ファイルをリポジトリに追加して、プロジェクトのセキュリティ脆弱性を報告する方法を指定できるセキュリティ SECURITY.md。
• リポジトリが脆弱な依存関係またはマルウェアを使用していることを GitHub が検出したときに通知する Dependabot アラート。
• リポジトリ内のセキュリティの脆弱性に関する情報を非公開で議論、修正、公開するために使用できるセキュリティ アドバイザリ。
• コード内の 脆弱性とエラーの検出、トリアージ、修正に役立つコード スキャン。
• リポジトリにコミットされたトークン、資格情報、シークレットを検出し、プッシュ前にブロックできるシークレット スキャン。 パブリック リポジトリでは、プッシュ保護が既定で有効になっています。

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

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

セキュリティ ポリシーを SECURITY.md と通信する

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

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

GitHub セキュリティ勧告

GitHub セキュリティ アドバイザリを使用すると、リポジトリの保守担当者は、プロジェクトのセキュリティの脆弱性について非公開で話し合い、修正できます。 リポジトリの保守担当者は、修正プログラムで共同作業を行った後、セキュリティ アドバイザリを公開して、セキュリティの脆弱性をプロジェクトのコミュニティに公開できます。 セキュリティ アドバイザリを公開することで、リポジトリの保守担当者は、コミュニティがパッケージの依存関係を更新し、セキュリティの脆弱性の結果を調査しやすくなります。 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 に対して、承認レビューまたは状態チェックの合格を要求することができます。

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

• ビルドを実行して、コードの変更をビルドできることを確認します。
• リンターを実行して、入力ミスと内部コーディング規則への準拠を確認します。
• 自動テストを実行して、コードの動作の変更を確認します。
• 同様に続きます。

pull request で必須のレビュー担当者

コードを重要なブランチにマージする前にレビューを要求することで、リポジトリのセキュリティを向上させることができます。 必須のレビュー担当者は、品質、セキュリティ、アカウンタビリティを適用するのに役立ちます。

必要な校閲者を構成するには:

1. GitHub のリポジトリに移動します。
2. リポジトリ名の下にある [設定]>[ブランチ] をクリックします。
3. 保護するブランチの横にある [ ルールの追加 ] をクリックするか、既存のルールを編集します。
4. マージする前にプルリクエストレビューを要求するを選択します。
5. 必要に応じて、次の項目を確認します。
   • コード所有者からのレビューを要求する
   • 新しいコミットがプッシュされたときに古いプル要求の承認を無視する
   • 最後のプッシャー以外のユーザーからの承認を要求する

管理者のアクセス許可がないと、必要なレビューをバイパスできません。 マージする前に、提案された変更が別の共同作成者または指定されたコード所有者によって確認されることを確認します。

詳細については、「 保護されたブランチについて」を参照してください。

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 フォルダーに作成できます。