このドキュメントでは、ソフトウェアのソースコードを管理するためのベスト プラクティスについて説明します。+
ソフトウェア チームがソースを管理するために行う基本的なステップは、バージョン管理システム（VCS）を採用することです。バージョン管理システムは、変更の履歴と監査可能性を提供します。GitHub などのホスト型バージョン管理システムには、可用性、安定性、セキュリティ制御、統合コードレビュー ツール、他のクラウド サービスとの統合などのメリットがあります。
現在、ほとんどのチームがバージョン管理を使用していますが、バージョン管理システムとその CI/CD パイプラインの他の部分との統合を構成する方法は数多くあります。
このドキュメントでは、バージョン管理システムを構成する際のソフトウェア サプライ チェーンのセキュリティに関する考慮事項について説明します。このドキュメントでは、ソフトウェア サプライ チェーンを保護するためのフレームワークである Supply-chain Levels for Software Artifacts のベスト プラクティスについて説明します。このフレームワークには、ソース要件など、変更を段階的に実装するための複数のレベルの要件が含まれています。
変更履歴と変更不可のリビジョンを備えたバージョン管理システムは、SLSA レベル 2 の要件です。ソフトウェア サプライ チェーンの開始ベースライン レベルとして、SLSA レベル 2 に準拠することをおすすめします。
SLSA レベル 3 では、ソースとビルドのプラットフォームは、検証済みのソース履歴やソース保持ポリシーなど、より厳格なセキュリティ要件に準拠します。SLSA レベル 4 では、ソース要件に二人でのレビューが追加されます。
アプリケーション ソース以上のバージョン管理を使用する
アプリケーション ソースをバージョン管理に保存することは、過去のレビューや監査が必要な場合に確立されています。ただし、構成、ポリシー、データなど、バージョン管理のメリットを享受できる他のタイプのソースもあります。これには、次のファイルが含まれます。
- コンピューティング インフラストラクチャの可用性とセキュリティに影響するファイル
- ファイナライズにはコラボレーションを必要とするファイル
- 繰り返し可能な承認プロセスを必要とするファイル
- 変更履歴を必要とするファイル
以下に例を示します。
- 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 と同期する必要があります。実際には、通常、組織内のアプリケーションとインフラストラクチャ、およびそれらを担当するユーザーを反映した階層型のID とアクセス制御（IAM）システムを使用します。
- リポジトリ ユーザーに対して、多要素認証による一元化された ID 管理を要求します。
- 一元化された ID 管理により、ユーザーが組織を離れたり、新しいチームに移動したりした場合でも、ソース管理に関する最小権限を維持できます。
- 多要素認証は、ソースに対するフィッシングやその他の種類の攻撃のリスクを大幅に軽減します。2 要素認証は、コード承認者の SLSA レベル 4 の要件の 1 つです。
- リポジトリのオーナーを信頼できる少数の従業員に限定します。これには、バージョン管理を ID 管理システムと統合し、ポリシーを設定する機能を組織の上位に移動することが必要になる場合があります。可能であれば、リポジトリのオーナーが 2 人目のレビューアなしでマージを実行できないようにします。
コードのレビュー
コードレビューは、組織がソフトウェアの品質とセキュリティを維持するための主な方法です。コードレビューでは、次のようなさまざまな障害モードに対処しようとします。
- ソフトウェア欠陥や柔軟性のない設計を使用したコードの導入。
- API の定義が不十分
- デベロッパーが記述した安全でないコードによる、セキュリティの問題の導入
- 安全でない、または安全でない可能性のあるサードパーティ ライブラリの追加による、セキュリティの問題の導入。
リスクを軽減する方法としては、次のようなものがあります。
- ソフトウェア ライフサイクル全体でテスト自動化を実装します。ソースをバージョン管理システムに commit したときにトリガーされる自動テストは、テストで検出された問題に関するフィードバックをデベロッパーが迅速に取得する方法です。
- アプリケーションのセキュリティ レベルに応じて適切なレビューアの数と ID を設定します。たとえば、使用率の低いイントラネット アプリは、一般向けのビジネス クリティカル アプリケーションよりもセキュリティ要件が低くなります。
- 技術的専門知識と commit の変更に必要な信頼レベルの両方に基づいてレビューアを割り当てます。レビューアは、レビュー対象の言語、コードが対話するシステム、およびこのタイプのアプリケーションのセキュリティ リスクについてのエキスパートである必要があります。技術的な専門知識の要件には、多くの側面があります。例:
- コードは読みやすか。
- 安全か。
- 適切なサードパーティ ライブラリを使用してるか。
- サードパーティ ライブラリを保護するプロセスがあるか。
- コードは構成可能か。
- API 設計はベスト プラクティスに従っているか。
レビューは官僚的なステップではなく、ベスト プラクティスに沿った継続した会話とする必要があります。技術スタックの各部分に関するチェックリスト、スタイルガイド、設計基準を作成し、新しいデベロッパー向けの教育プログラムも作成します。VS Code や IntelliJ などの IDE には、プログラマティック エラーやスタイルエラーを自動的にフラグできるリンターが用意されています。リンターは、デベロッパーがより一貫性のあるコードを作成するのに役立ち、コード レビュー担当者は自動チェックでは特定しにくい問題に集中できます。
安全なソフトウェアの開発は、Open Source Security Foundation（OpenSSF）が作成した無料のオンライン コースです。ソフトウェア サプライ チェーンのセキュリティの観点から、基本的なソフトウェア開発手法について説明します。
個々のデベロッパーの準備が整い次第、機能ブランチのプルリクエストでコードレビューを実施します。新しいリリースをセキュリティ チェックとコードレビューのためにテストするまで待たないでください。
脆弱性スキャン（サードパーティ ライブラリのスキャンを含む）をプルリクエストと 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 は、一般公開アクセスには使用できません。この機能にアクセスするには、アクセス リクエスト ページをご覧ください。
次のステップ
- ビルドを保護するためのベスト プラクティスについて学習する。
- 依存関係を保護するためのベスト プラクティスについて学習する。
- デプロイを保護するためのベスト プラクティスについて学習する。