2026年8月に韓国で開催されたイベント「Open Source Summit Korea 2026」のセッション「SBOMs Aren't Enough. Secure Your Software Supply Chain End-To-End」に、ニューヨーク大学（New York University）のヨンジェ・チョン氏とジャスティン・カッポス氏が登壇した。両氏は、OpenSSF（Open Source Security Foundation）やCNCF（Cloud Native Computing Foundation）が提供するオープンソースのツール群を組み合わせることで、開発プロセス全体にわたってソフトウェアの完全性を確保する手法を解説した。

　サプライチェーンの起点となるソースコード管理は、「GitHub」などのソースコード共有サービス（フォージ）のセキュリティ機能に依存しているのが現状だ。しかし、フォージが設定したブランチ保護ルール（マージ権限や承認数など）はリポジトリ外の管理層にあるため、権限者が一時的にルールを無効化して不正コードを投入した場合、その痕跡は「Git」の履歴では追跡困難になる。従来のコミット署名はソースコードの改ざんは防げるものの、リポジトリ全体が正しい履歴を指しているかどうかまでは保証しない。

　この盲点を補うのが「gittuf」だ。gittufはポリシー管理層をフォージから切り離して、誰がマージ権限を持つかなどのセキュリティポリシーをGit自体の参照データとしてコードと共に保持する。これによって、特定のツールに依存せず、開発者がローカル環境で独立してセキュリティを検証できる体制を実現する。

ビルドプロセスの証拠記録と正確なSBOM生成

　ソースコードが正しくても、ビルド工程で不審な処理があれば成果物は汚染される。ビルドプロセスの完全性を保証するフレームワークが「in-toto」だ。in-totoは「誰が、どのソースコードと依存関係を使い、どのコマンドでビルドしたか」という過程全般のデジタル証拠（アテステーション：構成証明）を記録する。

　この証拠データをSBOM生成に活用するツールが「sbomit」だ。完成したバイナリファイルを後から解析してSBOMを作成する手法は、調理後の料理を見て材料を推測するようなもので、ビルド途中に混入した不正要素を見落とすリスクがある。sbomitは、ビルド実行中のアテステーションに基づいてSBOMを生成するため、プロセス中の事実を反映した正確な部品表を作成できる。

配布時の改ざんを防ぐクライアント検証（TUF）

　成果物の作成後、エンドユーザーにパッケージを届ける配布プロセスでも、リポジトリ侵害や署名鍵の盗難といったリスクが潜む。配布段階のセキュリティを担うのが「TUF」（The Update Framework）だ。

　TUFの特徴は、エンドユーザー（クライアント）が配布元を無条件に信頼するのではなく、署名付きメタデータを用いて安全性を自己検証する点だ。役割ごとに異なる鍵と有効期限を設定して権限を分散管理することで、仮に1つの鍵が漏えい・侵害されてもシステム全体の乗っ取りを防ぐ「侵害耐性」（Compromise Resilience）を備える。

自組織の脅威モデルに合わせた段階的導入

　gittuf、in-toto、sbomit、TUFといった一連のツール群は、単一の攻撃ではなくライフサイクル全体の隙間を埋める相互補完的なスタックだ。これら全てを一括で導入する必要はない。まずはSLSAを指針として自組織の脆弱なプロセスを特定し、リスクの高い領域から段階的に導入を進めることが、実現可能でセキュアなサプライチェーンを構築する現実的な道筋だ。