だんだんと皆さんの意識が高まってきているので、 ソフトウェアのサプライチェーンを保護する あらゆる組織のサイバー セキュリティ戦略の重要な部分である必要があります。
ソフトウェア サプライ チェーンの脅威を軽減するための包括的な戦略を作成する際の主な困難の 1 つは、サプライ チェーンの複雑さと多様性です。各サプライ チェーンは独自であり、関与する要素は常に変化しているため、自社のサプライ チェーン、ましてやサプライ チェーンが生成するソフトウェアを信頼することが困難になっています。
この記事では、ソフトウェアの利用者と制作者が SDLC を保護するための信頼とコンプライアンスを透過的に実証し、セキュリティのベスト プラクティスを促進し、規制要件を満たし、緩和することを可能にする継続的コンプライアンス プラットフォームについて説明します。 サイバーリスク aテストステーション.
私たちが提案するモデルは、好みのプラットフォームやユースケースに関係なく、簡単に拡張してスタックに統合できるセット ブロックで構成されています。最後に、次を使用して基本的な検証ポリシーを示します。 Scribe の Valint ツール このプロセスが最初に心配するほど複雑ではないことを示すためです。
サプライチェーンカオス理論
サプライチェーンを保護する際の主な課題の 1 つは、関連するシステムが非常に複雑であることです。ソフトウェア サプライ チェーンには、環境の一部として、またはコード ベースに統合されたソフトウェアとして、最終製品の作成に関与するすべてのソフトウェアが含まれます。この説明から、これらのサプライ チェーンは広大であり、開発者がコードを書き始めた瞬間から、コンパイル、テスト、統合を経て、最終製品が実行され、あらゆる部分が組み込まれる時点に至るまで、すべてが含まれていることがわかります。途中で使用したソフトウェアとライブラリ。
このようなシステムのセキュリティ モデルを定義するには、膨大なプログラミングを理解する必要があります。 言語、パッケージ マネージャー、製品、テクノロジー スタック、CI サービス、クラウド プロバイダー、依存関係インポート、VM、オペレーティング システム、および特定のサプライ チェーンに含まれる可能性のあるその他のコンポーネント。このようなシステム内では、アプリケーション、トークン、キー、その他の形式のアクセス許可など、リスクにさらされる可能性のある幅広い資産を考慮することが重要です。
ポリシー検証モデルの概要
私たちが提案するモデルには、サプライ チェーンのセキュリティとコンプライアンスを確保するために連携して機能するいくつかの構成要素が含まれています。. これらの構成要素は、ソフトウェアのセキュリティ面とソフトウェア サプライ チェーン規制への準拠を継続的に検証するために必要です。
- 証拠: ポリシーによって自動的に使用されることを目的とした不変オブジェクト。これらのオブジェクトには、ポリシーの適用を有効にし、コンプライアンス要件を満たすために必要なメタデータが含まれています。証拠コンテンツには、アーティファクト、イベント、設定に関するメタデータが含まれますが、実際のレポート、構成、またはスキャンを収集することもできます。
証拠 署名された形式と署名されていない形式の両方が存在する場合があります。 i に従うことをお勧めしますn-toto 認証仕様 署名されたものを利用して 証明 そして署名なし ステートメント それぞれフォーマットします。- 証明書 (別名、検証可能な署名付き証拠): 特定の事柄に関連する検証可能な証拠 環境コンテキスト、何らかの形式の PKI 署名を使用して信頼を伝えます。
- 環境コンテキスト: コンテキスト情報はモデルを結び付けます。
それは、証拠がどこから来たのか、それにどのような情報が含まれているのかという疑問に答えます。コンテキストが証拠の一部であるのではなく、証拠にリンクされていることが重要です。複数の証拠を同じコンテキストにリンクさせることができ、このモデルにより証拠の検索と取得がより簡単かつ効率的に行えるためです。
基本的に、環境コンテキストはラベル付けシステムであり、ほとんどのラベルが環境、プラットフォーム、またはアーティファクトから読み取られます。ラベルは、開発プロセスおよび CI/CD パイプラインの多くのプロセスへの正規化されたアクセスを提供します。 Git リポジトリ、タグ、コミットなどの証拠の出所に関連する側面だけでなく、ワークフロー名、ジョブ名、runID などにも関連します。環境コンテキストには、アーティファクトのハッシュ、名前、タグなどの主題の側面も含まれる場合があります。
コンテキストは、in-toto の延長として見ることができます。 認証仕様、署名されたペイロードに統合されます。ラベル付けシステムを使用すると、ポリシー評価フェーズに、さまざまな側面でラベルによる証拠を照会する方法を提供できます。さらに、コンテキストデータを政策評価プロセスの一部として使用して、証拠に「状況認識」を追加することもできます。
- ポリシー： 必要なコンプライアンス レポートを定義するユーザー構成のポリシー モジュールのセット。ポリシーでは、ビルド パイプラインまたは開発プロセスに含まれるさまざまな種類の製品またはシステムに対して、最低限のセキュリティ標準または必要なコンプライアンス レベルを指定する場合があります。最も重要なことは、ポリシー評価の結果として、次のようなコンプライアンス レポートが作成されることです。 アテステーション 同じように。これにより、コンプライアンス レポートを管理する (たとえば、コンプライアンス ステータスを関係者に公開する) だけでなく、組織のより広範なコンプライアンス規制をカプセル化する可能性のあるより複雑なポリシーにコンプライアンス レポートを利用することもできます。ポリシーは次のようにグループ化できます。 ポリシーモジュール。これらは、いくつかの特性を共有するポリシー ルールのセットを実装するプラグインです (ソフトウェア モジュールと同様)。これらのプラグインは、ポリシー プロバイダーによって提供されます (詳細は後ほど)。
ポリシー モジュールを評価すると、評価、コンプライアンスの詳細、問題のセキュリティ規制に関する評決を含む結果が得られます。さらに、結果には、コンプライアンスについて評価された証拠モジュールを追跡するために必要な証拠の履歴証跡が含まれます。 - 店舗: ホスティング、アップロード/ダウンロード、証拠のクエリ機能を提供するサービス (これについては後で詳しく説明します)。これらは、イメージ レジストリ (ストレージとしての OCI)、専用サービス (つまり、Scribe サービス)、または単にローカル ファイル システム上で利用できます。
- ポリシープロバイダー: これらは、ポリシー モジュールの署名と提供を担当するエンティティ (企業、組織) です。プロバイダーは、証明書の一種としてポリシーを提供することで、ポリシー自体に信頼性と透明性を伝えます。たとえば、OPA バンドル認証により、規制当局はポリシー モジュールを実装した公式 OPA バンドルを公開および署名できるようになります。
これらのビルディング ブロックを利用することで、組織はビルド パイプラインと開発ライフサイクルのセキュリティとコンプライアンスを比較的簡単に検証できるようになります。
仕組み
このワークフローの開始点は、ソフトウェア製品またはコンポーネントの証拠を生成する開発者またはシステムです。証拠コンテンツ、コンテキスト情報、件名、署名が収集され、証拠ストアにアップロードされます。
逆に言えば、コンプライアンス レポートは、組織のニーズと要件に適合したポリシーを評価することによって作成されます。
政策評価ではコンテキスト情報を使用して、サプライチェーンによって生成された証拠を照会し、規制が必要とする可能性のあるすべての情報が証拠に含まれていることを確認できます。.
追加の利点として、ポリシーとコンプライアンス レポート自体が証拠としてアクセスできるため、透明性と信頼性が得られるだけでなく、関連するすべての証拠までの履歴追跡が可能になります。これにより、組織はコンプライアンス レポートを管理できるだけでなく、ソフトウェア利用者に信頼を伝えるための信頼できる証明書として使用することもできます。.
このフローを利用することで、組織や関係者はリスクを軽減し、透明性を提供し、サプライチェーン内のコンプライアンスを確保することができ、混乱による影響を軽減し、製品全体のセキュリティと信頼性を向上させることができます。
政策評価
この 評価 ポリシーの検証は、それぞれが特定の規制とコンプライアンスのニーズを支持する一連のポリシー モジュールを検証することによって行われます。
ポリシー評価では、各モジュールに次の 2 つの簡単な質問があります。
- モジュールに準拠するにはどのような証拠が必要ですか?
- コンプライアンスを証明する証拠の基準は何ですか?
たとえば、次のようなコンテキストでは、 SLSA (ソフトウェアアーティファクトのサプライチェーンレベル) フレームワーク、ポリシー モジュールは、セキュリティ要件に準拠するために、署名された SLSA 来歴証拠とビルド パイプラインのセキュリティ体制スキャンの両方が必要であることを指定する場合があります。これらのモジュールによって提供された証拠は、すべての SLSA 要件を満たしていることを確認するために検証されます。
- SLSA 要件に準拠するにはどのような証拠が必要ですか?
- ビルド アーティファクトの SLSA 来歴証明書 (署名された証拠)。
- アーティファクトを生成する CI パイプラインのセキュリティ ポスチャ スキャン。
- SLSA 要件への準拠を証明する証拠の基準は何ですか?
- どちらの証拠にも、SLSA 要件をすべて満たす情報が含まれている必要があります。
この例では、SLSA 来歴証明書ではイメージのビルド プロセス全体を記述する必要があり、セキュリティ体制の証明書ではイメージのソースを保存した SCM がブランチ保護ルールを使用していることを検証する必要があります。
- どちらの証拠にも、SLSA 要件をすべて満たす情報が含まれている必要があります。
ポリシー モジュールの別の例は次のとおりです。 アーティファクトモジュールの検証これは、一部のアーティファクトが信頼できるソースによって署名される必要があることを指定します。証明書の利用 (検証可能な署名付き証拠) PKI (公開鍵インフラストラクチャー) 署名。アーティファクトに署名する必要がある特定の個人/エンティティの要件に準拠し、アーティファクトの出所のコンテキストを証明します。
この アーティファクトモジュールの検証 次の質問に答えます。
1. セキュリティ要件への準拠を証明するにはどのような証拠が必要ですか?
- PKI 署名 (証明書) を含むアーティファクトを説明する証拠。
2. コンプライアンスを確保するために、この証拠をどのように検証できますか?
- 証明書 PKI 署名は有効です。
- PKI 証明書の ID はユーザーの要件と一致します。
- 証拠の主題はユーザーの要件と一致します。
- 形式と起源はユーザーの要件に一致します。
理論から実践へ
Valint ツールで現在サポートされているこのモデルの実装を詳しく見てみましょう。
画像の署名と出所を検証する方法を指定するポリシーの簡単な例を見てみましょう。
具体的には、証拠が次の基準を満たしていることを確認する必要があります。
- 証拠のタイプは、画像を記述する CycloneDX SBOM 証明書です。
- アーティファクトには次の署名が付けられています mycompany.com.
- このイメージは、Circle-CI ワークフローから生成されます。 my_image_src レポ。
テンプレートポリシー
前の例では、ポリシーは静的であり、という名前の特定のイメージについてのみチェックされました。 私の会社/私の画像。ただし、多くの場合、テンプレート/変数機能をサポートするポリシーを使用することが望ましいです。これにより、CI/CD ビルド パイプライン内の複数の同様のプロセスまたはアーティファクトに適用できる要件を定義できます。
ポリシーをテンプレート化するには、ポリシーを製品に静的にロックする代わりに、変数を使用できます。上記の例では、次のように変更できます。 アーティファクト名 値を `$MY_IMAGE` 代わりに、評価者が同じコンプライアンス規制を必要とする多数のイメージに対して 1 つのポリシーを設定できるようにします。
今後の展望
At 筆記、私たちの最終的な目標は、証拠に基づいた検証可能なコンプライアンス モデルを通じてサプライ チェーンのリスクを軽減することです。このモデルを試す最初の場所の 1 つは、CI/CD ビルド パイプラインです。私たちは、この証拠検証アプローチがサプライチェーンの透明性と説明責任を確保する鍵であり、関係するすべての利害関係者に利益をもたらすと信じています。私たちのモデルは、ソフトウェア サプライ チェーン コミュニティにおける新しいアイデアの多くをカプセル化し、それらの多くの間の関係を定義します。私たちはソフトウェア サプライ チェーンの透明性の革新と向上に取り組んでいます。このモデルに興味を持ったら、ぜひチェックしてみてください。 Valint CLI ドキュメント ここでは、ツールの機能と用途について詳しく説明します。ぜひお試しください。
このコンテンツは、エンドツーエンドのソフトウェア サプライ チェーン セキュリティ ソリューションの大手プロバイダーである Scribe Security によって提供されており、ソフトウェア サプライ チェーン全体のコード成果物とコード開発および配信プロセスに最先端のセキュリティを提供しています。 詳しくはこちら。
関連記事
