このドキュメントでは、ソフトウェアのソースコードを管理するためのベスト プラクティスについて説明します。+
ソフトウェア チームがソースを管理するために行う基本的なステップは、バージョン管理システム（VCS）を導入することです。バージョン管理システムは、変更の履歴と監査可能性を提供します。GitHub などのホスト型バージョン管理システムには、可用性、安定性、セキュリティ管理、統合されたコードレビュー ツール、他のクラウド サービスとの統合などの追加のメリットがあります。
現在、ほとんどのチームがバージョン管理を使用していますが、バージョン管理システムと CI/CD パイプラインの他の部分との統合を構成する方法は数多くあります。
このドキュメントでは、バージョン管理システムを構成する際のソフトウェア サプライ チェーンのセキュリティに関する考慮事項について説明します。ソフトウェア サプライ チェーンを保護するためのフレームワークである ソフトウェア アーティファクトのサプライ チェーン レベルのベスト プラクティスについて説明します。このフレームワークには、ソース要件など、変更を段階的に実装するための複数レベルの要件が含まれています。
変更履歴と不変のリビジョンを備えたバージョン管理システムは、SLSA レベル 2 の要件です。ソフトウェア サプライ チェーンの開始ベースライン レベルとして、SLSA レベル 2 に準拠することをおすすめします。
SLSA レベル 3 では、ソースとビルド プラットフォームは、検証済みのソース履歴やソース保持ポリシーなど、より厳格なセキュリティ要件に準拠しています。SLSA レベル 4 では、ソースの要件に 2 人によるレビューが追加されます。
アプリケーション ソース以上のバージョン管理を使用する
アプリケーション ソースをバージョン管理に保存することは、過去のレビューや監査が必要な場合に確立されています。ただし、構成、ポリシー、データなど、バージョン管理のメリットを享受できるソースは他にも存在します。次のようなファイルが対象となります。
- コンピューティング インフラストラクチャの可用性とセキュリティに影響するファイル
- ファイナライズにはコラボレーションを必要とするファイル
- 繰り返し可能な承認プロセスを必要とするファイル
- 変更履歴を必要とするファイル
以下に例を示します。
- Infrastructure as Code: インフラストラクチャをスケーラブルで安全な方法で管理したい組織は、Infrastructure as Code を主な手法として使用します。たとえば、Artifact Registry リポジトリを作成する Terraform モジュールをバージョン管理に保存できます。
- 構成管理: 構成管理は Infrastructure as Code に似ていますが、Ansible、Puppet、Chef などのツールを使用してアプリケーション構成を管理します。アプリケーション構成ファイルをバージョン管理システムに保存、管理します。
- データベースの構成と移行スクリプト: プロダクト データベースと分析またはロギング データベースの両方の構成とスクリプトを保存します。
- Jupyter ノートブック: GitHub に保存されているノートブックを使用するには、JupyterLab の拡張機能、Colaboratory、Vertex AI Workbench など、さまざまな方法があります。
- セキュリティ ポリシー: 自動ポリシー適用用のポリシー ファイルを保存します。 たとえば、GKE でのデプロイの動作を許可または拒否する Gatekeeper ポリシーや、ポリシー違反である、Terraform でインフラストラクチャのプロビジョニングを防ぐ Sentinel ポリシーを保存できます。
バージョン管理は、DORA DevOps の調査で特定された、ソフトウェア デリバリーと組織のパフォーマンスを向上させる技術的な能力の 1 つです。スクリプト、ソースコード、構成ファイルをバージョン管理に保存すると、環境の再現と復元、変更のトレースと監査、欠陥への迅速な対応が可能になります。
リポジトリの構成
リポジトリは、コードと関連するロール、権限、統合、承認を整理するための基本的な論理単位です。
リポジトリの構成で発生する可能性のある問題には、次のようなものがあります。
- リポジトリの構成は標準化されていないため、特に、組織が数百または数千のリポジトリを持つ一般的なシナリオでは、リポジトリのセキュリティがアプリケーションにとって適切かどうかを保証するのが難しくなります。
- リポジトリを作成したユーザーは、他のレビューアなしでマージを実行する権限を含む、完全な管理者権限を持つオーナーになります。
- リポジトリをコード分析、ビルドサーバー、問題トラッカー、通知サービス、その他の CI/CD インフラストラクチャの部分と統合するには、かなりの作業が必要になる場合があります。リポジトリの作成と設定に標準的な方法があると、反復作業を省略でき、ベスト プラクティスをサポートできます。
これらの問題に対処するためのベスト プラクティスは次のとおりです。
- リポジトリを、繰り返し可能なセキュリティを意識した自動プロセスで設定します。たとえば、リポジトリが対象とするアプリケーションのセキュリティ要件を組み込んだ Terraform モジュールを設定できます。セキュリティの高いアプリケーションの場合、セキュリティが低いアプリケーションとは異なる、より多くの承認者が必要です。
- リポジトリ管理者がゼロから構成する代わりに、リポジトリ構成テンプレートのセットから新しいリポジトリ構成を選択するための方法を作成します。これらのテンプレートは、アプリケーションのさまざまなセキュリティ レベルを反映し、各セキュリティ レベルに必要なユーザー ID と同期する必要があります。通常、これは、組織内のアプリケーションとインフラストラクチャ、およびそれらを管理するユーザーを反映した階層型のIdentity and Access Control（IAM）システムを使用することを意味します。
- リポジトリ ユーザーに対して、多要素認証による一元化された ID 管理を要求します。
- 一元化された ID 管理により、ユーザーが組織を離れたり、新しいチームに異動したりしても、ソース管理に関する最小限の権限が維持されます。
- 多要素認証を使用すると、ソースに対するフィッシングなどの攻撃のリスクを大幅に軽減できます。2 要素認証は、コード承認者の SLSA レベル 4 要件の 1 つです。
- リポジトリのオーナーは、信頼できる少数の従業員に限定します。これには、バージョン管理と ID 管理システムを統合し、ポリシー設定機能を組織の上位に移動することが必要になる場合があります。可能であれば、リポジトリのオーナーが 2 人目のレビューアなしでマージを実行できないようにします。
コードのレビュー
コードレビューは、組織がソフトウェアの品質とセキュリティを維持するための主な方法です。コードレビューでは、次のようなさまざまな障害モードに対処しようとします。
- ソフトウェア欠陥や柔軟性のない設計を使用したコードの導入。
- 明確に定義されていない API
- デベロッパーが記述した安全でないコードによるセキュリティ問題の導入
- 安全でない、または安全でない可能性のあるサードパーティ ライブラリの追加による、セキュリティの問題の導入。
リスクを軽減する方法には次のようなものがあります。
- ソフトウェア ライフサイクル全体にテスト自動化を実装します。ソースをバージョン管理システムに commit したときにトリガーされる自動テストは、テストで見つかった問題に関するフィードバックをデベロッパーが迅速に得る方法です。
- アプリケーションのセキュリティ レベルに応じて適切なレビューアの数と ID を設定します。たとえば、使用率の低いイントラネット アプリは、一般向けのビジネス クリティカル アプリケーションよりもセキュリティ要件が低くなります。
- 技術的専門知識と commit の変更に必要な信頼レベルの両方に基づいてレビューアを割り当てます。レビューアは、レビュー対象の言語、コードが対話するシステム、およびこのタイプのアプリケーションのセキュリティ リスクについてのエキスパートである必要があります。技術的な専門知識の要件には多くの側面があります。例:
- コードは読みやすか。
- 安全か。
- 適切なサードパーティ ライブラリを使用してるか。
- サードパーティ ライブラリを保護するプロセスがあるか。
- コードは構成可能か。
- API の設計はベスト プラクティスに準拠しているか
レビューは官僚的なステップではなく、ベスト プラクティスに沿った継続した会話とする必要があります。テクノロジー スタックの各部分に関するチェックリスト、スタイルガイド、設計基準を作成し、新しいデベロッパー向けの教育プログラムを作成します。VS Code や IntelliJ などの IDE には、プログラマティック エラーやスタイルエラーを自動的にフラグできるリンターが用意されています。Lint は、デベロッパーがより一貫性のあるコードを作成できるようにし、コード レビュー担当者が自動チェックでは簡単に特定できない問題に集中できるようにします。
安全なソフトウェアの開発は、Open Source Security Foundation（OpenSSF）が作成した無料のオンライン コースです。ソフトウェア サプライ チェーンのセキュリティの観点からの基本的なソフトウェア開発手法について説明します。
個々のデベロッパーが準備ができたらすぐに、機能ブランチの pull リクエストを使用してコードレビューを行います。新しいリリースをセキュリティ チェックとコードレビューのためにテストするまで待たないでください。
サードパーティ ライブラリのスキャンなど、脆弱性スキャンをプル リクエストと IDE に統合すると、問題をできるだけ早く特定できます。Google Cloud の On-Demand Scanning API を使用すると、コンテナをローカルでスキャンして脆弱性を検出できます。
マージ前の自動テストを統合して、デベロッパーがアプリケーションを壊す可能性のある変更を特定して修正できるようにします。 テストの自動化について確認してください。
承認を統合する
インテグレーションが継続される CI/CD パイプラインでは、コードを本番環境ブランチにマージすると、自動ビルドやロールアウトなどのダウンストリームの変更が生じる可能性があります。そのため、マージできるユーザーを保護することは、ソフトウェアのデプロイを保護するうえで重要な要素です。以下のような点を考慮します。
- 本番環境ブランチに保護されたブランチ オーナーを設定します。マージを許可される人数と ID は、アプリケーションのセキュリティ要件に適したものである必要があります。SLSA レベル 4 では、2 人の強力な認証済み承認者が必要ですが、承認者の数はリポジトリのコンテンツに適している必要があります。
- ほとんどのバージョン管理システムでは、リポジトリ オーナーが単独でマージを行うことができるため、リポジトリ オーナーの ID を厳密に制御します。
- マルチリポジトリとマルチアーティファクトのロールアウトでは、デプロイとマージの承認プロセスを分離します。
開発を保護するためのツール
Google Cloud には、ソフトウェア サプライ チェーンのセキュリティ体制を強化するために使用できる一連のモジュラー機能とツールが用意されています。次のコンポーネントは、ソフトウェア ソースコードの保護に役立ちます。
Cloud Workstations（プレビュー）
Cloud Workstations は、Google Cloud 上でフルマネージド開発環境を提供します。IT 管理者とセキュリティ管理者は、開発環境のプロビジョニング、スケーリング、管理、保護を簡単に行うことができます。また、デベロッパーは一貫した構成とカスタマイズ可能なツールを使用して開発環境にアクセスできます。
Cloud Workstations は、アプリケーション開発環境のセキュリティ体制を強化することで、セキュリティのシフトレフトに役立ちます。VPC Service Controls、非公開の上り（内向き）または下り（外向き）ネットワーク、強制イメージ更新、Identity and Access Management アクセス ポリシーなどのセキュリティ機能を備えています。詳細については、Cloud Workstations のドキュメントをご覧ください。
Cloud Code source protect（プレビュー）
Cloud Code は、アプリケーションの作成、デプロイ、Google Cloud との統合を行う IDE サポートを提供します。これにより、デベロッパーはサンプル テンプレートから新しいアプリケーションを作成してカスタマイズし、完成したアプリケーションを実行できます。Cloud Code source protect によって、デベロッパーが IDE で作業する際に、脆弱な依存関係の特定やライセンス レポートなど、リアルタイムのセキュリティ フィードバックが提供されます。これにより、デベロッパーはソフトウェア開発プロセスの開始時にコードを迅速に修正し、修正できます。
機能の可用性: Cloud Code の source protect は、一般公開アクセスには使用できません。この機能にアクセスするには、アクセス リクエスト ページをご覧ください。
次のステップ
- ビルドを保護するためのベスト プラクティスについて学習する。
- 依存関係を保護するためのベスト プラクティスについて学習する。
- デプロイを保護するためのベスト プラクティスについて学習する。