Google の OSS Rebuild がスタート：リポジトリ汚染を一掃する試みへの期待とは？

Google Launches OSS Rebuild to Strengthen Security of The Open-Source Package Ecosystems

2025/07/24 CyberSecurityNews — 現代のソフトウェア・サプライチェーンは、無数のサードパーティ・コンポーネントに依存しているため、それらのパッケージ・リポジトリは攻撃者にとって格好の標的となっている。この１年の間に発生した、xz-utils バックドアや solana/webjs タイポスクワッティングなどの、注目を集めるセキュリティ侵害が示したのは、防御側が認知する前に、広く利用されているライブラリを巧妙なコードで汚染するという、可能性があることだった。

そして、Google が新たに発表した OSS Rebuild イニシアチブは、Python／JavaScript／Rust の各パッケージを、密閉された環境で自動的に再構築し、各アーティファクトの暗号署名付き SLSA の出所を公開することで、この問題に正面から対応するものとなっている。

不透明なビルド・プロセス中に、攻撃者が悪意のロジックを挿入する事例が増加しているため、すべての要素を勘案してバイナリを再現する能力が、すべてをカバーする制御手段になるという。

Google Security Blog のアナリストたちが、アップ・ストリームのコミットとレジストリに公開されたペイロードを比較した結果、マルウェアのソースコードと公開バイトコードの間に明確な相違が確認された。それは、大規模かつ再現可能なビルドの必要性を強調するものだった。

OSS Rebuild が導き出したのは、宣言的なビルド定義である。つまり、監視下にあるサンドボックス内でアーティファクトを実行し、再構築されたものとユーザーがインストールするものが異なる場合には、ビットレベルでの差分を公開することで、その必要性に応えるというスタイルである。

このホスト型サービスにおいては、PyPI／npm／Crates.io で最も多くダウンロードされている、数千のパッケージをすでにカバーしているが、Google はパイプラインをオープンソース化することで、それぞれの企業が独自のミラーを展開できるようにしている。

シンプルな Go ベースの CLI により、その宣言の表示が可能になる：

# Fetch signed provenance for the Rust crate ‘syn’ v2.0.39
$ oss-rebuild get cratesio syn 2.0.39

# List all rebuilt versions of a PyPI library
$ oss-rebuild list pypi absl-py

感染メカニズムの検証

従来のマルウェアがビルド・プロセスに潜伏する方式は、ペイロードのダウンロードまたはコンパイル後の、オブジェクト・ファイルの書き換えとなる。

OSS Rebuild では、テンポラリ・コンテナ内でビルドを分離し、送信ネットワークのブロックを用いて、すべての中間アーティファクトをハッシュ化することで、このチェーンを遮断する。

したがって、不正な curl | bash コマンドやコンパイラのフラグ切り替えにより、攻撃者がコード挿入を試みる場合であっても、再構築されたパッケージの再現は失敗し、最終ダイジェストに不一致が生じる。

つまり、疑わしいバージョンはセキュリティ・チームにより自動的に隔離されるため、変更されたシンボルを関数レベルで正確に特定する、簡潔な diff をメンテナーは精査できる。

こうして、不透明な CI パイプラインから、透明性が担保され複製が可能なビルドへと信頼を移行することで、この Google のプラットフォームは、パッケージ検証を受動的な期待から、能動的かつ測定可能な保証へと転換する。

Google が取り組む OSS Rebuild は、リポジトリ内のバイナリとソースコードの間に生じる、不一致を防ぐために設計されています。特に、再構築の過程で、外部からの不正なコードが混入するリスクが脆弱性の原因になると、この記事は指摘しています。それほどまで、OSS のリポジトリ汚染は、大きな問題になっています。よろしければ、カテゴリ Repository を、ご参照ください。