ソフトウェアをセキュアにデリバリーするには

お客様のニーズを満たすためにソフトウェアやアプリケーションをビルドする企業にとって、スピードと製品化までの時間は最優先事項です。 こうした戦略の遂行に不可欠な要素が、選ばれるプラットフォームとして驚異的な成長を遂げるコンテナの推進要因となっています。 この 1 年間で、製品化までの時間の短縮、可用性の向上、セキュリティの改善、スケーラビリティの向上、コストの削減といったコンテナがもたらすメリットを享受し、これらの組織の多くがサーバーレスのアプローチについても考え始めています。

ソフトウェア ソリューションによって新しい機能や製品を提供するまでの時間は短縮されました。しかし、既存のセキュリティ対策の多くは、その速度の上昇に対処しきれず、以下の3 つの問題のうちの 1 つを引き起こしています。

1. デベロッパーは既存のプロセスによって失速し、遅れをとっている
2. セキュリティ チームとオペレーション チームが妥協することで、組織が脅威にさらされる可能性がある
3. 開発チームは、納期に間に合わせるために既存のセキュリティ プロセスを回避し、脆弱性を抱えている

ここ数年、「ソフトウェア サプライ チェーン」攻撃として分類されるセキュリティ侵害が多数発生しています。

Log4Shell は、2021 年 12 月に確認された Apache Log4j ソフトウェアにおける危険な脆弱性でした。この脆弱性は、最大 CVSS スコア 10 とされ、Java ベースのロギング フレームワークである Log4j の人気が高いため、特に壊滅的な被害をもたらしました。 これが重大な問題になった要因は 2 つあります。1 つ目は、悪用が非常に簡単で、リモートで完全にコードを実行できること、2 つ目は、依存関係ツリーの何層にもわたっていることが多いため、見逃されやすいことでした。

IT マネジメント ソフトウェア会社であるSolarwindsは、同社で使用されているオープンソース ソフトウェアの公式ビルドに悪質なコードを注入する国家単位の不正行為者によって攻撃されました。この悪質なアップデートは、米国財務省や商務省を含む 18,000 の顧客に push されました。

同じく IT マネジメント ソフトウェアのプロバイダである Kaseya は、ゼロデイ脆弱性を利用した攻撃を受けました。この攻撃は、Kaseya VSA サーバーを侵害し悪質なスクリプトを送信して、影響を受けたシステム上のすべてのファイルを暗号化するランサムウェアを配布しました。

これらの事件や類似の事件への対応が急務となり、ホワイトハウスは 2021 年 5 月、連邦政府と取引する組織に対し、ソフトウェアのセキュリティについて一定の基準を維持するよう求める大統領令を発表しました。

「ソフトウェア サプライ チェーン」という用語は、いろいろな意味で非常に適切な言葉だといえます。ソフトウェア サプライ チェーンを構築するためのプロセスは、自動車を製造するためのプロセスと酷似しています。

自動車メーカーは、さまざまな市販部品を入手し、独自の部品を製造してから、高度に自動化されたプロセスで部品を組み立てます。 メーカーは、サードパーティが製造した部品が信頼できる供給元からのものであることを確認することで、その運用の安全性を保証しています。 自社のコンポーネントは、セキュリティ上の問題がないことを確認するために、広範囲にわたってテストされます。 そして最後に、信頼できる工程を経て組み立てが行われ、完成車となります。

ソフトウェア サプライ チェーンは、自動車メーカーと多くの点で似ています。ソフトウェア メーカーは、特定の機能を実現するオープンソースのコンポーネントを入手し、自社の知的財産の中核となるソフトウェアを自社で開発します。 そして、コードはコンポーネントを配備可能なアーティファクトに結合するビルドプロセスを経て、本番環境にデプロイされます。

安全ではないリンクが一つあるだけでソフトウェアのサプライ チェーンへの侵入が起こります。

昨年話題になった攻撃のように、プロセスの各段階が、攻撃者が悪用できる弱点につながる可能性があります。

例えば、平均的な NPM パッケージには、12 の直接依存関係と約 300 の間接依存関係があります。 また、公開されている NPM パッケージのおおよそ 40% 近くが、既知の脆弱性を持つコードに依存していることもわかっています。

これらの脆弱性は、コードを安全でなくしてしまうとは限りません。たとえば、実際に使われることのないライブラリの一部に脆弱性があるかもしれません。 それでも、これらの脆弱性を確認する必要があります。

この問題の規模はとてつもないものです。これらの脆弱性のうち 1 つでもパッチが適用されていないものがあれば、悪意ある攻撃者にソフトウェアのサプライ チェーンに侵入する機会を提供することになりかねません。

Google Cloud では、何十年にもわたり、世界規模のアプリケーションを構築してきました。 Google は、デベロッパーの開発速度を上げるために、多くの社内プロジェクトをオープンソース化してきました。 同時に、ソフトウェア体験の安全性を確保するために、さまざまな社内プロセスも開発しました。

ここでは、あらゆる場所でソフトウェア サプライ チェーンをより強固なものにするために、Google Cloud が行っている取り組みをご紹介します。

• 投資の拡大 - Google Cloud は、2020 年 8 月に、ゼロトラスト プログラムの拡大、ソフトウェア サプライ チェーンの安全確保の支援、オープンソース セキュリティの強化など、サイバーセキュリティ強化のために今後 5 年間で 100 億ドルを投資することを発表しました。
• ソフトウェア アーティファクトのサプライ チェーン レベル（SLSA）– SLSA は、サプライ チェーンの整合性を確保するためのエンドツーエンドのフレームワークです。これは、Google 社内で実施している多くのプロセスに相当するオープンソースです。 SLSA は、何がどのようにビルドされたかという監査可能な証明書を提供します。
• DevOps Research and Assessment（DORA） - Google の DORA チームは 7 年間の研究プログラムを実施し、ソフトウェア デリバリーと組織のパフォーマンスを向上させる多くの技術、プロセス、測定、および文化に関する能力を検証しています。
• Open Source Security Foundation - Google は 2019 年に、サプライ チェーンのセキュリティに関する業界横断的なフォーラムである Open Source Security Foundation を共同設立しました。
• Allstar – Allstar は、組織やリポジトリにインストールし、セキュリティ ポリシーを設定し、適用する GitHub アプリです。 これにより、GitHub プロジェクトのセキュリティのベスト プラクティスを継続的に実施できます。
• Open Source Scorecards - Scorecards は、オープンソース プロジェクトのリスクスコアを提供するために、明確に定義されたセキュリティ ポリシー、コードレビュー プロセス、ファジングや静的コード分析ツールによる継続的なテスト カバレッジなどの評価指標を使用します。

Google は、ソフトウェア サプライ チェーンのセキュリティの問題を克服するためには、次の 2 つが必要だと考えています。

1. 業界標準およびフレームワーク。
2. 最小権限の原則を使用してこれらの標準を実装するマネージド サービスは、ゼロトラスト アーキテクチャと呼ばれます。ゼロトラスト アーキテクチャとは、すべてのユーザー、デバイス、ネットワークを本質的に信頼できないとみなすものです。情報へのアクセス権を得るには、信頼を獲得する必要があります。

これらのアプローチを 1 つずつ見ていきましょう。

現状では、SLSA は業界の合意によって制定される段階的に採用可能なセキュリティ ガイドラインのセットです。 最終的に、SLSA は適用の面でベスト プラクティスのリストとは異なり、特定のパッケージやビルド プラットフォームに「SLSA 証明書」を提供するために、ポリシー エンジンに供給できる監査可能なメタデータの自動作成をサポートする予定です。

SLSA は、段階的かつ実行可能であり、すべてのステップでセキュリティ上のメリットを提供するように設計されています。 あるアーティファクトが最高レベルで認定されれば、消費者はアーティファクトが改ざんされておらず、そのソースを安全に追跡できるという確信を持てます。これは、今日のほとんどのソフトウェアでは不可能ではないにしても、困難なことです。

SLSA は 4 つのレベルで構成されており、SLSA 4 は理想的な最終状態を表しています。下位レベルは、対応する整合性保証のインクリメンタル マイルストーンを表しています。 現在、要件は以下のように定義されています。

SLSA 1 は、ビルドプロセスを完全にスクリプト化して、自動化し、来歴を生成することを要求しています。来歴はビルドプロセス、トップレベルのソース、依存関係など、アーティファクトがどのようにビルドされたかに関するメタデータです。 来歴を知ることで、ソフトウェア利用者はリスクに応じたセキュリティ上の判断ができます。 SLSA 1 の来歴は改ざんを防ぐものではありませんが、コードのソースを特定する基本的なレベルを提供し、脆弱性管理の助けとなることが期待されます。

SLSA 2 では、バージョン管理および認証済みの来歴を生成するホスト型ビルドサービスを使用する必要があります。これらの追加要件は、消費者にソフトウェアの出所に対するより高い信頼性を提供します。 このレベルでは、ビルドサービスが信頼できる範囲での改ざんを来歴が防止します。 SLSA 2 は、SLSA 3 への容易なアップグレード パスも提供します。

SLSA 3 はさらに、ソースの監査の可能性と来歴の完全性を保証するために、ソースとビルド プラットフォームがそれぞれ特定の基準を満たすことを要求しています。SLSA 3 では、ビルド間の汚染など特定の脅威を防ぐことで、以前のレベルよりもはるかに強力な改ざん防止策を提供しています。

SLSA 4 は現在最高レベルで、すべての変更に対して、二人でのレビューと、密閉型の再現可能なビルドプロセスを要求しています。二人でのレビューは、ミスを発見し、不適切な動作を抑止するための業界のベスト プラクティスです。密閉型のビルドは、証明書の依存関係のリストが完全であることを保証します。 再現性のあるビルドは、厳密には必須ではありませんが、監査可能性や信頼性の面で多くの利点があります。 全体として、SLSA 4 は、ソフトウェアが改ざんされていないという高い信頼性を消費者に提供します。 これらの提案レベルの詳細は、対応するソースおよびビルド / 来歴の要件を含め、GitHub リポジトリで確認できます。

ソフトウェアのサプライ チェーンは、コード、ビルド、パッケージ、デプロイ、実行の 5 つのフェーズに分類されます。それぞれのフェーズで、セキュリティに対する考え方を説明します。

Google Cloud では、上記の標準とベスト プラクティスがデフォルトで実装された、コードとビルドからデプロイと実行まで、フルマネージド ツールを提供しています。

ソフトウェアのサプライ チェーンを保護するには、コードの来歴を証明する信頼チェーンを確立し、検証し、維持することで、実際の本番環境で実行されているものが意図したものであることを確実にする必要があります。 Google では、ソフトウェアの開発およびデプロイ プロセスを通じて生成およびチェックされる証明書を通じてこれを実現し、コードレビュー、検証済みコードの来歴、およびポリシーの適用などを通じてアンビエント セキュリティのレベルを可能にしています。 これらのプロセスを組み合わせることで、ソフトウェア サプライ チェーン リスクを最小限に抑え、デベロッパーの生産性を向上できます。

ベースとなるのは、Identity and Access Management や監査ログといった一般的な安全なインフラストラクチャ サービスです。 次に、ソフトウェアのライフサイクルを通じた認証の定義、チェック、実施方法によって、ソフトウェアのサプライ チェーンを保護します。

Google Cloud でポリシーと証明書を用いて開発プロセスのアンビエント セキュリティを実現する方法について詳しく見ていきましょう。

ソフトウェアのサプライ チェーンのセキュリティは、デベロッパーがアプリケーションを設計し、コードを書き始めたときから始まります。 これには、自社のソフトウェアだけでなく、オープンソースのコンポーネントも含まれますが、それぞれ独自の課題があります。

オープンソース ソフトウェアと依存関係

オープンソースは、デベロッパーがより速くモノを作ることを可能にし、組織がより機敏に、より生産的になることを可能にします。 しかし、オープンソース ソフトウェアは決して完璧ではありません。私たちの業界はオープンソース ソフトウェアに依存していますが、その依存関係やそれに伴うさまざまなレベルのリスクについて、多くの場合、ほとんど知見がありません。 ほとんどの企業にとって、リスクは主に脆弱性かライセンスのどちらかに起因します。

オープンソースのソフトウェア、パッケージ、ベースイメージ、その他のアーティファクトは、依存する「信頼チェーン」の基礎を形成するものです。

たとえば、お客様の組織でソフトウェア「A」を作成しているとします。この図は、信頼チェーン、言い換えれば、プロジェクトにおける暗黙の依存関係の数を示しています。 図において、「b」～「h 」は直接依存関係、「i」～「m」は間接依存関係です。

ここで、依存関係ツリーの奥深くに脆弱性があることを考えましょう。 この問題は、多くの部品において非常に早く現れます。 さらに、依存関係は頻繁に変化します。平均的な 1 日で、4 万個の NPM パッケージの依存関係が変化しています。

Open Source Insights は、Google Cloud が構築したツールで、依存関係グラフを提供するため、依存関係ツリーの下まで、自身の依存関係と他の依存関係を確認できます。Open Source Insights は、セキュリティ勧告、ライセンス情報、および複数言語にわたるその他のセキュリティ データを継続的に更新し、すべて一か所で提供します。 Open Source Insights は、オープンソース プロジェクトのリスクスコアを提供する Open Source Scorecards と合わせて使用することで、デベロッパーが数百万のオープンソース パッケージの中からより適切なものを選択できるように支援します。

この懸念を払拭するためには、コードとしての依存関係に注目することが鍵となります。 これらの依存関係がサプライ チェーンの末端に向かうにつれて、より検査が難しくなっていきます。 依存関係を確保するために、サプライから始めることをおすすめします。

• Open Source Insights や OSS Scorecards などのツールを使って、依存関係をより深く理解できます。
• ワークフローの要となる自動プロセスにより、すべてのコード、パッケージ、ベース画像をスキャンして検証します。
• これらの依存関係にアクセスする方法をコントロールします。自社のコードとオープンソースのコードの両方を、徹底したコードレビューと監査要件に基づいた制約のもとでリポジトリとして厳重に管理することが重要です。

ビルドとデプロイのプロセスについては後ほど詳しく説明しますが、ビルドの来歴を確認し、安全なビルド環境を活用し、デプロイ時にイメージの署名とその後の検証を確実に行うことも重要です。

また、デベロッパーが採用できる安全なコーディング手法が複数存在します。

• テストの自動化
• メモリセーフのソフトウェア言語を使用する
• コードレビューの委任
• commit の信頼性を確保する
• 悪質なコードの早期発見
• 機密情報の漏洩を避ける
• ロギングとビルド出力を要求する
• ライセンス管理の活用

ソフトウェア サプライ チェーンを保護するための次のステップは、大規模で安全なビルド環境を確立することです。 ビルドプロセスは、本質的には、リポジトリから潜在的に多くの言語のソースコードをインポートすることから始まり、設定ファイルに記述された仕様を満たすようにビルドを実行します。

Google のようなクラウド プロバイダは、最新のマネージド ビルド環境を提供し、必要なスケールでイメージを構築できます。

ビルドの過程で、考えなければならないことがあります。

• ビルドプロセス中もその後も、機密は守られますか？
• ビルド環境にアクセスできるのは誰ですか？
• 比較的新しい攻撃ベクトルや流出リスクについてはどうですか？

セキュアなビルド環境を構築するためには、まずシークレットから始めます。シークレットは重要で、比較的容易に確保できます。まず、シークレットは決して平文ではなく、可能な限りビルドの一部ではないことを確認します。 その代わり、暗号化されていることを確認し、必要に応じて外部のシークレットを参照するようにビルドをパラメータ化する必要があります。 また、定期的なローテーションを簡略化し、万が一の漏洩の際にも、影響を最小限に抑えられます。

次のステップは、ビルドのためのアクセス許可の設定です。 ビルドプロセスには、さまざまなユーザーとサービス アカウントが関わっています。たとえば、あるユーザーはシークレットを管理する必要があるかもしれませんし、あるユーザーはステップの追加や修正によってビルドプロセスを管理する必要があるかもしれません。さらに、あるユーザーはログの閲覧だけで十分かもしれません。

その際、以下のベスト プラクティスに従うことが重要です。

• 最も重要なのは、最小権限の原則です。 きめ細かなアクセス許可の導入により、ユーザーやサービス アカウントに、効率的な業務遂行に必要な正確なアクセス許可を付与します。
• ユーザーとサービス アカウントの相互作用を把握し、ビルドの設定から実行、ビルドのダウンストリームへの影響までの責任チェーンを明確に理解するようにします。

次に、このプロセスをスケールアップする際には、可能な限りビルドの境界を確立し、構成のコード化とパラメータ化によって自動化を行い、スケールアップを図ります。 これにより、ビルドプロセスに変更があった場合、効果的に監査できます。 さらに、機密性の高いビルドやデプロイに対する承認ゲート、インフラストラクチャの変更に対する pull リクエスト、監査ログの定期的な人力によるレビューを通じて、コンプライアンスのニーズを満たしていることを確認できます。

最後にネットワークがご自身のニーズに合っているかどうかを確認します。ほとんどの場合、独自のソースコードをファイアウォールの内側のプライベート ネットワークでホストするのが最善です。 Google Cloud では、自社のプライベート ネットワーク境界内でロックダウンされたサーバーレス構築環境である Cloud Build のプライベート プール機能や、知的財産の流出を防ぐ VPC Service Controls などの機能を利用できます。

Binary Authorization

IAM は必需品であり、論理的な出発点でもありますが、確実なものではありません。 認証情報の漏洩は重大なセキュリティ リスクとなるため、IAM への依存度を下げるために、エラーの起こりにくい認証ベースのシステムに変更できます。 Google は Binary Authorization と呼ばれるシステムを採用しており、信頼できるワークロードのみをデプロイできます。

Binary Authorization サービスは、プロセス全体を通じて、証明書とポリシー チェックにより信頼チェーンを確立、検証、維持します。 基本的に Binary Authorization は、コードやその他のアーティファクトが本番環境に移行する際に暗号署名（証明書）を生成し、デプロイ前にこれらの証明書をポリシーに基づいてチェックします。

Google Cloud Build を使用する場合、一連の証明書が取得され、全体的な信頼チェーンに追加されます。 たとえば、どのタスクを実行したか、どのようなビルドツールやプロセスを使用したか、などの証明書が作成されます。 特に、Cloud Build は、ビルド構成のソースをキャプチャして、ビルドがスクリプトで行われたことを検証するために使用できるため、SLSA レベル 1 の達成を支援します。 スクリプトによるビルドは、手動によるビルドよりも安全であり、SLSA レベル 1 では必須となります。 さらに、ビルドの来歴やその他の証明書は、コンテナ イメージ ダイジェストを使用して調べることが可能です。コンテナ イメージ ダイジェストは、あらゆる画像にユニークな署名を作成するもので、SLSA レベル 1 にも必要です。

ビルドが完了すれば、本番環境に使えるコンテナ イメージがほぼ完成します。 既存の画像の改ざんや不正な画像のアップロードを防ぐことができる、安全な保管場所が必要不可欠です。 パッケージ マネージャーには、自社製とオープンソース製の両方のビルドイメージと、アプリケーションが使用する言語パッケージが必要です。

Google Cloud の Artifact Registry は、そのようなリポジトリを提供します。Artifact Registry は、組織がコンテナ イメージと言語パッケージ（Maven や NPM など）の両方を一か所で管理するための場所です。 これは Google Cloud のツールとランタイムと完全に統合されており、ネイティブのアーティファクト プロトコルのサポートが付属します。 これにより、CI / CD ツールと簡単に統合して自動化パイプラインを設定できるようになりました。

ビルドの手順と同様に、Artifact Registry へのアクセス許可を十分に検討し、最小権限の原則に従うようにすることが重要です。 不正なアクセスを制限するだけでなく、パッケージ レポジトリはより多くの価値を提供できます。 たとえば、Artifact Registry には脆弱性スキャン機能があり、イメージをスキャンして安全にデプロイできることを確認できます。 このサービスは、常に更新される脆弱性データベースと照らし合わせて画像をスキャンし、新たな脅威に対する評価を行い、脆弱性が発見された場合は警告できます。

このステップでは、アーティファクトの脆弱性の結果が特定のセキュリティのしきい値を満たしているかどうかの証明など、追加のメタデータを生成します。 この情報は分析サービスに格納され、分析サービスはアーティファクトのメタデータを構造化して整理し、Binary Authorization で容易にアクセスできるようにします。 これを利用して、リスクのあるイメージを Google Kubernetes Engine（GKE）にデプロイしないように自動で設定できます。

ソフトウェア セキュリティ サプライ チェーンの最後の 2 つのフェーズは、デプロイと実行です。 これらは 2 つの別々のステップですが、認可されたビルドのみが本番環境に移されることを確実にする方法として、一緒に考えることは理にかなっています。

Google は、どのようなビルドを認可すべきかを決定するためのベスト プラクティスを準備しました。 これは、サプライ チェーンの完全性を確保し、信頼できるアーティファクトのみを生産することから始まります。 次に、ソフトウェア デリバリーのライフサイクルの一部として、脆弱性管理が含まれています。 最後に、この 2 つを組み合わせて、整合性と脆弱性スキャンに関するポリシーに基づいたワークフローを実施します。

この段階まで来ると、コード、ビルド、パッケージの各フェーズをすでに通過しています。サプライ チェーンに沿って取得した認証は、Binary Authorization により信頼性を検証できます。また、自動適用モードでは、認証が組織のポリシーを満たしている場合にのみ、イメージがデプロイされます。監査モードでは、ポリシー違反がログに記録され、アラートがトリガーされます。 また、Binary Authorization を使用すると、承認された Cloud Build プロセスを使用してビルドされたものでなければ、ビルドを実行できないように制限できます。 Binary Authorization は、適切にレビューされ、認証コードのみがデプロイされることを保証します。

信頼できるランタイム環境にイメージをデプロイすることは必須です。Google Cloud のマネージド Kubernetes プラットフォームである GKE は、コンテナに対してセキュリティファーストのアプローチをとっています。

GKE は、注意する必要のあるクラスタ セキュリティの多くに対応します。 クラスタの自動アップグレードにより、リリース チャンネルを使用して Kubernetes のパッチを適用し、自動的に最新に維持できます。 セキュアブート、シールドされたノード、整合性チェックにより、ノードのカーネルとクラスタ コンポーネントが変更されておらず、意図したとおりに動作していること、悪質なノードがクラスタに結合できないことを確認します。 最後に、Confidential Computing では、メモリを暗号化したノードでクラスタを実行することで、処理中であってもデータの機密を保持できます。 さらに、安静時およびネットワーク経由のデータ暗号化により、GKE はコンテナ型ワークロードを実行するための非常に安全でプライベートかつ機密性の高い環境を提供します。

さらに、GKE は、ロードバランサの証明書管理、Workload Identity、クラスタへの内向きを構成して保護するための強力な方法による高度なネットワーク機能を通じて、お客様のアプリケーションのセキュリティを向上できます。また、GKE はサンドボックス環境も提供しており、信頼できないアプリケーションを実行しながら、残りのワークロードを保護できます。

GKE Autopilot では、GKE のセキュリティのベスト プラクティスと機能が自動的に実装されるため、攻撃対象がさらに減少し、セキュリティ問題につながる構成ミスを最小限に抑えられます。

もちろん、デプロイを検証すればよいというものではありません。Binary Authorization は継続的な検証にも対応しており、デプロイ後も定義されたポリシーへの準拠を継続することが可能です。 実行中のアプリケーションが既存または新たに追加されたポリシーに適合しない場合、アラートが作成され、ログに記録されます。そのため、本番環境で実行されているものが正確に意図したものであることを確信できます。

脆弱性の管理

サプライ チェーンのセキュリティのもう一つの側面は、整合性の確保と同時に、脆弱性を迅速に発見し、パッチを適用することです。 攻撃者は、アップストリームのプロジェクトに積極的に脆弱性を挿入するように進化しています。 脆弱性管理と欠陥検出は、ソフトウェア提供のライフサイクルの全段階を通じて組み込まれるべきです。

コードがデプロイできるようになったら、CI / CD パイプラインを使用して、ソースコードと生成されたアーティファクトを包括的にスキャンするために利用可能な多くのツールを活用します。 これらのツールには、静的解析ツール、ファジング ツール、各種脆弱性スキャナが含まれます。

ワークロードを本番環境に導入した後、本番環境で稼働し、ユーザーにサービスを提供している間、新たな脅威をモニタリングし、直ちに対策を講じる計画を立てることが必要です。

まとめ

要約すると、ソフトウェアのサプライ チェーンを保護するためには、SLSA のようなベスト プラクティスを取り入れ、そのベスト プラクティスの実施を支援する信頼できるマネージド サービスを利用することが重要です。

以下のことが重要です。

• コードと依存関係から始めて、それらを信頼できるようにします。
• ビルドシステムを保護し、必要なビルド手順がすべて踏まれたことを証明するために証明書を使用します。
• すべてのパッケージとアーティファクトが信頼でき、改ざんされないことを確認します。
• 誰が何をデプロイできるかを制御し、監査証跡を維持します。 Binary Authorization を使用して、デプロイするすべてのアーティファクトの証明書を検証します。
• 信頼できる環境でアプリケーションを実行し、実行中に誰にも改ざんされないようにします。 新たに発見された脆弱性を常に監視し、お使いのデプロイ環境を保護します。

Google では、この取り組みにおける各ステップにおけるベスト プラクティスをプロダクト ポートフォリオに組み込み、信頼できる基盤を構築しています。

ソフトウェア サプライ チェーンの保護を開始する準備はできましたか？念のため明示しておきますが、どこから開始するかはほぼ恣意的です。サプライ チェーン全体のセキュリティを確保するためのアクションは 1 つではなく、サプライ チェーン全体のセキュリティにおいては、どれかひとつのアクションがその他のアクションよりも重要ということはありません。 ここでは、スタートダッシュのための 4 つの最適化案を紹介します。

1. ソフトウェアにパッチを適用する

既知の脆弱性を持つコードを本番環境に導入してしまった場合、攻撃者の仕事を代行してしまったことになります。 その時点では、ソフトウェアのサプライ チェーンをどれだけ確保しても、すでに侵入されているので、意味がありません。そのため、パッチの適用は非常に重要です。

2. お使いの環境で何が実行されているのかコントロールする

パッチの適用が完了したら、ソフトウェアのサプライ チェーンそのものをコントロールしたいと思うでしょう。 これは、実行中のものが本当にビルドツールや信頼できるリポジトリから来たものであると断言できるようにすることから始まります。 このレベルの管理は、意図的な攻撃と、デベロッパーが安全でないことを知らずにデプロイしてしまった不注意なエラーの両方を防ぐのに有用です。 これにより、クリックテストや Binary Authorization などのツールを追加するための強力な基盤ができあがります。

3. サードパーティ ベンダーのパッケージの安全性を確保する

サプライ チェーンのセキュリティの新たな課題としては、ベンダーのソフトウェアが侵害され、ランサムウェアや不正アクセスの経路として、対象となるお客様に提供されるケースが頻発していることが挙げられます。 お客様の環境で実行するサードパーティ ベンダーのパッケージ - システム管理製品、ネットワーク管理製品、セキュリティ製品など、環境内で実行するサードパーティ ベンダーのパッケージは、多くの場合、高度な権限を持っています。 これらのベンダーには、定型的なセキュリティ ステートメントにとどまらず、使用しているパッケージについてある程度の保証を提供するよう求めることをおすすめします。 SLSA の適合レベルはどの程度か、最近の大統領令の要求事項の範囲内かどうかを尋ねることもおすすめします。

4. ソースコードの非公開のコピーを持つ

オープンソース ソフトウェアを使用している場合、インターネットから直接ダウンロードしてきたバージョンをビルドに使用するのはやめましょう。 その代わり、パッチを適用した非公開コピーを用意しておけば、ビルドのたびにクリーンな場所から始めることができ、ソースコードがどこから来たのか 100% の信頼性を達成できます。

DevOps のベスト プラクティス

1. 6 年分の State of DevOps Report です。ソフトウェア デリバリーのパフォーマンスを予測する能力に関する詳細な情報や、貴社の現状と改良の方向性を見出すために役立つクイック チェックについての記事が含まれています。
2. Google Cloud 2021 Accelerate State of DevOps Report
3. Google Cloud ホワイトペーパー: クラウド ネイティブへの再構築: デベロッパーの生産性を大幅に向上させる革新的なアプローチ

ソフトウェア サプライ チェーンの保護

1. Google Cloud ブログ: ゼロトラストの ID セキュリティとは
2. Google セキュリティ ブログ: SLSA のご紹介: サプライ チェーンの整合性のためのエンドツーエンドのフレームワーク
3. Google Cloud ホワイトペーパー: セキュリティのシフトレフト: ソフトウェア サプライ チェーンの保護