Google has unveiled a new initiative called OSS Rebuild, aimed at strengthening the security of open-source package ecosystems and defending against software supply chain attacks.
“As supply chain attacks increasingly target popular dependencies, OSS Rebuild offers security teams valuable data to mitigate risks – without adding extra burden on upstream maintainers,” said Matthew Suozzo from the Google Open Source Security Team (GOSST) in a blog post this week.
The project’s goal is to generate build provenance – trusted metadata about how packages are built – for packages hosted on Python Package Index (PyPI), npm (JavaScript/TypeScript), and Crates.io (Rust). Google also plans to expand support to other open-source platforms.
OSS Rebuild uses a mix of declarative build instructions, build instrumentation, and network monitoring to create verifiable metadata. This data helps confirm the origin of packages and ensures they haven’t been tampered with.
Google explained that OSS Rebuild uses a combination of automation and heuristics to generate a likely build definition for a given package, which is then rebuilt. “We semantically compare the result with the existing upstream artifact, normalizing both to eliminate sources of inconsistency – such as archive compression – that can break exact, bit-for-bit comparisons,” the company said.
Once the package is successfully reproduced, the build definition and its result are published using SLSA Provenance, an attestation framework that enables users to confidently verify the package’s origin, reproduce the build themselves, or customize it based on a verified, working baseline.
In cases where full automation isn’t possible, OSS Rebuild provides a manual build specification that can be used to replicate the package instead.
According to Google, OSS Rebuild can help uncover several types of software supply chain compromises, including:
- Published packages with code not found in the public source repository, indicating possible tampering or hidden changes (e.g.,
@solana/web3.js) - Suspicious build behavior, such as unexpected scripts or modifications during the build process (e.g.,
tj-actions/changed-files) - Unusual execution paths or hidden malicious operations embedded in packages—issues that are often difficult to detect through manual code review alone (e.g., the
XZ Utilsbackdoor incident)
By verifying that built artifacts match publicly available source code and detecting anomalies in build activity, OSS Rebuild aims to improve trust and transparency in open-source software.
In addition to securing the software supply chain, OSS Rebuild also brings several other benefits:
- Enhances Software Bills of Materials (SBOMs) by providing accurate, verifiable build data
- Accelerates vulnerability response by making it easier to trace and validate package contents
- Strengthens trust in open-source packages through reproducible builds and integrity checks
- Reduces reliance on CI/CD systems to manage package security, shifting that responsibility to a more transparent and standardized process
“Rebuilds are generated by analyzing published metadata and artifacts,” Google explained. “These are then evaluated against the corresponding upstream package versions. When a match is achieved, build attestations are published, confirming the integrity of the upstream artifact and ruling out many potential vectors of compromise.”
Leave A Comment