ソースを保護する

このドキュメントでは、ソフトウェアのソースコードを管理するためのベストプラクティスについて説明します。+

ソフトウェアチームがソースを管理する基本的な手順は、バージョン管理システム（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 の拡張機能][jlab]、Colaboratory、[Vertex AI Workbench][vertex] など、さまざまな方法があります。
セキュリティポリシー: 自動ポリシー適用用のポリシーファイルを保存します。たとえば、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 には、プログラマティックエラーやスタイルエラーを自動的にフラグできるリンターが用意されています。リンターはより整合性のあるコードを作成し、コードレビューアが自動チェックで特定しにくい問題に集中できるようにします。

Developing Secure Software は、Open Source Security Foundation（OpenSSF）によって作成された無料のオンラインコースです。ソフトウェアサプライチェーンのセキュリティのコンテキストで、基本的なソフトウェア開発のプラクティスについて説明します。
個々のデベロッパーが準備が整うとすぐに、機能ブランチの pull リクエストでコードレビューを行います。新しいリリースをセキュリティチェックとコードレビューのためにテストするまで待たないでください。
サードパーティライブラリのスキャンなどの脆弱性スキャンを pull リクエストと IDE に統合すると、問題をできるだけ早く特定できます。Google Cloud の On-Demand Scanning API を使用すると、コンテナの脆弱性をローカルでスキャンできます。
マージ前の自動テストを統合して、デベロッパーがアプリケーションを壊す可能性のある変更を特定して修正できるようにします。テストの自動化について確認してください。

承認を統合する

インテグレーションが継続される CI/CD パイプラインでは、コードを本番環境ブランチにマージすると、自動ビルドやロールアウトなどのダウンストリームの変更が生じる可能性があります。このため、マージできるユーザーを保護することは、ソフトウェアのデプロイを保護するうえで重要な部分となります。以下のような点を考慮します。

本番環境のブランチに、保護されたブランチのオーナーを設定します。マージを許可される人数と ID は、アプリケーションのセキュリティ要件に適したものである必要があります。SLSA レベル 4 では、2 つの強力な承認者が必要ですが、承認者の数はリポジトリのコンテンツに適した数にする必要があります。
ほとんどのバージョン管理システムでは、リポジトリオーナーが単独でマージを行うことができるため、リポジトリオーナーの ID を厳密に制御します。
マルチリポジトリとマルチアーティファクトのロールアウトのデプロイとマージの承認プロセスを分離します。

開発を保護するためのツール

Software Delivery Shield は、フルマネージドでエンドツーエンドのソフトウェアサプライチェーンセキュリティソリューションです。デベロッパー、DevOps、セキュリティチームがソフトウェアサプライチェーンのセキュリティ体制を強化するために使用できる Google Cloud サービスに、包括的でモジュール式の一連の機能とツールを提供します。Software Delivery Shield の次のコンポーネントは、ソフトウェアソースコードの保護に役立ちます。

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 ソースの保護は、デベロッパーが IDE で作業する際に、脆弱性のある依存関係の識別やライセンスレポートなどのリアルタイムのセキュリティフィードバックを提供します。これにより、デベロッパーはソフトウェア開発プロセスの開始時にコードを迅速に修正し、修正できます。

機能の可用性: Cloud Code の source protect は、一般公開アクセスには使用できません。この機能にアクセスするには、アクセスリクエストページをご覧ください。