SLSAで始めるソフトウェア・サプライチェーンセキュリティ：現状・課題・将来の展望

1. はじめに：ソフトウェアサプライチェーンとSLSAの重要性

近年、ソフトウェアサプライチェーンのセキュリティ対策が世界的に注目されています。米国DoD（国防総省）の調達事例でも、兵器システム（例：F-35戦闘機）におけるソフトウェア依存リスクが指摘され、日本の製造業や企業システムでも他人事ではなくなりました。参考：【解説】ソフトウェア・サプライチェーンリスク管理と調達におけるセキュリティフレームワーク ASF の紹介 ──実務に役立つポイントを整理

そこで注目されているのが、SLSA（Supply-chain Levels for Software Artifacts）というフレームワークです。Googleが提唱するSLSAは、ソースコードからビルド、リリースに至るまでのプロセスを可視化し、改ざんリスクを低減するための手法をまとめています。

本記事では、ソフトウェアサプライチェーンのリスク管理を強化するための枠組み SLSA について解説します。企業のセキュリティ担当者を念頭に、SLSA の基本概念やビルド環境のリスク事例、現状の導入状況と課題、そして将来的な見通しをまとめました。

2024年10月22～23日に開催された SOSS・Fusion/24 での講演
**Continuous Assurance of Supply Chain Security Levels of Open Source Artifacts using SLSA 0.1 - Krithika Venugopal & Raj Krishnamurthy, ComplianceCowから、その内容を紹介します。

SLSA を使用したオープンソース成果物のサプライチェーンセキュリティレベルの継続的な保証 - Krithika Venugopal および Raj Krishnamurthy、ComplianceCow
エンドユーザーが信頼できるビルドシステムによって生成された SLSA の出所を適切に検証し、変更されたソースからのビルド、ビルドプロセスの侵害、変更されたパッケージのダウンロードなどの脅威から保護する方法について語られています。

【ポイント】

SLSA は「誰がどこでどのようにビルドしたか」を証明する概念
Provenance による「誰がどこでどうビルドしたか」の記録
SLSAは以下のリスクを防ぐことを目的とする
1. ソースコード改ざん
2. 依存関係の悪用
3. ビルド環境の侵入・バックドア
動画では、実際のリスク事例や SLSA の各レベルが紹介される

Provenance
ソフトウェアをビルドした際の「ビルド環境・依存関係・リポジトリ情報」などを記録するデータ

2 サプライチェーンの脅威モデル

slide

上のスライドはソフトウェアサプライチェーン内で起こりうる脅威を「ソース（Source）」「依存関係（Dependencies）」「ビルド（Build）」「パッケージ（Package）」の各段階に分けて示しています。アルファベット（A～H）はそれぞれの典型的な攻撃例です。
最終的には、右下にある「Provenance Verification（プロベナンスの検証）」により、「どのソースから、どんな依存関係を使って、どのようにビルドされたか」を確認することで、これらの脅威を防ぐ必要があることを表しています。

以下に、図中のA-Hの説明と代表的な事例をまとめました。

脅威ID	日本語での説明	代表的な事例・ケース
A	不正な変更の投稿（Submit unauthorized change）ソースコードに権限のない人が改変を行い、開発者に気づかれないまま取り込まれてしまうリスク。	Linuxカーネルへのバックドア提案 (2003) 権限のない人物が巧妙に変更を提案し、メンテナのレビューをすり抜けようとした事件。実際に発覚したため大事には至りませんでしたが、もし受け入れられていたら深刻な被害をもたらす可能性がありました。参考: LWN.net (2003)
B	ソースリポジトリの侵害（Compromise source repo）ソースコードを保管しているリポジトリ自体が攻撃者に乗っ取られ、正規のコードが改ざんされるリスク。	PHP公式リポジトリの改ざん (2021) PHPの公式Gitリポジトリが何者かにハイジャックされ、一時的にソースに不正なコミットが加えられました。すぐに発覚・ロールバックされたものの、正規のリポジトリが攻撃されるリスクを示す事例です。公式メーリングリスト (2021)
C	改ざんされたソースからのビルド（Build from modified source）すでに改変されたソースをビルドに使ってしまい、気づかぬうちに不正な成果物が生成されるリスク。	Webminリポジトリの改ざん (2019) Webサーバ管理ツールWebminの公式ソースコードに攻撃者がバックドアを仕込み、ユーザーが正規バージョンと思い込んで改ざん済みソースをビルド・配布していた疑いがある事件。 Webmin公式説明
D	改ざんされた依存関係を使用する（Use compromised dependency）外部ライブラリやモジュールが侵害されている場合に、それを取り込んでしまうリスク。	event-stream事件 (2018) Node.jsの人気ライブラリ「event-stream」に悪意のある依存関係が追加され、暗号通貨ウォレットを狙った攻撃が仕込まれました。 GitHub Issue (詳細)
E	ビルドプロセスの侵害（Compromise build process）ビルド環境や手順が攻撃を受け、バックドアやマルウェアを挿入されるリスク。	SolarWinds事件 (2020) ソフトウェア企業SolarWindsのビルド環境が攻撃者に侵害され、アップデートにマルウェアを混入。大手企業・政府機関にまで影響が及んだ大規模インシデントです。 CISA公式情報
F	改ざんされたパッケージのアップロード（Upload modified package）正式な成果物のふりをした、不正なパッケージを配布側にアップロードされるリスク。	npmの「UA-Parser.js」改ざん (2021) 正規パッケージがアカウント乗っ取りにより改ざんされ、不正版が公式レジストリに公開。問題のあるバージョンはすぐに削除され、利用者にアップグレードが呼びかけられた。 GHSA-pjwm-rvh2-c87w
G	パッケージレジストリの侵害（Compromise package registry）パッケージ配布レジストリが攻撃者に制圧され、ユーザーが気づかないまま不正パッケージをダウンロードさせられるリスク。	RubyGemsレジストリでの不正パッケージ RubyGems上で正規のgemを置き換えたり、そっくりな名前のgemを大量登録して利用者を騙す手口が散発的に確認されています。 strong_passwordの事例
H	改ざんされたパッケージの使用（Use compromised package）ユーザーや開発者が、その不正パッケージを本物と信じてインストール・使用してしまうリスク。	PyPIでのtypo-squattingや改ざん事例 PythonのPyPIリポジトリに類似名の悪意あるパッケージが登録され、利用者が誤ってインストールするケースがたびたび起こります。 ZDNET

SLSAのレベル構造：L1～L3

SLSAでは、ビルド環境の強度やProvenance（ビルド情報）の管理レベルを指標化しています。SLSA 1.2時点では L1～L3 までが定義され、数字が上がるほど環境がセキュアになると考えられています。

レベル	特徴	信頼度
L1	とりあえず Provenance（ビルド情報）を生成	低い
L2	公式CI/CDなどのホストでビルド	中程度
L3	ビルド環境をセキュアに管理（ハードニング）	高い

slide

動画: 1:25 でレベルの違いを解説

この図は SLSA 1.0 の成熟度（Maturity）レベルを示しています。左下の Build L0（レベルゼロ）から始まり、レベルが上がるほどビルド環境がセキュアになるイメージです。

Build L0: None
Provenance（ビルド情報）がまったく生成されず、何の保証もない状態。
Build L1: Build provenance
Provenance は生成されるが、その内容の信頼性までは保証されていない段階。
例）開発者PCなどから手動で Provenance を作っても、正しさを証明する仕組みがない。
Build L2: Signed provenance from hosted build platforms
公的な（ホストされた）ビルド環境で Provenance を生成し、署名することである程度の信頼を確保する段階。
例）GitHub Actions や公式CI/CDなどで署名つき Provenance を作成しているが、ビルド環境自体の安全性はまだ完全に保証されない。
Build L3: Hardened platform
ビルドプラットフォームが十分なセキュリティ対策 >ハードニングを施されており、ビルドプロセス全体の信頼度が高い段階。
例）ビルドマシンが厳格に管理・監査され、キャッシュ汚染などのリスクにも強い体制。

表の右側には各レベルに対応するコメントが書かれていて、

L1 では「Provenanceは生成するが整合性は不明」
L2 では「ホストされたビルドの署名があるが、本当に安全か？」
L3 では「ビルド環境のコントロールが十分で、よりセキュア」
といった概要が簡単に示されています。

L2 でもキャッシュ汚染などのリスクは残り、L3 でようやくビルド過程の改ざんリスクを大幅に下げられます。

4. Provenance: ビルド結果の正当性を証明するためのメタデータ

Provenance は、ビルド結果の正当性を証明するためのメタデータです。たとえば「どのブランチを使ったか」「コミットは署名されているか」「依存関係は正しいものか」などの情報が記録され、外部からでも検証しやすくなります。

【ポイント】

2:53: subject（成果物）と predicate（ビルド環境・依存関係・設定）
コミット署名やブランチ保護、リポジトリURLなどを明示し、不正混入を判定できる

predicate
ビルドの詳細情報（環境・依存関係・設定など）をまとめる要素

slide

上の図は SLSA Provenance（プロベナンス）の構造を示しています。

Subject: どの成果物（例: イメージ）を指すかを特定し、名前とダイジェスト（ハッシュ）を持つ
Predicate:
- Builder Id: ビルドを行ったビルダーを特定
- Build Definition: ビルドの具体的な定義（Type、Configuration、Environment、Build Materials）
  - Type: ビルドのテンプレートや方式
  - Configuration: リポジトリURLやワークフローなどの設定
  - Environment: ビルド時のパラメータやリソース
  - Build Materials: ソースやベースイメージなど、使用した依存要素（URI とダイジェスト）を記録

つまり、Provenance には「どのイメージを、どのビルダーや環境、依存関係を使ってビルドしたか」がまとめられ、外部からでも“何がどう作られたか”を確認できるようにする仕組みを表しています。

slide

上の図は、Provenance（ビルド情報）を使って何を検証できるか を整理しています。4つのカテゴリに分かれており、それぞれチェックできる不正や改ざんが例示されています。

Attestation Verification
- Provenance（ビルド情報）の存在有無や改ざんの有無を確認
Verify subject
- アーティファクト（成果物）自体の改ざんや、typo squatting >似た名前のパッケージに置き換えがないかをチェック
Verify build material
- ビルド元リポジトリやブランチ、コミットが正当か、ビルド後にソースコードが改ざんされていないか、出力イメージのダイジェストが偽造されていないかなど
Verify build configuration
- ビルド手順やビルダーが正しいか、入力パラメータに不審なものが含まれていないかを確認

要するに、Provenanceを用いることで「誰が、どんな依存関係や設定で、どのコミットを使ってビルドしたか」を総合的に検証できる仕組みを説明しています。

5. サプライチェーンの具体的なリスクの例

SLSA によって大半のリスクは軽減されますが、キャッシュ汚染やビルド環境へのバックドアなど完全に排除しきれない部分も残ります。動画では以下の事例が紹介されています。

5.1 キャッシュ汚染

参照: 3:36
複数のビルドが連続するとき、先のビルドのキャッシュが汚染されていると、次のビルドに影響
L2 でもキャッシュ管理は必須だが、運用上の課題が残る

5.2 SolarWinds のようなビルド環境バックドア

参照: 3:47
SolarWinds はビルドプラットフォーム自体が攻撃され、マルウェアが仕込まれた事例
外部からはビルド環境内部が見えないため、Provenance などの証拠がないと追跡が困難

5.3 Typo-squatted パッケージ

参照: 5:56
正しいパッケージ名に似せた悪意ある名前を登録し、ユーザーを誤誘導
Provenance でビルドマテリアル（依存関係）をチェックすれば、本当に正規リポジトリか判定しやすい

typo squatting
パッケージ名のタイプミスを狙って、似た名前の悪意あるソフトをダウンロードさせる攻撃

6. 現在のSLSAの動向と課題

SLSA はビルド面中心の要件が多く、ビルド環境のハードニング情報やソース管理要件が十分カバーされていない問題があります。また、実際の導入事例もまだ少ないという印象です。

現状	課題
ビルド信用が前提	ハードニング状況やソース管理の保証不足
SLSA導入例が少ない	全レベルを満たしている事例は公表されていない

参照: 8:02
- ビルダーがどの程度ハードニングされているか、Provenanceに含まれていないという問題
参照: 8:56
- ソーストラック >ソース面の要件が弱体化しており、ブランチ保護やコミット署名の完全保証は難しいという問題

Integrity
ソースコードやデータに改ざんがなく、正当性が保たれた状態

slide

この図は ソースコードのインテグリティ（改ざん防止） における「理想（IDEAL）」と「現実（REAL）」のギャップを示しています。

左側（理想）
- Hardened Source Control Platform
  ソース管理システム自体をしっかりハードニング（セキュリティ強化）する
- All changes are authorized
  すべての変更が権限のある人だけに限られ、承認されている
- Signed commits
  コミットが署名されていて、改ざん防止を徹底している
右側（現実）
- How to validate hardening of the source control platform?
  実際にプラットフォームがどれほどハードニングされているか検証する方法が難しい
- Private repo - No access
  プライベートリポジトリの場合、外部からはアクセスできず、レビューや検証が不透明
- How good are signed commits?
  署名付きコミットがあっても、その鍵や署名がどこまで安全に管理されているか
- How well are the code reviews done?
  コードレビューの実施状況（十分な人数やプロセスか）はどうか

要するに、理想的にはソース管理が万全で、署名や承認フローが完璧であってほしいが、実際には検証方法や管理プロセスの不備など課題が残る、という対比を表しています。

7. 現在のSLSA導入状況

動画では、どの企業が何レベルまで達成しているかなどの具体例は語られませんでした。登壇者が「SLSAを導入している方？」と会場に質問した場面では、手を挙げたのは少数であり、本格的な導入はこれからという印象です。

【ポイント】

具体的な企業名やプロジェクトの達成レベルは不明
OSS プロジェクトや一部 CI/CD サービスで、L2 相当の Provenance 自動生成を試行する動きはある
L3 まで完全に準拠している事例はまだ少ないと考えられる

8. 将来の方向：L4の再現可能ビルド

将来のSLSAには L4: Reproducible Build（再現可能ビルド）も盛り込まれ、「同じソースと環境であれば誰がビルドしても同一のバイナリを得られる」状態を目指します。
これにより改ざん検知がさらに容易になり、環境の区別なくビルドの完全性を厳密に保証できる可能性があります。

【ポイント】

10:02: レベル4 の展望
コードや環境が変わらなければ、同一の成果物が必ず再現される
Provenance に記載された情報との一致を検証しやすくなる
L4実装はまだ一般化していないが、OSS界隈では徐々に取り組みが進む
SLSAの最終目標は「ビルド環境を含めた信頼の連鎖」を確立すること

Reproducible Build
同じソースと環境で作れば誰が行っても同じバイナリが生成されるビルド手法

9. まとめ

SLSA はソフトウェアサプライチェーンの改ざんやマルウェア混入リスクを低減するうえで注目を集めていますが、導入例はまだ限られています。とりわけ L3 まで揃えた事例は少なく、ビルド環境ハードニングやソース管理の要件不足などが課題です。一方、将来的にはレベル4（再現可能ビルド）の普及によって、改ざん検出がより厳密になる可能性があります。まずはL1やL2相当の導入から始め、Provenanceをしっかり生成して署名するところから着手してみるのが現実的でしょう。

FutureVulsでは、企業の脆弱性管理を支援するSaaSを通じて、こうした継続的なセキュリティ対策を導入しやすい環境をご提供しています。

FutureVulsのソフトウェア・サプライチェーンに関連する機能