Valint は、証拠を作成、管理、署名、検証するための主要な Scribe ツールです。で 以前の投稿では、CI/CD パイプラインのセキュリティを検証する際の主要なツールとして証拠の署名と検証を使用する理論について説明しました。簡単に思い出していただきますと、Scribe が提案したモデルには、ニーズに合った方法でシャッフルしたり積み重ねたりできるいくつかの構成要素が含まれています。構成要素には、収集された証拠が含まれます (SBOM, SLSA 出所、含めたいサードパーティのテスト結果）、収集された証拠の環境コンテキスト（作成者、場所、時期など）、およびその証拠に適用したいポリシー。
証拠に適用したいポリシーはこのモデルの重要な要素であるため、私たちが提供するポリシー エンジンの可能性をさらに詳しく調査するためにブログ投稿を捧げたいと考えました。
この記事では、私たちが考案した最も基本的なポリシー (情報の署名と検証) について説明します。より複雑なポリシーのテンプレートがどのようなものかを説明し、特定のユーザーが最後の「メイン」ブランチを作成したユーザーであることを確認する方法や、パイプラインが実行されていることを確認する方法など、ポリシーの標準的な例をいくつか示します。含める必要があるサードパーティツールのテストが含まれています。
ここから始めましょう: 証拠の署名と検証
ヴァリント は非常に多用途なツールですが、この記事を簡潔にするために、主に Valint の CLI インターフェイスを例として使用します。
最初のステップは、Valint をダウンロードすることです。
curl -sSfL https://get.scribesecurity.com/install.sh | sh -s -- -t valint
リポジトリまたはイメージから SBOM を作成するコマンドは「bom」です。たとえば、次のようにしたい場合は、 bom のイメージ busybox:latest コマンドは次のようになります。
$HOME/.scribe/bin/valint bom busybox:latest -o attest -f
注意してください attest のエイリアスです attest-cyclonedx-json.
デフォルトでは、Valint は使用しています シグストア インタラクティブ フローは、Scribe の Cocosign ライブラリに埋め込まれた署名メカニズムの背後にあるエンジンとして機能します。このライブラリは、署名と検証のためのデジタル署名を扱います。コマンドを適用したら、まず証拠に署名することを Y/[N] オプションで承認する必要があります。
署名に標準の PKI を使用することもできます (x509 証明書をサポートしています)。署名キーを保存するには、KMS、GitHub シークレット ストアなどの複数のオプションがあり、希望する署名メカニズムを使用するように Valint を簡単に設定できます。
署名を承認すると、ブラウザーで Sigstore にリダイレクトされ、GitHub アカウント、Google アカウント、または Microsoft アカウントのいずれかを使用してログインする必要があります。
サインインすると、ログインが成功したことがわかります。
この時点で、ブラウザを閉じてシェルに戻ると、証拠が正常に作成されたことが確認できます。
証明書は、デフォルトでローカル キャッシュに書き込まれます。ローカル キャッシュの場所は、 --output-directory 構成ファイル内のフラグ flag。を使用することもできます。 –出力ファイル フラグを使用して、証明書のカスタム パスを提供します。
署名付き証明書を作成したので、それが存在し、署名されていることを確認してみましょう。証拠を検証するコマンドは次のとおりです。 verify. 使い方はほぼ同じです bom コマンドを使用しますが、フラグを使用します -iの略です --input-format そのデフォルトは次のようになります bom, attest-cyclonedx-json。 verify コマンドは、まず Valint が使用するデフォルトの場所で必要な証拠を探します。証拠の保存と後での検索の両方を行う場合は、別の場所を指定できます。
したがって、確認したい場合は、 busybox:latest 前の例で生成して署名したイメージ証明書のコマンドは次のようになります。
$HOME/.scribe/bin/valint verify busybox:latest -i attest
すべて正しく行ったと仮定すると、結果は次のようになります。
元の証明書の署名者の電子メールを含む電子メールのリストが表示され、検証された証明書のタイプ (この場合は cyclonedx-json) も確認できます。
とても簡単そうですよね？ワンランク上に上げてみましょう。
ポリシーテンプレート
A 方針 のセットで構成されます モジュール。 ポリシーに含まれるすべてのモジュールが評価および検証されると、ポリシーが検証されます。モジュールの構成と設定に準拠する証拠が見つかった場合、モジュールは検証されます。
ポリシーは、Valint の設定ファイルの一部としてポリシー セクションで設定されます。これは、Valint 構成ファイルの一部 (潜在的なポリシーが含まれる部分) の例です。
プロジェクトに構成ファイルを含める必要はないことに注意してください。Valint はデフォルトのオプションを有効にするだけで問題なく動作します。さらに、このファイル内の内容はすべてオプションであるため、ポリシーのみを含むこのようなファイルを作成することは完全に有効です。
デフォルトでは .valint.yaml という名前の構成ファイルは、リポジトリのルートに含まれている必要があります。コマンドを実行すると、このファイルに含めたポリシーに基づいて、 valint verify 有効になっているポリシーとモジュールはすべて実行されます。基本的な「検証」ポリシーがデフォルトであるため、何も設定する必要はありません。 verify .valint.yaml ファイルがなくてもコマンドが適切に動作するようにします。
構成ファイルにどのようなポリシーを追加するかは、探すべき証拠があるかどうかに依存します。デフォルトでは、パイプラインで「bom」コマンドを実行すると、結果の証拠が Scribe 証拠ストアにアップロードされます。同様に、「verify」コマンドを実行すると、Scribe 証拠ストアで証拠が検索されます。このデフォルトを変更して、OCI またはキャッシュを証拠ストアとして使用することもできますが、この記事では、デフォルトが使用され、すべての証拠がアップロードされ、Scribe 証拠ストアから取得されると仮定します。
したがって、この例に基づいて、ポリシーのコンポーネントを見てみましょう。の 方針 は次のフィールドをサポートします。
- 名、ポリシー名 (必須)。
- enable、モジュールを有効にします (デフォルトは false)。
- モジュール、ポリシーモジュール構成のリスト。
この モジュール セクションでは次のフィールドがサポートされています。
- 名、ポリシーモジュール名 (必須)。
- enable、モジュールを有効にします (デフォルトは false)。
- type、モジュールのタイプ、現在サポートされている アーティファクトの検証 と git オーナー.
- match 、特定のコンテキストを持つ証拠に一致します。
- 、モジュール固有の構成。
ポリシーには複数のモジュールを含めることができ、「verify」コマンドを実行すると、有効なモジュールがすべて実行されます。
フィールドのドライなリストはあまり有益ではないことはわかっているので、次のセクションであるサンプル ポリシーに進みましょう。
サンプルポリシー
画像検証ポリシー
Valint の署名検証フローを表す最も単純なポリシーから始めましょう。
attest: cocosign: ポリシー: - 名前: verify_policy 有効: true モジュール: - 名前: signed_sbom タイプ: verify-artifact 有効: true 入力: signed: true 形式: attest-cyclonedx-json ID: 電子メール: - barak@scribesecurity.com
繰り返しますが、このポリシーはリポジトリのルートにある .valint.yaml ファイルに含める必要があります。これが機能するには、事前に次のコマンドを実行して署名付き SBOM を作成しておく必要があります。 valint bom 指示。確認する準備ができたら、次のコマンドを実行する必要があります。 valint verify
この例を見ると、ポリシーが有効になっていて、次のタイプの有効なモジュールが 1 つあることがわかります。 ‘verify-artifact‘. モジュールは、入力が署名されているかどうか、形式が正しいかどうかを確認します。 ‘attest-cyclonedx-json’, そして、電子メールに示されている ID によって署名されていること ‘barak@scribesecurity.com’.
このポリシーを実行するには、 verifyパイプライン内のコマンドは次のようになります。
valint verify busybox:latest
から verify コマンドは、提供されたポリシーに基づいて、 busybox:latest Scribe 証拠ストアの証拠の一部。次の形式の署名付き SBOM を探します。 `cyclonedx-json` そして、SBOM に署名した ID がポリシーで規定された電子メールを使用していることを確認します。 `barak@scribesecurity.com`.
その証拠ストアにはそのような画像が複数ある可能性があると言うかもしれませんが、それは正しいでしょう。ここでコンテキストが関係します。デフォルトでは、 verify コマンドは、利用可能な最も近い一致を検索します。ただし、コマンドがパイプライン実行 ID のコンテキストまたはアーティファクトが作成されたビルド システムと一致する必要があることを指定できます。これを行うには、フィールドを使用する必要があります。 match: 適切なコンテキスト タイプを使用します。例えば：
一致: context_type: github git_url: github.com/my_org/myimage.git ブランチ: main
この場合、証拠は Github によって、つまり、 git_url とによって、 main そのリポジトリのブランチ。必要に応じて適切なコンテキストを使用して、ポリシーで検証したい内容を正確に検証することが重要です。
バイナリ検証ポリシー
別の例を見てみましょう。このポリシーは、チェックしている exe ファイルが特定のリポジトリからのものであり、数人の既知の個人のうちの 1 人によって署名されたことを検証することを目的としています。
attest: cocosign: ポリシー: - 名前: verify_policy 有効: true モジュール: - 名前: binary_module タイプ: verify-artifact 有効: true 入力: signed: true 形式: attest-cyclonedx-json ID: 電子メール: - barak@scribesecurity.com - mikey@scribesecurity.com - adam@scribesecurity.com match: target_type: file context_type: azure git_url: https://dev.azure.com/mycompany/somerepo # 環境の Git URL。入力名: my_binary.exe
この例を見ると、ポリシーが有効になっていて、次のタイプの有効なモジュールが 1 つあることがわかります。 ‘verify-artifact‘ モジュールは、入力が署名されていること、およびその形式であることをチェックします。 ‘attest-cyclonedx-json’, そして、モジュールにリストされている 1 つの許可された電子メールのうちの 3 つによって署名されていること。さらに、次のことをチェックします。 verify コマンドは入力を受け取り、その入力に名前が付けられていることを確認します。 ‘my_binary.exe’、入力が Azure で作成されたファイルであり、特定の git URL からのものであることがわかります。 https://dev.azure.com/mycompany/somerepo.
ご覧のとおり、この例では、ポリシーを検証するためにさらに多くの要件があります。
このポリシーを実行するには、 verify パイプライン内のコマンドは次のようになります。
valint verify file:my_binary.exe
Scribe 証拠ストアにこのバイナリの署名済みバージョンがあることを確認するには、まず次のような証拠を作成する必要があります。
valint bom file:my_binary.exe -o attest
第三者による証拠検証ポリシー
最後の例では、使用するサードパーティ ツールがパイプラインで適切に実行され、JSON ファイルの形式で期待する結果が作成されたことを確認する方法を見てみましょう。
アテスト: ココサイン: ポリシー: - 名前: verify_policy イネーブル: true モジュール: - 名前: 3rd-party-rule タイプ: verify-artifact イネーブル: true 入力: 署名: false 形式: アテスト汎用 ID: 電子メール: - bob@scribesecurity。 com match: target_type: generic context_type: azure git_url: https://dev.azure.com/mycompany/somerepo git_branch: main input_name: 3rd-party-scan.json
この例では、パイプラインのある時点でサードパーティ ツールを実行し、その結果として `3rd-party-scan.json` ファイルが作成されたと想定します。ファイルが Azure DevOps から生成されている必要があるというポリシーを満たすには、` によってトリガーされます。https://dev.azure.com/mycompany/somerepo` リポジトリと ` による署名bob@scribesecurity.com`.
探している証拠を生成するには、サードパーティ ツールを実行した直後に、結果のファイルをキャプチャし、Valint を使用して証拠に変換する必要があります。
valint bom 3rd-party-scan.json -o attest-generic --predicate-type https://scanner.com/scan_format
証拠は何を証明しますか?
したがって、Valine を使用してパイプライン内のさまざまなことを検証できることがわかりました。この能力は実際に何に使えるのでしょうか？
私たちのパイプラインが侵害され、何人かの悪者がパイプライン内およびパイプラインに対して私たちが望まないことをし始めたと想像してみましょう。パイプラインのさまざまなステップが期待どおりに実行され、期待どおりの結果が生成され、承認された担当者によって署名されたことを検証することで、悪者が私たちをだますことがはるかに困難になります。
潜在的な攻撃の 1 つは、パイプラインの最後にあるバイナリ ファイルを置き換えて、クライアントが取得するバージョンがオリジナルではなく悪意のあるバージョンになるようにすることです。あなたのバージョンに署名し、クライアントにそのマスター コピーと照合して検証するよう依頼することで、すべてのクライアントがあなたが作成した同じファイルを使用しており、巧妙な偽造品ではないことを確認できます。
証拠を作成して検証するこのモデルは、まだ始まったばかりです。私たちは、Valint をさらに堅牢かつ多用途にするために、追加機能を追加することに常に取り組んでいます。それまでの間、ぜひチェックしてみてください。 ドキュメント Scribe が提供するものと、Valint でさらに何ができるかについて詳しく知ることができます。 Valint は無料でダウンロードして使用できるため、このツールを今すぐ試してみることを妨げるものは何もありません。
このコンテンツは、エンドツーエンドのソフトウェア サプライ チェーン セキュリティ ソリューションの大手プロバイダーである Scribe Security によって提供されており、ソフトウェア サプライ チェーン全体のコード成果物とコード開発および配信プロセスに最先端のセキュリティを提供しています。 詳しくはこちら。
関連記事
