Mavenアーティファクトの84%が不透明？OSSサプライチェーンに潜むリスクと「再現可能なビルド」の自動化 • vonxai blog

現代のソフトウェア開発において、Maven Centralのようなエコシステムが提供するライブラリは「水道」や「電気」のような不可欠なインフラですが、私たちが普段利用しているそのバイナリが、公開されているソースコードから正しく生成されたものであるかを確認する術は限られています。もしコンパイル過程で悪意あるコードが混入していれば、ソースコードレビューだけでは防ぐことができず、昨今のサプライチェーン攻撃のリスクに対抗するためには、バイナリがソースコードから再現可能であることを第三者が検証できる「再現可能なビルド（Reproducible Builds）」が不可欠となっています。

本記事では、Oracle Labsの研究チームが発表した論文「Unlocking Reproducibility: Automating re-Build Process for Open-Source Software」に基づき、トップ1,200のアーティファクトの84%が透明性のあるビルドパイプラインを経ていないという衝撃的な実態と、GitHub Actionsの解析を通じてビルドプロセスを自動復元する最新技術「BUILDGEN」について解説し、OSSサプライチェーンのセキュリティ強化に向けた新たなアプローチを紹介します。

衝撃の事実：トップ1,200ライブラリの8割以上が「ビルド経路不明」

研究チームはまず、Maven Centralで最も頻繁に使用されているトップ1,200のアーティファクト（ライブラリ）を対象に、そのリリースプロセスの透明性を調査しました。その結果は衝撃的なものでした。約84%のアーティファクトが、透明性のあるCI/CDパイプラインを経てビルドされていないことが判明したのです。

調査項目	件数	割合	意味合い
アーティファクト総数	1198	100%
ソースコード（コミット）が特定できたもの	963	80.38%	ソース自体は公開されている
透明性のあるCI/CDパイプラインが確認できたもの	191	15.95%	ビルド過程が追跡可能
GitHub Actionsの実行ログが削除されていたもの	471	39.31%	検証の手がかりがない
リリース後にコードがコミットされたもの	87	7.26%	手動リリースの可能性が高い
SLSA来歴メタデータが含まれていたもの	2	0.17%	改ざん防止の証明がある

図表1：Mavenアーティファクトのリリースの透明性調査

このデータは、私たちが利用しているライブラリの大多数が、「ソースコードはこれです」と言われつつも、実際には開発者のローカルPCなど、不透明な環境でビルドされたバイナリを信頼して使っているという現状を突きつけています。特に、セキュリティの厳格な証明であるSLSA（Supply-chain Levels for Software Artifacts）メタデータを含んでいたのは、わずか0.17%（2件）でした。

ソースコードからの「再ビルド」を自動化する壁

この不透明性を解消する唯一の手段は、利用者側（あるいは第三者機関）がソースコードからバイナリを再ビルドし、配布物と一致するか検証することです。しかし、これには2つの巨大な技術的障壁があります。

正確なソースコード（コミット）の特定: バージョンタグの命名規則がプロジェクトごとにバラバラである。
ビルド環境の再現: 当時使用されたJDKのバージョン、Maven/Gradleのバージョン、環境変数が分からないとビルドは失敗する。

新ツール「BUILDGEN」のアプローチ

研究チームは、既存のセキュリティツール「 Macaron 」を拡張し、これらのプロセスを完全自動化する 「BUILDGEN」 を開発しました。従来の手法（AROMAなど）が「ビルドコマンドを推測する」アプローチだったのに対し、BUILDGENは 「GitHub Actionsのワークフロー定義ファイルを静的解析・データフロー解析する」 という画期的な手法を採用しています。

図表2：ソースコードからのビルド自動化パイプライン 図表2：BUILDGENによる自動化パイプライン

具体的には、リポジトリ内の .github/workflows を解析し、実際にリリースに使われたコマンド、JDKバージョン、環境変数を抽出します。これにより、推測に頼らない高精度なビルド仕様書（Build Spec）の自動生成が可能になりました。

図表3：ビルド仕様書の生成ワークフロー 図表3：GitHub Actions解析から仕様書生成までの流れ

検証結果から見えた「再現性」を阻む真の課題

提案システムを用いて、既存の再現可能データセット（Reproducible Central: RC）に含まれるパッケージの再ビルド実験が行われました。結果は良好で、特に従来手法では対応できていなかったGradleプロジェクトの再ビルドにも成功しました。

しかし、ツールの成功率以上に、 「なぜ失敗したか」 の分析こそが、OSSエコシステムの現状を物語っています。

RC	AROMA	BUILDGEN	ビルドツール	結果の概要
失敗	失敗	失敗	Maven	環境差異: 古いプラグインやJDKの不一致
成功	成功	成功	Maven	成功多数: 73パッケージで完全再現
失敗	成功	失敗	Maven	ラッパー問題: Maven Wrapperの挙動差異
成功	-	成功	Gradle	新規対応: 19件のGradleビルドに成功

図表4：既知の再現可能パッケージに対する再ビルド検証結果

1. 「Maven Wrapper」の落とし穴

BUILDGENが失敗し、AROMA（従来手法）が成功した数少ないケースでは、「Maven Wrapper (mvnw)」が原因となっていました。CI上では mvnw が特定の（古い）Mavenバージョンをダウンロードして実行しようとしますが、現代の環境ではそのバージョンが動かなかったり、互換性がなかったりするのです。逆にAROMAは mvnw を無視してシステムの最新Mavenを強制使用したため、偶然成功していました。これは、 「厳密な環境再現をしようとするほど、過去の負債（古いツールチェーン）に足元をすくわれる」 というジレンマを示しています。

2. 「野良」パッケージと依存関係の消滅

さらに、再現性が保証されていないランダムな200個の「野良」パッケージに対する実験では、さらに深刻な問題が浮き彫りになりました。以下がその主要な結果の抜粋です。

カテゴリ / 発見事項	件数
ビルド仕様書生成の結果（200パッケージ）
ビルド仕様書の生成に成功	134
ビルド仕様書生成の改善待ち（失敗）	66
生成失敗の主な要因
リポジトリ情報が利用不可またはアクセス不能	36
Maven/Gradle以外のビルド（SBT, Antなど）	23
生成されたビルド仕様書による再ビルド結果（計134件）
再ビルド成功（Maven + Gradle）	40
再ビルド失敗（Maven + Gradleエラー）	69
システムレベルの問題（環境やセットアップなど）によるビルド失敗	25

図表5：AROMAやRCに含まれない200のMavenパッケージの評価結果（主要な項目を抜粋）

最も大きな障壁となったのは、ツールのバグではなく 「依存関係の利用不可（Dependency Availability）」 でした。かつてはビルドできていたプロジェクトでも、依存していた古いライブラリがMaven Centralから削除されたり、リポジトリが移動したりすることで、二度とビルドできなくなっているケースが散見されました。

これは「ソフトウェアの腐敗（Software Rot）」とも呼べる現象です。どれだけ優秀な自動化ツールがあっても、エコシステムからパーツが失われてしまえば、パズルを完成させることは不可能です。

まとめと今後の展望

本研究は、OSSサプライチェーンのセキュリティにおいて、以下の重要な示唆を与えています。

現状の不透明さ: トップレベルのOSSでさえ、84%はビルドプロセスがブラックボックスであり、完全な信頼を置くにはリスクがある。
自動化の進化: GitHub ActionsなどのCI定義を解析することで、ビルド仕様の復元は高い精度で自動化可能になった（BUILDGENの成果）。
インフラの課題: 真の「再現可能なビルド」を実現するには、ソースコードだけでなく、ビルドツールや依存ライブラリを含めた 「ビルド環境の保存・永続化」 が不可欠である。

「ソースコードがあるから安心」という時代は終わりました。今後は、BUILDGENのようなツールを用いて、自分たちが依存しているライブラリが「本当にそのコードから生まれたものか」を検証するプロセスが、企業のセキュリティ要件として求められるようになるでしょう。

Webサービスや社内のセキュリティにお困りですか？弊社のサービスは、開発チームが抱える課題を解決し、生産性と幸福度を向上させるための様々なソリューションを提供しています。ぜひお気軽にご相談ください！

参考資料:

Unlocking Reproducibility: Automating re-Build Process for Open-Source Software