LASSIC Media らしくメディア
ソフトウェアサプライチェーン対策を外注
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- ソフトウェアサプライチェーンセキュリティは、依存パッケージだけでなくビルド・配布過程での改ざんも対象とする考え方です。
- SLSA（Supply-chain Levels for Software Artifacts）は、ビルドの来歴（provenance）記録と改ざん耐性を段階的に高めるフレームワークです。
- CIパイプラインの改修や署名検証の導入には専門知見が必要なため、外注時は委託範囲と発注準備を明確にすることが求められます。
目次
ビルド過程の改ざんという見落とされがちな脅威
ソフトウェアサプライチェーンセキュリティとは、コード管理からビルド・パッケージング・配布に至る一連の工程で、成果物の改ざんや不正な混入を防ぐための取り組みを指します*1。脆弱性スキャンやSBOM（Software Bill of Materials、ソフトウェア部品表）の整備が「何が使われているか」を可視化する取り組みであるのに対し、本記事が扱うのは「その成果物がどのように作られ、途中で改ざんされていないか」という来歴（provenance）と完全性の論点です。
この論点が注目される背景には、開発・配布プロセスの複数段階で完全性の弱点が明らかになった事例があります。ソフトウェアサプライチェーンの完全性確保に関する業界フレームワークSLSAは、SolarWinds事件やCodecov事件を挙げ、ソフトウェア製造過程の各段階に完全性の弱点が存在すると指摘しています*1。
SLSAの公式文書では、コードの改変が意図的な攻撃だけでなく「インサイダーの脅威」や「侵害されたアカウント」からも発生しうるとされ、ソースコード管理からバイナリの配布に至るまでの各段階で改ざんの危険が存在すると説明されています*1。脆弱性検出やソースコード解析は重要な取り組みですが、それだけでは十分ではなく、ビルド・配布の過程そのものが改ざんされていないことを保証する仕組みが必要だとされています*1。
依存パッケージの脆弱性やライセンスの管理（SBOM管理）は「何が使われているか」の可視化であり、本記事が扱う来歴・改ざん耐性の論点とは目的が異なります。両者は補完関係にあり、後述するように併用することでサプライチェーン全体の完全性を高められます。
SLSAが示す来歴記録と改ざん耐性の考え方
SLSAとは何か
SLSA（読み方は「サルサ」、Supply-chain Levels for Software Artifacts）は、ソフトウェアサプライチェーンセキュリティのための業界合意に基づく段階的な採用ガイドラインです*1。開発者（生産者）と利用者（消費者）の双方が活用できる枠組みとして設計されており、Google・OpenSSF（Open Source Security Foundation）などが関与するオープンな仕様として公開されています*1。
ビルドトラックの3レベル
SLSA v1.0の仕様には「ビルドトラック」と呼ばれる段階的なレベルが定義されています*1。レベルが上がるほど、ビルドプロセスの改ざんに対する耐性が高まる設計です。
Build L1は「来歴が存在する」段階です。ビルドプロセスがどのように成果物を作ったかを示す来歴（provenance）を作成・配布することが求められますが、この段階の来歴は署名がなく偽造が可能とされています*1。目的はミスの防止や出所の追跡を可能にすることにあります*1。
Build L2は「ホストされたビルドプラットフォーム」の段階です。L1の要件に加え、ホストされたビルドプラットフォームがデジタル署名で来歴に署名することが求められます*1。これによりビルド後の改ざんを防ぎ、偽造には明示的な攻撃行為が必要になるとされています*1。
Build L3は「強化されたビルド」の段階です。L2の要件に加え、ビルドプラットフォームが実行間の相互影響を防止し、署名用の秘密鍵をユーザーが操作する工程から隔離することが求められます*1。内部脅威や認証情報の漏洩に対抗する、最も強度の高い保護段階と位置づけられています*1。
来歴（provenance）が果たす役割
来歴は、ビルドプラットフォーム・ビルドプロセス・入力（ソースやビルド設定）を記録し、期待される値との比較検証を可能にする文書です*1。来歴があることで、利用者は「この成果物がどのビルド環境で、どのソースから作られたか」を検証でき、想定外の環境で作られた成果物や、改ざんされたビルド設定による成果物を判別できます。
SLSAはナビゲーション上で「開発者向け」「組織向け」「インフラ提供者向け」という3つのステークホルダー区分を設けており、立場に応じた採用ガイダンスを示す構成になっています*1。自社が生産者（ビルドを行う側）なのか消費者（成果物を利用する側）なのかによって、着手すべき対応が変わる点は導入検討の前提として押さえておく必要があります。
署名検証・SBOM・脆弱性管理との関係を整理する
Sigstoreとcosignによる署名・検証
来歴を作成しても、それが偽造されていないことを検証できなければ意味を持ちません。この検証の仕組みを提供するのがSigstoreです。Sigstoreはソフトウェアサプライチェーンセキュリティを高めるためのオープンソースプロジェクトで、開発者がリリースファイル・コンテナイメージ・バイナリ・SBOMなどの成果物に署名・検証できる枠組みを提供します*2。
Sigstoreのクライアントツールがcosignです。cosignは公開鍵・秘密鍵のペアを生成し、証明書署名要求を認証局（Fulcio）に送信します*2。利用者はOIDC（OpenID Connect）認証トークンを用いることで長期的な鍵管理の負担を避けられ、署名後に秘密鍵を破棄する運用が可能です*2。署名情報は改ざん検知が可能な追記型の台帳（Rekor）に記録され、検証時には署名そのものの正当性・証明書内のID・台帳への記録有無を確認することで、成果物が期待される送信元から来ており改ざんされていないことを確認します*2。
SBOM・脆弱性スキャンとの役割分担
SBOMは、ソフトウェアを構成するコンポーネント（依存ライブラリやOSSパッケージ）の一覧を示す部品表です。Sigstoreの説明でも、SBOMは署名・検証の対象となる成果物の一種として扱われています*2。つまりSBOMは「何が含まれているか」を示す構成情報であり、来歴・署名検証は「その成果物がどう作られ、改ざんされていないか」を示す完全性の情報という関係になります。両者は対象領域が異なるため、片方だけでは供給網全体のリスクを網羅できません。
脆弱性スキャンは、SBOMなどで可視化されたコンポーネントに既知の脆弱性が含まれていないかを検査する取り組みです。SLSAの公式文書も、脆弱性検出やソースコード分析は必須の取り組みとしつつ、それだけではビルド・配布過程の改ざんを防げないと位置づけています*1。サプライチェーン全体の完全性を高めるには、構成の可視化（SBOM）・既知の弱点の検出（脆弱性スキャン）・製造過程の改ざん耐性（SLSA・署名検証）を組み合わせる考え方が必要です。
CIパイプラインへの組み込みと段階導入の論点
SLSAの来歴生成や署名は、多くの場合CI/CD（継続的インテグレーション・継続的デリバリー）パイプラインの中に組み込む形で実装します。ここでは実務上の論点を整理します。
既存パイプラインの棚卸しが出発点になる
自社のCIパイプラインを内製で改修するには、ビルドシステムの構成理解に加え、署名基盤（Sigstore等）の統合、来歴フォーマット（attestation）の生成ロジックの実装など、複数領域の専門知識が必要です*2。既存のCI構成（利用しているビルドツール・ホスティング環境・デプロイ経路）を棚卸しし、どの工程にどのレベルの来歴・署名を組み込むかを設計する工程が最初のステップになります。
レベルは一度に最上位を目指す必要はない
SLSAはビルドトラックを複数レベルに分け、段階的にセキュリティを高める採用ガイドラインとして設計されています*1。L1（来歴の作成）から着手し、ホスト型のビルドプラットフォームへの移行によるL2、鍵管理の隔離によるL3へと順を追って強化する進め方が、フレームワークの設計思想に沿った現実的な道筋といえます。
失敗した場合の影響を踏まえた優先順位づけ
ビルドパイプラインの改ざんや、不正な成果物の配布は、検知が遅れるほど影響範囲が広がります。SLSAが挙げるSolarWinds事件のように、正規の配布経路を通じて改ざんされた成果物が利用者側に届いた場合、影響は自社だけでなく成果物を利用する取引先にも及ぶ可能性があります*1。どの成果物・どの配布経路が取引先への影響が大きいかを整理し、優先度の高いパイプラインから来歴・署名の導入を進める判断が求められます。
この設計・実装には、CI/CD構成の理解と署名基盤の統合経験の両方が必要になります。自社のエンジニアリソースだけで対応する場合、ビルドシステムの専門知識に加えて、Sigstoreのような署名基盤の運用知識を持つ人材を確保する必要があり、体制構築の負荷は小さくありません。
外注の委託範囲と発注準備で押さえる点
委託範囲の切り分け
ソフトウェアサプライチェーンセキュリティの導入を外注する場合、委託範囲は大きく分けて「現状のCIパイプラインの棚卸し・脅威分析」「来歴生成・署名検証の設計と実装」「導入後の運用・監視体制の整備」の3領域に分けられます。どこまでを外部に委託し、どこを自社で運用するかを事前に切り分けておくことが、発注後の手戻りを防ぎます。
専門パートナーに依頼した場合との違い
内製で対応する場合、CI/CDの構成理解、attestation（来歴の証明書）フォーマットへの理解、Sigstoreなど署名基盤の統合経験を持つ人材が必要です。専門パートナーに依頼した場合は、SLSAやSigstoreの仕様変更への追随、既存パイプラインへの組み込みパターンの知見を活用しやすくなります。内製・外部委託のいずれを選ぶ場合も、自社のビルド環境の特性(利用言語・ビルドツール・デプロイ経路)を発注前に整理しておくことが前提になります。
発注前に準備すべき情報
発注準備としては、まず対象とするリポジトリ・ビルドパイプラインの一覧、現在使用しているCI/CDサービス、既存のSBOM・脆弱性スキャンの運用状況を整理します。次に、どのレベル（L1〜L3）を目標とするか、対象範囲を一部のパイプラインに限定するか全体に広げるかという導入スコープを決めます。これらの情報が整理されているほど、委託先との要件のすり合わせが的確になり、見積もりの精度も高まります。
まとめ：サプライチェーン完全性を守る3つの判断軸
本稿では、ビルド・配布過程の改ざん対策としてのソフトウェアサプライチェーンセキュリティとSLSAの考え方を整理しました。要点を3つに集約すると次の通りです。第一に、脆弱性スキャンやSBOM管理だけでは製造過程の改ざんを防げず、来歴（provenance）記録と署名検証という別の視点が必要です。第二に、SLSAはBuild L1からL3までの段階的な強化を前提とした枠組みであり、一度に最上位レベルを目指す必要はありません。第三に、外注する場合は委託範囲(棚卸し・設計実装・運用監視)を切り分け、対象パイプラインや目標レベルを発注前に整理しておくことが成果を左右します。
よくある質問
SLSAとSBOMはどちらから導入すべきですか。
SLSAとSBOMは目的が異なるため優劣で選ぶものではありません。SBOMは構成の可視化、SLSAは製造過程の改ざん耐性を扱う枠組みです*1*2。自社に既存のSBOM運用があるかどうかを起点に、不足している側から着手する進め方が現実的です。
SLSAのBuild L1から始めても効果はありますか。
効果はあります。Build L1は署名のない来歴の作成が中心ですが、ビルドプロセスの記録自体がミスの防止や出所の追跡を可能にするとされています*1。L2・L3への段階的な強化を前提とした設計のため、L1から着手する進め方は枠組みの想定に沿っています。
署名検証の導入にはどのような基盤が必要ですか。
Sigstoreのような署名・検証基盤の利用が代表的な選択肢です。cosignによる署名生成、認証局(Fulcio)への証明書要求、署名記録の台帳(Rekor)への記録という一連の仕組みを組み込む必要があります*2。既存のCI/CD環境への統合方法は環境によって異なるため、事前の設計が欠かせません。
既存のCIパイプラインを大きく変更する必要がありますか。
変更範囲は目標レベルによって異なります。Build L1は来歴の生成が中心で既存パイプラインへの影響は比較的限定的ですが、Build L2以降はホスト型ビルドプラットフォームへの移行や鍵管理の隔離など、パイプライン構成そのものの見直しが必要になる場合があります*1。
外注する場合、どの工程から相談するのが現実的ですか。
まず現状のCIパイプラインの棚卸しと脅威分析から相談する進め方が現実的です。対象リポジトリやビルドツール、既存のSBOM・脆弱性スキャンの運用状況を整理したうえで、目標とするレベルや導入範囲を専門パートナーとすり合わせることで、設計・実装工程の精度が高まります。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：SLSA（Supply-chain Levels for Software Artifacts）「About SLSA」「SLSA Build Track Levels」（https://slsa.dev/spec/v1.0/about、https://slsa.dev/spec/v1.0/levels）
- *2 出典：Sigstore「About Sigstore」（https://docs.sigstore.dev/about/overview/）
