その SLSAフレームワーク 進化を続け、新しい SLSA v1.2 今回のリリースでは重要なアップデートが含まれています 現代のソフトウェアを開発するすべての人へ pipeline以前のバージョンとは異なり、SLSA v1.2 は、より実践的な採用、より強力な出所保証、より明確なルールに重点を置いています。 SLSA認証ソフトウェアサプライチェーンへの攻撃が増加し続けているため、開発者は各成果物がどのように構築され、どのシステムがそれに触れたかを検証するための、シンプルで信頼性の高い方法を必要としている。
このガイドでは、 ソフトウェア成果物のサプライチェーンレベル v1.2、 なぜ SLSAフレームワーク は、 software supply chain security そして、これらの要件をCI/CDワークフローに自然に組み込む方法についても説明します。
1. SLSAとは何か、そして開発者がSLSAフレームワークに依存する理由
SLSAはソフトウェア成果物のサプライチェーンレベルの略です。 SLSAフレームワーク ビルドにおけるコードの流れ、プロジェクトへの依存関係の導入方法、成果物の移動方法を検証することで、ソフトウェアサプライチェーンを保護します。 pipelines. 出所、隔離、完全性に関する明確なルールを定めているため、チームは出荷するものを正確に理解できます。
開発者がソフトウェア成果物のサプライチェーンレベルに頼るのは、それが実用的な疑問に答えてくれるからです。ビルドシステムがどのようにバイナリを作成したか、そしてそのプロセスに何かが改ざんされていないかを証明できますか？これは実際のところ重要です。 pipeline依存関係が頻繁に変化し、ビルドが複数のシステムにまたがって実行されるような状況において、SLSAは複雑なワークフロー内で発生する依存関係の汚染、ビルド手順の侵害、および不正な変更のリスクを低減します。
2. SLSA v1.2の新機能
SLSA v1.2では、開発チームにとって導入がより容易かつ現実的なものとなるよう、いくつかの変更が加えられています。これらのアップデートにより、仕様は現代の組織におけるソフトウェア開発手法にも適合するようになりました。
より厳格なビルド要件
SLSA v1.2 ではビルド分離要件が明確化され、開発者はどの部分が pipeline 管理する必要がある。これにより、以前のバージョンで発生していた混乱が軽減され、チームはランナー、ビルダー、オーケストレーターに対して一貫した保護を適用できるようになる。
SLSA v1.2 証明書フォーマットの改訂
新バージョンでは、SLSAアテステーションの構造を更新し、証拠の生成と利用方法を簡素化しました。アテステーションの解析が容易になったことで、ツールによる検証の自動化が促進され、手作業の手順が削減されます。
更新された出所要件
出所情報スキーマには、依存関係、ビルドパラメータ、信頼できるソースに関するより多くの情報が記録されるようになりました。その結果、各成果物の起源を容易に追跡できるようになります。
依存関係のセキュリティ強化
サプライチェーン攻撃は多くの場合、侵害されたパッケージから始まるため、ソフトウェア成果物のサプライチェーンレベルv1.2では、依存関係の選択、バージョン管理、検証に関する期待値を強化しています。
隔離の定義をより明確にする
この仕様では、密閉型ビルドと隔離環境の定義が改善されています。これにより、開発者はビルドロジックをより正確に検証し、安全でないシステムを意図せず信頼してしまうことを回避できます。
3. SLSA v1.2と以前のバージョンとの比較
以下は、SLSA v1.2 がプロベナンス、ビルド分離、および SLSA アテステーションに対する期待値をどのように変更するかを示す視覚的な比較です。
| エリア | SLSA v1.1 | SLSA v1.2 |
|---|---|---|
| 来歴 | 限定的な依存関係メタデータを含む基本的な来歴情報 | より詳細な依存関係とビルドパラメータの追跡による拡張された来歴情報 |
| 証明 | より厳格な証明書フォーマット | 自動化と検証を容易にするための改良された**slsa認証**モデル |
| 隔離の構築 | 一般的な隔離に関するガイダンス | 孤立した建築業者と密閉型建築物に関するより明確な定義 |
| 依存関係制御 | 期待は限定的 | 依存関係の選択、追跡、検証に関するより厳格なルール |
| 養子縁組の難しさ | 要件に時折曖昧さがある | より実用的で、開発チームにとって適用しやすい |
4. SLSA認証の理解
A SLSA認証 これは、ソフトウェア成果物がどのように作成されたかを証明する署名付きステートメントです。ビルドプロセス、ソースコード、依存関係、およびバイナリを生成した環境について記述します。証明書は固定のスキーマに従うため、ツールで自動的に検証できます。
開発者にとって、これはビルドが期待どおりに生成されたことを検証できることを意味します。 pipeline また、信頼できないシステムによって改ざんされていないことも保証されます。さらに、疑わしい変更が来歴情報に直接反映されるため、証明書によって改ざんを早期に検出できます。
5. XygeniがSLSA v1.2の要件を満たすのにどのように役立つか
Xygeniは コンプリート build security 層 それは、 SLSAフレームワーク手動レビューに頼る代わりに、コード、依存関係、CI全体にわたる継続的なチェックが行われます。 pipelines.
出所証明と認証の検証
Xygeniはプロベナンスファイルを検証します、検証 SLSA認証 コンテンツと、ビルドメタデータが想定されるソースと一致するかどうかのチェック。
ビルドスクリプトの監視
Xygeni はビルド スクリプトを監視し、内部の不正な変更、安全でないコマンド、または疑わしい動作を検出します。 pipelines.
依存関係の検証
Xygeniは、依存関係の整合性、バージョン履歴、信頼レベルをチェックすることで、パッケージが侵害されるリスクを軽減します。
アーティファクトの完全性
Xygeniは、アーティファクトの改ざんをスキャンし、それらが期待されるビルド出力と一致していることを確認します。
Pipeline Security
XygeniはCIとCDを検証します pipeline一貫性があり安全な構築パターンに従います。
SBOM サプライチェーンマッピング
Xygeniは生成および分析します SBOMs、これはチームが満足するのに役立ちます SLSA provenance および下流工程における監査要件。
その結果、チームは開発速度を落とすことなく、また複数のツールを寄せ集めることなく、SLSA v1.2の要件を満たすことができる。
6. SLSA v1.2アップデートに関する最終的な考察
ソフトウェア成果物のサプライチェーンレベルv1.2は、ソフトウェアサプライチェーンの明確性と保証を強化します。さらに、開発者は、出所を理解し、ビルドの整合性を検証し、サプライチェーン全体で一貫した制御を実装するためのより簡単な方法を利用できるようになりました。 pipeline仕様も採用しやすくなり、 SLSA認証 ソフトウェアがどのように作成されたかを証明する上で中心的な役割を果たします。そのため、チームは出荷する成果物に対する信頼性をより高めることができます。
Xygeni を使用すると、 SLSAフレームワーク 既存の SDLCさらに、出所を自動的に検証し、依存関係を継続的にチェックし、ビルドを不正アクセスから保護することができます。その結果、開発速度を落とすことなくサプライチェーンを強化できます。
👉 無料トライアルを開始する or デモを予約する SLSA v1.2でビルドを保護しましょう
