Google Launches OSS Rebuild to Expose Malicious Code in Widely Used Open-Source Packages

Jul 23, 2025Ravie LakshmananSoftware Integrity / DevSecOps

Google recently unveiled the launch of a groundbreaking initiative known as OSS Rebuild to enhance the security of open-source package ecosystems and mitigate software supply chain attacks.

Matthew Suozzo from the Google Open Source Security Team (GOSST) emphasized in a blog post that, “As supply chain attacks persist in targeting commonly-used dependencies, OSS Rebuild equips security teams with valuable data to prevent compromises without imposing additional burdens on upstream maintainers.”

The primary objective of the project is to offer build provenance for packages on the Python Package Index (Python), npm (JS/TS), and Crates.io (Rust) package registries, with future plans to expand to other open-source software development platforms.

Through OSS Rebuild, the goal is to utilize declarative build definitions, build instrumentation, and network monitoring capabilities to generate reliable security metadata. This metadata can be used to verify the package’s origin and ensure that it has not been tampered with.

Cybersecurity

Google explained, “By employing automation and heuristics, we establish a potential build definition for a target package and reconstruct it. We then compare the outcome with the original upstream artifact, standardizing each to eliminate inconsistencies that could hinder bit-for-bit comparisons (e.g., archive compression).”

Once the package is successfully reproduced, the build definition and result are shared via SLSA Provenance as an attestation mechanism. This allows users to validate its origin, replicate the build process, and even customize the build based on a known-functional foundation.

In scenarios where complete automation is not feasible, OSS Rebuild offers a manual build specification as an alternative.

According to Google, OSS Rebuild can play a crucial role in identifying various types of supply chain compromises, including:

  • Published packages containing code not found in the public source repository (e.g., @solana/web3.js)
  • Questionable build activities (e.g., tj-actions/changed-files)
  • Unusual execution paths or suspicious operations embedded within a package that are challenging to detect through manual inspection (e.g., XZ Utils)

Cybersecurity

In addition to fortifying the software supply chain, this solution can enhance Software Bills of Materials (SBOMs), accelerate vulnerability response times, reinforce package trust, and relieve CI/CD platforms of the responsibility for an organization’s package security.

Google stated, “Rebuilds are generated by analyzing the published metadata and artifacts and are compared against the upstream package versions. When successful, build attestations are issued for the upstream artifacts, validating the integrity of the original artifact and eliminating numerous potential compromise sources.”