この記事は、Viktor Kartashov と Daniel Nebenzahl と共同執筆されました。
監査人のリトマス試験: ビルドを証明できますか?
「出荷するすべてのコンテナ イメージが、まさにあなたが主張するとおりに構築されたことを、明確に証明できますか?」
多くの監査担当者は、数週間にわたる慌ただしいYAMLリファクタリングではなく、迅速かつ確実な回答を期待しています。SLSA（ソフトウェア成果物のサプライチェーンレベル）フレームワークは、その証明のための青写真、つまり構造化され改ざん防止機能を備えた出所を提供します。
しかし、ここに問題があります。従来、出所ジェネレーターをすべての CI ワークフローに組み込むと、すぐにモグラ叩きゲームのようになってしまいます。
- リポジトリが何十個もありますか? つまり、レビューしてマージする PR が無数に存在することになります。
- パイプラインの変更? 継続的な手動メンテナンス。
- 歴史的建造物ですか? 過去のリリースの証拠を再作成する簡単な方法はありません。
Scribe Security は、SLSA on Scale によってその摩擦を解消します。 より高度な プラットフォーム CLIは、既存の CI ログをインテリジェントに収集し、すべてのイメージ ビルドを自動的に検出し、包括的な全体的な出所 (SLSA レベル 1 の場合は未署名、SLSA レベル 2 の場合は署名済み) を出力します。これらはすべて、事前の設定を必要としない単一のコマンドから実行されます。
プラットフォーム CLI: Provenance におけるノータッチ パラダイム シフト
| 従来のアプローチ | Scribe プラットフォーム CLI |
| すべてのCIジョブにジェネレータステップを埋め込む | パイプライン編集ゼロ — ログを分析する After ビルドが完了 |
| 古いビルドを埋め戻すのが難しい | 遡及的に来歴を作成する 過去のワークフロー実行から |
| リポジトリあたりの線形労力 | 1つのコマンドでスケール 10 → 1,000以上のリポジトリ |
魔法が起こる仕組み：信頼の自動化
Scribe Platforms CLI は、既存のビルドに干渉することなく、自動化された SLSA の由来を提供するために、舞台裏で高度な処理を実行します。
- 丸太を伐採します: Scribe は CI/CD システム (現在は GitHub Actions、GitLab と Jenkins のサポートは近日中に開始予定) に接続してビルド ログを取得します。
- あらゆるビルドを検出します: パイプラインに特別な設定をしなくても、Scribe は Docker、Podman、または Buildah コマンドをインテリジェントに識別し、すべてのイメージ作成を正確に特定します。
- 主要なメタデータを抽出します: イメージタグ、暗号化ダイジェスト、ランナー ID、ビルド引数、タイムスタンプなどの重要な詳細は、これらのログから直接取得されます。
- リンクされた SBOM を生成します: 完全なトレーサビリティを実現するために、Scribeは以下の両方を自動的に作成します。 source ソフトウェア部品表（SBOM）と 画像 SBOM をビルドの起源に直接リンクします。
- SLSAの由来: Scribe は、この豊富なデータを使用して、各画像に対して完全に準拠した in-toto SLSA 来歴ステートメントを構築します。
- レベル2に署名します（オプション）： フラグを追加するだけで、Scribe は署名機能 (X509、Pub-Priv、Sigstore、または推奨の KMS) と統合し、出所を暗号的に署名して SLSA レベル 2 に昇格します。
- 検証とレポート: 重要なのは、Scribeは事前に定義された SLSA.l1 or SLSA.l2 証拠に基づく取り組み。これにより整合性が検証され、包括的なSARIFレポートが出力されます。このレポートはレベル2コンプライアンスの署名も付与されます。
生成されたすべての成果物はローカルに残すことも、改ざん防止機能付きで長期保存するために Scribe Hub に安全にアップロードすることもできます。
世代を超えて: ポリシー・アズ・コードによるコンプライアンスの証明
出所情報の生成は基本的な要素ですが、監査人を真に満足させるのは、そのコンプライアンスを証明することです。ScribeはSLSA出所情報を生成後すぐに、その証拠に基づいて自動的に取り組みを実行します。
これらの取り組みは自動監査人として機能し、次のような点をチェックします。
- 出所は適切に形成され、完全ですか?
- 必要なフィールドはすべて入力され、正確ですか?
- リンクされた SBOM は有効でアクセス可能ですか?
- 出所は予想される ID によって暗号的に署名されていますか?
結果は？コンプライアンス状況を詳細に説明した包括的なSARIFレポートです。レベル2では、このレポート自体も署名されているため、監査担当者にとって明確で、機械可読かつ検証可能な回答となります。
簡単な例: Scribe-Security で SLSA の来歴を実現する 🚀
Scribe-SecurityのPlatforms CLIは、ビルドのSLSA出所生成を効率化し、レベル1（署名なし）とレベル2（署名あり）の両方の保証を実現するための統一されたコマンドを提供します。重要な違いは、--valint.sign引数の存在です。
GitHub の scribe-security/valint リポジトリ内のすべてのタグベースのビルドの SLSA の由来を取得するには、次のコマンドを実行します。
Bash
その後、Scribe が動作を開始します。最新の GitHub ワークフローをスキャンし、イメージ ビルドをインテリジェントに検出し、必要なデータをすべて収集し、リンクされた SBOM を含む包括的な in-toto SLSA の来歴を書き込みます。
–valint.sign: SLSA レベル 1 または 2 用のスイッチ🔑
当学校区の –valint.sign フラグは単純なトグルとして機能します:
- 省略 –valint.sign SLSA レベル 1 (符号なし) の場合: Scribe は、基本的な追跡可能性のために、署名されていない基礎的な来歴を生成します。
- 含める –valint.sign SLSA レベル 2 (署名済み) の場合: Scribe は、出所ファイルと SARIF コンプライアンス レポートに暗号署名し、より高いレベルの検証可能な保証を提供します。
単一のフラグで制御されるこの統合コマンドにより、既存の CI/CD パイプラインを変更することなく、堅牢な SLSA コンプライアンスを大規模に実現することが簡単になります。
オープンソースの SLSA 来歴生成
SLSAの出所の生成はプライベートリポジトリに限定されません。多くのオープンソースプロジェクトでは、 公開CI/CDログビルドの出自を生成することが可能になります。これらの出自レコードには、当初はリポジトリや組織の秘密情報といったあまり広範囲ではない情報が含まれる可能性がありますが、将来的には、 出典 SBOM、これに対処できます。
例えば、SLSAレベル1の出所を簡単に生成することができます。 ゴーギテア/ギテア プロジェクトを使用して プラットフォーム発見 コマンド：
このコマンドを実行すると、SLSA 要求を示すログと、検出されたイメージ ビルドとその関連する出所をまとめた表が表示されます。
ご覧のとおり、この記事の執筆時点で見つかった`gitea/gitea`の最新バージョンは**v1.24.2**です。SLSAの出所と関連証拠が発行された1.24.2つのイメージは、`gitea/gitea:1.24.2`と`gitea/gitea:XNUMX-rootless`です。例として、SLSAの出所は以下で参照できます。 ,
当社のサービスでは、フレームワークと証拠のライフサイクルを管理し、製品と資産の明確な概要を提供します。
このコンテンツは、エンドツーエンドのソフトウェア サプライ チェーン セキュリティ ソリューションの大手プロバイダーである Scribe Security によって提供されており、ソフトウェア サプライ チェーン全体のコード成果物とコード開発および配信プロセスに最先端のセキュリティを提供しています。 詳しくはこちら。
関連記事
