SLSA概要紹介 Supply-chain Levels for Software Artifacts

サイバートラスト株式会社 OSS事業本部 池田宗広氏 (The Linux Foundation Japan Evangelist)
2024年10月3日開催 OSSセキュリティMeetup 講演資料

Transcript

1. SLSA 概要紹介 
 Supply-chain Levels for Software Artifacts 
 2024年10月3日
 サイバートラスト株式会社
 OSS事業本部
 池田 宗広
 （The Linux Foundation Japan Evangelist)

2. SLSA とは 
 ▪ SLSA (サルサ) ： Supply-chain Levels for Software Artifacts • https://slsa.dev/ ▪ SLSAはツールではなく、サプライチェーンセキュリティのためのフレーム ワーク・チェックリストという位置付け • 2024/10 時点では v1.0 が最新 • ソースコード、ビルドプロセス、ビルドプラットフォームの運用辺りのセキュリティを 強化する • 強化対象のカテゴリはトラックと呼ばれている ▪ SLSA はソースからバイナリまでコードが変遷していく工程の自動的な追 跡を、ソフトウェアサプライチェーンの複雑性に関わらず改ざんから保護 しつつ支援する ▪ SLSA is designed to support automation that tracks code handling from source to binary, protecting against tampering regardless of the complexity of the software supply chain. ▪ 上記は「About SLSA」ページ からの引用 ▪ セキュリティの実現度合いをレベルで表現 • SLSA 1.0ではBuild Level 0~3が定義されている
3. SLSA における登場人物 
 ▪ Software producers • ソフトウェアの開発者、ベンダーなどソフトウェアを開発してリリースする人 ▪ Software consumers • いわゆるソフトウェアのエンドユーザー • ソフトウェアの開発者がOSSのコードを利用してソフトウェアを作る場合は、ソフト ウェア開発者がコンシューマーにもプロデューサーにもなる ▪ Infrastructure providers • リリース対象のソフトウェアの開発を行うのではなく、CI/CDプラットフォームなどの プラットフォームを提供する人 • Githubなどのクラウドサービスを使う場合は Github がプロバイダー • Jenkins などで社内 CI/CD 環境を使っている場合は社内のCI/CD管理者がプロバイ ダー
4. SLSA の「トラック」と「レベル」 
 Build Platform Operations Source Build Level 0 Level 1 Level 2 Level 3 Level 4 Level 0 Level 1 Level 2 Level 3 Level 4 Level 0 Level 1 Level 2 Level 3 Level 4 SLSA1.0の対象範囲 https://slsa.dev/spec/v1.0/future-directions SLSAで定義 されて いるトラック トラック ＝ 広さ レベル ＝ 深さ
5. SLSA v1.0 
 ▪ SLSA 1.0 はビルドトラックの強化のための定義となっている • CI/CDプロセスの強化 • レベルは3まで定義されている ▪ 1.0 で定義されているのは CI/CD サプライチェーンの一部のみ • 将来的にはトラック（広さ）・レベル（深さ）を拡張する（予定） ▪ ビルドトラックのレベル4 ▪ 他のトラック ▪ ソースコードのプロテクション ▪ etc.
6. 各トラックにおける脅威 
 https://slsa.dev/spec/v1.0/threats-overview SLSA1.0の対象はこの辺
7. SLSA は何のために使うのか 
 ▪ サプライチェーンセキュリティ強化のため • ユーザーに対してセキュアと言えるものをリリースする ▪ SLSAを共通の言語とすることで認識を合わせやすくする ▪ セキュリティの実現レベルを測るためのチェックリストとして使う • 「SLSAレベル2を実現しています」といえば、どの程度のセキュリティを実現してる か理解してもらえる
8. SLSA で対応しないもの 
 ▪ コードの品質 • セキュアコーディングなどのプラクティスは別途適用するべきもの ▪ 製品提供者の信頼性 • サプライチェーンの強化が目的なので、ソフトウェア提供者（software producer）の 信頼性は別途保証が必要 • 「信頼」はセキュリティではなくてトラストの範囲 ▪ 依存関係に対する推移的な信頼(Transitive trust for dependencies) • 利用しているパッケージが依存しているパッケージなどの信頼性
9. SLSA における成果物の検証 
 ▪ 検証を行うためのファイルフォーマットがいくつか定義されている • SLSA Provenance ▪ https://slsa.dev/provenance/v1 • VSA (Verification Summary Attestation) ▪ https://slsa.dev/verification_summary/v1 ▪ どのフォーマットを選ぶかは要件次第だが、従うべきモデルは定義されて いる • General model ▪ https://slsa.dev/attestation-model
10. SLSA Provenance（工程証跡） 
 ▪ ビルドの来歴を記載するファイル • フォーマットは SLSA Provenance にて定義 • CI/CDプロセスで作成する ▪ 第三者がこのファイルを使ってソフトウェアを検証できる ▪ 以下のような場合に選択 • ビルドプロセスの詳細を公開しても問題ない ▪ 公開に問題がある場合はVSAを選択 • どういう場合にVSAを選ぶかは次スライドにて • 自分たちのコードがどのようにビルドされて信頼できるものだと示したい • OSSのソフトウェアである • 他のユーザーによってコードが利用される
11. VSA(Verification Summary Attestation) 
 ▪ VSAは、成果物がどのSLSA レベルで検証されたか、その検証に関する詳 細が記載される • SLSAレベルでの検証情報と依存関係の検証レベルについて提供される • Software consumer は、アーティファクトやその依存関係に関する確認情報へのア クセスなしで、アーティファクトの妥当性について判断できる • Software producer は、ビルドパイプラインの詳細を秘密に保ちながら、検証が行 われたことを伝えることができる。これは法的理由（ソフトウェアサプライヤーの秘 密保持）やセキュリティ理由（非公開のパッチの組み込み）がある場合に必要とさ れる ▪ 以下のような場合にVSAの選択を検討 • クローズドソースだが、ユーザーは社内以外にもいる • 監査や法的要件に準拠したい • ビルドプロセス全てを公開できない
12. General Model 
 https://slsa.dev/attestation-model
13. General Model : 推奨される形式 
 コンポーネント 推奨 Envelope DSSE (ECDSA over NIST P-256 (またはより強力な暗号 ), SHA-256) Statement in-toto atestations Predicate Provenance, SPDX など。適当なものがなければ定義する Bundle JSON Lines Storage/Lookup 未定
14. SLSA のセキュリティレベル 
 ▪ 0から4までの5段階 ▪ レベルが上がるほどセキュアにできているという意味 ▪ SLSA 1.0では3まで • 4も将来的にはできる模様
15. Build Level 0 ▪ 何も対応していない状態 Build Level 1 ▪ パッケージがどのようにビルドされたかを示すことができる • このレベルではビルドの証跡(provenance)を示すことはできるが、改ざんなどへの対策 はない ▪ Provenance をユーザーが取得できる Build Level 2 ▪ Provenance は署名される ▪ Provenance はホストされたビルドプラットフォームで生成される Build Level 3 ▪ より強力な改ざん保護を提供するビルド プラットフォーム上でビルドを実行す る Build トラックのセキュリティレベル 

16. SLSA Build レベル1 の要件 
 ▪ Software producer は一貫したビルドプロセスに従うこと。これにより、他 の人々は「正しいビルド」とはなにかを認識し期待することができる ▪ ビルドプラットフォームは、アーティファクトのビルド方法に関する証跡を 自動的に生成すること。これには、パッケージをビルドしたエンティティ、 使用したビルドプロセス、およびビルドの最上位の入力などが含まれる ▪ Software producer は、証跡をコンシューマーに配布すること。可能な限 り、パッケージエコシステムで決められた規約を使用する
17. SLSA Build レベル1 のメリット 
 ▪ Software producer と consumer 双方が正確なソースバージョンとビルドプ ロセスを知ることできるため、ソフトウェアのデバッグ、パッチ、再構築、分 析が容易になる ▪ 検証により、アップストリームリポジトリに存在しないコミットからビルドす るなど、リリース プロセス中のミスを防ぐことができる ▪ 組織内のさまざまなチームで使用される様々なソフトウェアとプラット フォームが棚卸できる
18. SLSA Build レベル2 の要件 
 レベル1の要件に加えて・・・ ▪ ビルドプラットフォームは専用のインフラを用いること ▪ Provenanceを署名して公開すること ▪ ユーザーは署名を検証することで provenance の真正性を検証できること
19. SLSA Build レベル2 のメリット 
 レベル1のメリットに加えて・・・ ▪ デジタル署名によりビルド後の改ざんを防止できる ▪ セキュリティ管理を回避しようとする敵対者を阻止できる • 例：解雇されそうな従業員など ▪ 監査および強化が可能な特定のビルドプラットフォームにビルドを制限することで、攻 撃対象領域を削減できる ▪ さらなる強化作業 (ビルド L3) を並行して実行しながら、サポートされているビルド プ ラットフォームへのチームの大規模な移行を早期に行うことができる 注 ▪ 出所を偽造したり、検証を回避したりするには明示的な「攻撃」が必要だが、これは簡 単に実行できる場合もある。 レベル２では、洗練されていない敵や、法的リスクや経済 的リスクに直面している敵を阻止することができる ▪ これは、ビルドと provenance の生成・署名がホストされたプラットフォームで実行され ることで実現する
20. SLSA Build レベル3 の要件 
 レベル2の要件に加えて・・・ ▪ 同じビルド プラットフォームで実行される同じプロジェクト内のビルドで あっても、実行が互いに影響を与えないこと ▪ Provenance の署名に使用される秘密鍵などが、ユーザー定義のビルドス テップからアクセスできないこと 注 ▪ SLSA に対応したプラットフォームを使わずに要件を満たすことは技術的 には可能だが、素直に対応している既存のプラットフォームを使うほうが 楽
21. SLSA Build レベル3 のメリット 
 レベル2のメリットに加えて・・・ ▪ 内部関係者の脅威、認証情報の漏洩、または他のテナントによるビルド 中の改ざんを防ぐことができる ▪ ビルドプロセスへの攻撃が困難になるため、攻撃・侵害されたパッケージ がアップロードされるリスクを大幅に軽減できる ▪ パッケージが公式のソースとビルド プロセスからビルドされたことを、強 い信頼性をもとに提供できる
22. SLSA のユーザー向けツール 
 ▪ ユーザー向けにリリース物を検証するツール • https://github.com/slsa-framework/slsa-verifier
23. SLSA をサポートするサービス・ツール 
 ▪ GitHub • Achieving SLSA 3 Compliance with GitHub Actions and Sigstore for Go modules • レベル3対応 • ソフトウェアサプライチェーンセキュリティのための GitHub Actions ワークフロー | 豆蔵デベロッパーサイト ▪ Gitlab • Software Supply Chain Security Direction • レベル3は将来対応予定 ▪ Red Hat Trusted Software Supply Chain • Red Hat Trusted Software Supply Chain • レベル3対応 ▪ FRSCA • https://buildsec.github.io/frsca/ • SLSA 1.0 のレベル2まで対応
24. SLSA をサポートするサービス・ツール 
 ▪ Jenkins • https://github.com/slsa-framework/slsa-jenkins-generator • Level 1に準拠するためのプラグイン • in-totoのプラグイン ▪ https://plugins.jenkins.io/in-toto/ ▪ Azure DevOps • https://github.com/slsa-framework/azure-devops-demo • provenanceを作成するツール • Level 1に準拠
25. How to SLSA : For Developers 
 ▪ 全レベル共通 • Provenanceを作成し、公開する ▪ Level 1 • CI/CD環境がなければ作る ▪ 可能ならLevel 2, 3に対応しているプラットフォームを選択するのが良い • ビルドプロセスについて文書化する ▪ Level 2 • ホストされたビルドシステムを使う • 署名された provenance を作成し、公開する • ユーザーが provenance を検証できるようにする ▪ Level 3 • 他に影響を及ぼさないビルドシステムを使う • 真正性が証明できる署名付きの provenance を生成する ▪ 認証機関によって認証されてるとかそんな感じか https://slsa.dev/get-started ドキュメントには「 developers」と書かれているが、 SLSAのアクター定義 でいうところの software producers が対象と思われる
26. How to SLSA : For Organizations 
 ▪ 全レベル共通 • provenanceを作成する • provenanceを公開し、ユーザーが検証できること ▪ Software consumers として • 公開されている provenance を検証する ▪ slsa-verifier などの検証ツールを利用する ▪ Software producers として • CI/CDプラットフォームがなければ構築する • 3rdパーティのプラットフォームを使っている場合、 ▪ そのプラットフォームでサポートされているレベルが望んだレベルならそのレベルに準拠する ように使う ▪ もし望んだツールに対応していないなら、 • 別のツールを使う • そのレベルをサポートするようにリクエストする • レベルサポートのために開発・貢献する！ • 独自のプラットフォームなら ▪ Buildプロセスでprovenance を生成するなど、SLSAの要件に合うように強化・メンテナンスする
27. How to SLSA：Infrastructure Providers 
 ▪ Build プラットフォーム提供者 • インフラがSLSAの要件を満たしているかチェックする ▪ https://slsa.dev/spec/v1.0/verifying-systems • Provenanceを作成する機能を提供する ▪ パッケージレジストリ提供者 • 配布するソフトウェアの provenance を検証して正しいことを確認する • Provenanceを配布する ▪ https://slsa.dev/spec/v1.0/distributing-provenance ▪ コンパイラやその他 CLI ビルドツールの提供者 • コンパイラ等のツールは SLSA provenance を生成できるが、ビルドレベル 1 を超え ることはできない • 代わりに、ユーザーにビルド プラットフォームで SLSA provenance を生成するよう に勧めるのが良い • …と書かれているので、基本的にはSLSAに対応しているプラットフォームを選択す ることが推奨されている
28. SLSA のコミュニティ状況 
 ▪ Mailing List • https://groups.google.com/g/slsa-discussion • あまり活発ではない様子 ▪ Slack • #slsa(536), #slsa-specification, #slsa-tbd, #slsa-tooling • どれも 1~2トピック/週 程度、それもミーティング連絡が多い ▪ Github • https://github.com/slsa-framework • slsa-github-generator（GitHub Actions で Level 3 Provenance を出力するツール）、 slsa-verifier（Provenance の検証ツール） あたりが活発 ▪ Steering Committee • Bruno Domingues - Intel • David A. Wheeler - Linux Foundation • Joshua Lock - Verizon • Kim Lewandowski - Chainguard • Mark Lodato - Google • Mike Lieberman - Kusari/CNCF • Trishank Karthik Kuppusamy - Datadog
29. ▪ SLSA はソフトウェアサプライチェーンセキュリティを実現・強化するための フレームワーク • サプライチェーンセキュリティのためのチェックリスト/ガイドライン/規格/要件 と捉 えると分かりやすい（かも） ▪ カバー範囲の広さを「Track」、セキュリティ強度を「Level」と表現 ▪ 2024/10 時点の最新版 SLSA 1.0 では、Build Track の Level 0～3 が定義さ れている • Level 1： 定義されたビルド、Provenance（工程証跡）の生成・配布 • Level 2： ＋ 専用ビルドプラットフォーム、Provenance への署名 • Level 3： ＋ 開発者から切り離されたビルドプラットフォーム ▪ オンプレでの実現・準拠に課題あり まとめ

30. SLSAワークショップ　 11/1(金) 夕方～ 内容 ①説明：SLSAの概要 ②アクティビティ：SLSA provenanceの生成と検証 ③説明：Publish/Deployment policyの概要 ④アクティビティ：Publish policyの生成と検証 必要なスキル 特になし すぐに実行できるコマンドが用意されているため、ターミナルでコマンド実行するだけで参加できま す！ ※ 16:00 から国際文化会館（六本木）にて、「 Japan SBOM Summit」に続けて開催予定 SLSAワークショップ開催！ 

31. 参考資料

32. IN-TOTO との関係 
 ▪ in-totoは、Cloud Native Computing Foundationでホストされるソフトウェア サプライチェーンを保護するフレームワークであり、in-toto仕様はソフト ウェアサプライチェーンのさまざまなステップを保護するための汎用的な ワークフローを提供する ▪ SLSA仕様では in-totoアテステーションを推奨しており、ソフトウェアサプラ イチェーンの証明書およびその他の属性を表現するための手段としてい る ▪ in-totoはソフトウェアサプライチェーンに関連する情報を表現するための 中立的なレイヤーであり、SLSAは特定のレベルの保証を達成するために in-totoメタデータに捉えるべき情報を厳密に指定する意見を持ったレイ ヤーと見なすことができる ▪ Go、Java、およびRustで書かれたin-totoの公式実装には、SLSA provenance メタデータを生成するサポートが含まれている。これらのAPI は、Sigstoreのcosign、SLSA GitHub Generator、およびin-toto Jenkinsプラ グインなど、SLSA provenance を生成する他のツールでも使用されている
33. Terminology （語句定義） 
 ▪ SLSA の目的の一つに「ソフトウェア サプライ チェーンのセキュリティにつ いて話すための一般的な用語」とあるので、Terminology ページ の語句 定義一覧を次頁から参考に記します
34. 語句定義： サプライチェーンモデル 
 用語 説明 例 Artifact アーティファクト 不変（immutable）なデータの塊。主にソフトウェアを指すが、 SLSA では あらゆるアーティファクト（成果物）に対してこの語を用いる ファイル、git コミット、ファイルのディレクトリ (何らかの方法で シリアライズされている )、コンテナー イメージ、ファームウェア イメージ Attestation アテステーション ソフトウェア アーティファクトまたはソフトウェア アーティファクト群に関する 認証されたステートメント (メタデータ) 署名されたSLSA Provenanceファイル Source ソース 人によって直接作成またはレビューされ、その後変更されていないアー ティファクト。これがサプライチェーンの起点であり、 SLSA はこれより以前 に遡って来歴を追跡することはない GitHub (プラットフォーム) に格納されている Git コミット (ソー ス)。 Build ビルド 一連の入力アーティファクトを一連の出力アーティファクトに変換するプロ セス。入力は、ソース、依存関係、または一時的なビルド出力など Travis CI (プラットフォーム) によって実行される、 .travis.yml (プロセス) Package パッケージ 他人が使用するために「公開」されたアーティファクト。 SLSA のモデルで はこれは常にビルド プロセスの出力だが、ビルド プロセスは何も行わな い場合もあることに注意 DockerHub（プラットフォーム）上で配布される Dockerイメージ （パッケージ） ソース コードを含む ZIP ファイルはソースではなくパッケージ である（git コミットなどの他のソースからビルドされるため） Dependency 依存性 ビルド プロセスへの入力ではあるが、ソースではないアーティファクト。 SLSA モデルではこれは常にパッケージ Alpine Linux (プラットフォーム) 上で配布される Alpine パッ ケージ
35. 語句定義： Roles（役割／登場人物） 
 役割 説明 例 Producer プロデューサー ソフトウェアを作成し、他者に提供する主体。 Producer はしばし ば consumer でもある OSS プロジェクトのメンテナ、ソフトウェアベンダー Verifier 検証者 アーティファクトの来歴を検査して、アーティファクトの真正性を 判断する主体 企業のソフトウェア取り込みシステム、プログラミング 言語エコシステムのパッケージ レジストリ Consumer 使用者 Producer が提供するソフトウェアを使用する主体。 Consumer は、使用するソフトウェアの来歴を検証することも、検証の責任 を別の Verifier に委任することもできる OSSディストリビューションを使用する開発者、 POSシ ステムを利用したビジネス Infrastructure provider インフラストラクチャ プロバイダー 他の役割主体にソフトウェアまたはサービスを提供する主体 パッケージ レジストリのメンテナ、ビルド プラットフォー ムのメンテナ
36. 語句定義： ビルドモデル（1/2) 
 語句 説明 Platform プラットホーム テナントがビルドを実行できるシステム。技術的には、ビルドを忠実に実行するための信頼できる一連のソフトウェア およびサービス。これには、ソフトウェア、ハードウェア、人、組織が含まれる Admin 管理者 プラットフォームへの管理アクセス権を持つ特権ユーザー。ビルドやコントロール プレーンを変更することが可能 Tenant テナント プラットフォーム上にアーティファクトを構築する信頼できないユーザー。テナントはビルドステップと外部パラメータ を定義する Control plane コントロールプレーン それぞれの独立したビルド実行を調整し、来歴を生成するビルド プラットフォーム コンポーネント。コントロール プ レーンは管理者によって管理され、テナントの制御外にある Build ビルド 入力ソースと依存関係を出力アーティファクトに変換するプロセス。テナントによって定義され、プラットフォーム上の 単一のビルド環境内で実行される Steps ステップ テナントによって定義された、ビルドを構成する一連のアクション
37. 語句定義： ビルドモデル (2/2) 
 語句 説明 Build environment ビルド環境 ビルドが実行される独立した実行コンテキスト。コントロール プレーンによって初期化される。分散ビルドの場合、こ れはステップを実行するすべてのマシン /コンテナ/VM の集合を意味する Build caches ビルドキャッシュ プラットフォームによって管理される中間アーティファクト ストレージ。中間アーティファクトはプラットフォームにより 明示的に何等かの入力にマッピングされる。各々のビルドは、プラットフォーム上で実行されているサブビルドとビ ルド キャッシュを共有する場合がある External parameters 外部パラメータ ビルドへのトップレベルの独立した入力のセット。テナントによって指定され、ビルドを初期化するためにコントロー ル プレーンによって使用される Dependencies 依存関係 構成ファイル、ソースアーティファクト、ビルドツールなど、ビルドプロセスの初期化または実行中にフェッチされた アーティファクト Outputs 出力 ビルドによって生成されたアーティファクト群 Provenance 来歴/工程証跡 プラットフォームと外部パラメータの識別を含む、出力がどのように生成されたかを説明する証明情報 (メタデータ)
38. 語句定義： パッケージモデル 
 語句 説明 Package パッケージ 配布を目的としたソフトウェアの識別可能な単位。「アーティファクト」または「パッケージ名」のいずれかを曖昧に意味する。この用語 は、曖昧さが許容されるかあいまいな方が望ましい場合にのみ使用すること Package artifact パッケージアーティファクト 配布を目的としたファイルまたはその他の不変（immutable）オブジェクト Package ecosystem パッケージエコシステム クライアントがパッケージ名を 1 つ以上の特定のアーティファクトに解決する方法など、パッケージの配布方法を管理する一連の規 則・規約 Package manager client パッケージマネージャークライアント パッケージ エコシステムと対話するためのクライアント側ツール Package name パッケージ名 変更可能なアーティファクト群の主識別子。同じソフトウェアであっても異なるバージョンは異なる名前を持つ。パッケージ名は consumer がソフトウェアを入手するために使用する主な識別子となる。 パッケージ名はエコシステム + レジストリに固有であり、メンテナが管理し、特定のハッシュやバージョンよりも一般的で、ソースの 「正しい」場所を示す(訳注：？)。パッケージ エコシステムではパッケージ名を Maven のグループ ID のような何らかの階層でグルー プ化する場合があるが、SLSA にはこれを表す特別な用語がない Package registry パッケージレジストリ パッケージング エコシステム内のアーティファクトにパッケージ名をマッピングする責任を負うエンティティ。ほとんどのエコシステム は複数のレジストリ (通常は 1 つのグローバル レジストリと複数のプライベート レジストリ) をサポートする Publish (a package) (パッケージの)公開 アーティファクトをパッケージ レジストリに登録して、アーティファクトを使用できるようにすること。技術的には、これはアーティファクト をパッケージ名に関連付けることを意味する。これは必ずしもアーティファクトを完全に公開することを意味するわけではない。アー ティファクトは、内部テストやクローズド ベータなど、一部のユーザーに対してのみ公開される場合がある
39. 語句定義： 検証モデル 
 語句 説明 Expectations 期待・想定 パッケージの来歴メタデータに記載された一連の強制事項。パッケージの producer は、明示的にせよ暗黙 的にせよ、パッケージに対して expectations を設定することになる （訳注：「強制事項」は constraints の訳。ビルドでソースに対して何が適用されるか、ということを意味してい る考えられる） Provenance verification 証跡の検証 アーティファクトは、パッケージが使用される前にパッケージの expectations が満たされていることを確認す るために、パッケージ エコシステムによって検証される Build platform certification ビルドプラットフォーム認定 ビルドプラットフォームは、宣言するレベルの SLSA 要件を満たしていることを 認定される必要がある
40. 留意事項 本資料に記載されている会社名、製品名、サービス名は、当社または各社、各団体の商標もしくは登録商標です。 その他本資料に記載されているイラスト・ロゴ・写真・動画・ソフトウェア等は、当社または第三者が有する知的財産権やその他の権利により守られております。 お客様は、当社が著作権を有するコンテンツについて、特に定めた場合を除き、複製、改変、頒布などをすることはできません。 本資料に記載されている情報は予告なしに変更されることがあります。また、時間の経過などにより記載内容が不正確となる場合がありますが、当社は、当該情報を更新する義 務を負うものではありません。