Google Launches OSS Rebuild to Reinforce Open Source Supply Chain Security

21 July 2025 – Mountain View, CA – In a bold move to reinforce software supply chain security, Google has unveiled OSS Rebuild, a scalable, automation-driven platform that reproduces and verifies open source packages. This initiative aims to provide verifiable SLSA Build Level 3 provenance across major ecosystems-Python (PyPI), JavaScript (npm), and Rust (Crates.io)-offering CISOs, SOC leads, and developers trusted metadata without requiring intervention from package maintainers.

With open source software now comprising 77% of modern applications and estimated to power over $12 trillion of global value, its ubiquity has become a double-edged sword. Recent attacks on critical packages – such as xz-utils (2024) and tj-actions/changed-files (2025) – expose how easily compromised components can cascade into widespread security incidents.

Google’s OSS Rebuild responds with reproducible builds, dynamic analysis, and SLSA Provenance that help verify package integrity, enabling defenders to detect tampering, prevent compromise, and trust what they deploy.

“OSS Rebuild gives the security community transparency into open source packages that’s on par with managing source code,” said Matthew Suozzo, Google Open Source Security Team (GOSST).

Inside OSS Rebuild

How It Works

At its core, OSS Rebuild automates the following:

• Derives declarative build definitions for open source packages.
• Rebuilds the packages using a controlled, observable environment.
• Compares the result against the original artifact, normalizing non-deterministic elements.
• Publishes verifiable SLSA provenance metadata, allowing defenders to trace origins and validate integrity.

Packages that match their source definitions receive a public attestation. When deviations occur – such as extra code not present in source repos – OSS Rebuild flags the discrepancy.

Coverage

OSS Rebuild currently supports:

• PyPI: Python packages (e.g., absl-py)
• npm: JavaScript/TypeScript (lodash@4.17.20)
• Crates.io: Rust (syn@2.0.39)

Google plans to expand support across ecosystems, enabling reproducibility for thousands of widely-used libraries.

AI Assistance

To overcome the complexity of some build processes, Google is experimenting with AI that can infer build logic from natural language documentation a promising path to broaden automation without shifting work to maintainers.

Security Capabilities of OSS Rebuild

OSS Rebuild addresses three critical attack vectors:

Unsubmitted Source Code

If a package contains code not in its source repo, OSS Rebuild refuses to attest.
Real-world example: solana/web3.js compromise, 2024

Build Environment Compromise

By using minimal, monitored environments, the platform detects anomalies or avoids exposure.
Real-world example: tj-actions/changed-files backdoor, 2025

Stealthy Backdoors

Dynamic analysis can flag unexpected behavior during build-time, including logic bombs or covert channels.
Real-world example: xz-utils supply chain attack, 2024

Implications for MEA and Global Stakeholders

MEA Security Ecosystem

Though the OSS Rebuild launch is U.S.-based, it holds serious value for MEA nations where open source adoption is high but supply chain governance remains under-resourced. Organizations in UAE, Nigeria, Kenya, and South Africa – increasingly reliant on public code – stand to benefit from the platform’s transparency and automation.

“This kind of tooling shifts the paradigm. Reproducibility and attestation should become default requirements in regulated open source environments,” said Dr. Aisha Rahim, Chief Security Architect, East Africa Digital Trust Alliance.

How Enterprises Can Use OSS Rebuild

OSS Rebuild is designed for both consumers and producers of packages:

For Security Teams

• Integrates into security services, vulnerability scanners, and SBOM generators.
• Adds fine-grained build observability to supply chain workflows.
• Enables vendor patching and re-hosting with confidence.

For Publishers

• Boosts trust via independent package validation.
• Provides attestations for historical releases, even if SLSA wasn’t adopted earlier.
• Reduces CI/CD exposure, shifting integrity checks out of complex build systems.

Actionable Takeaways for Security Professionals

1. Audit high-risk dependencies using OSS Rebuild attestations.
2. Integrate SLSA metadata into vulnerability management platforms.
3. Enforce reproducible builds for internal and third-party packages.
4. Monitor for deviation warnings in packages that fail to rebuild cleanly.
5. Use OSS Rebuild CLI (oss-rebuild) to fetch and verify packages.
6. Update SBOM processes to include build reproducibility signals.
7. Segment build infrastructure using Google’s reproducible environments as a model.
8. Educate DevOps teams on SLSA best practices.
9. Involve AI tools in build process documentation and exploration.
10. Contribute to OSS Rebuild by submitting manual specs or testing new packages.

Conclusion

OSS Rebuild marks a pivotal milestone in Google’s supply chain security journey, offering a practical path to regain trust in open source packages. For defenders, it replaces uncertainty with cryptographic attestation. For developers, it reduces operational burden. For the world, it signals a future where secure by default is no longer aspirational, but achievable.

The call to action is clear: Get involved, stay transparent, and rebuild trust-one package at a time.

References

• Introducing OSS Rebuild: Open Source, Rebuilt to Last (Google Blog, 21 July 2025)
• SLSA Provenance Framework
• Solana/web3.js Backdoor Incident Summary (2024)
• xz-utils Supply Chain Attack Explained (2024)
• tj-actions/changed-files compromise overview (2025)
• Google OSS-Fuzz Initiative
• OSS Rebuild GitHub Repository
• Secure Open Source Software Supply Chains