Full Report
Posted by Matthew Suozzo, Google Open Source Security Team (GOSST)Today we're excited to announce OSS Rebuild, a new project to strengthen trust in open source package ecosystems by reproducing upstream artifacts. As supply chain attacks continue to target widely-used dependencies, OSS Rebuild gives security teams powerful data to avoid compromise without burden on upstream maintainers.The project comprises:Automation to derive declarative build definitions for existing PyPI (Python), npm (JS/TS), and Crates.io (Rust) packages.SLSA Provenance for thousands of packages across our supported ecosystems, meeting SLSA Build Level 3 requirements with no publisher intervention.Build observability and verification tools that security teams can integrate into their existing vulnerability management workflows.Infrastructure definitions to allow organizations to easily run their own instances of OSS Rebuild to rebuild, generate, sign, and distribute provenance.ChallengesOpen source software has become the foundation of our digital world. From critical infrastructure to everyday applications, OSS components now account for 77% of modern applications. With an estimated value exceeding $12 trillion, open source software has never been more integral to the global economy.Yet this very ubiquity makes open source an attractive target: Recent high-profile supply chain attacks have demonstrated sophisticated methods for compromising widely-used packages. Each incident erodes trust in open ecosystems, creating hesitation among both contributors and consumers.The security community has responded with initiatives like OpenSSF Scorecard, pypi's Trusted Publishers, and npm's native SLSA support. However, there is no panacea: Each effort targets a certain aspect of the problem, often making tradeoffs like shifting work onto publishers and maintainers.Our AimOur aim with OSS Rebuild is to empower the security community to deeply understand and control their supply chains by making package consumption as transparent as using a source repository. Our rebuild platform unlocks this transparency by utilizing a declarative build process, build instrumentation, and network monitoring capabilities which, within the SLSA Build framework, produces fine-grained, durable, trustworthy security metadata.Building on the hosted infrastructure model that we pioneered with OSS Fuzz for memory issue detection, OSS Rebuild similarly seeks to use hosted resources to address security challenges in open source, this time aimed at securing the software supply chain.Our vision extends beyond any single ecosystem: We are committed to bringing supply chain transparency and security to all open source software development. Our initial support for the PyPI (Python), npm (JS/TS), and Crates.io (Rust) package registries—providing rebuild provenance for many of their most popular packages—is just the beginning of our journey.How OSS Rebuild WorksThrough automation and heuristics, we determine a prospective build definition for a target package and rebuild it. We semantically compare the result with the existing upstream artifact, normalizing each one to remove instabilities that cause bit-for-bit comparisons to fail (e.g. archive compression). Once we reproduce the package, we publish the build definition and outcome via SLSA Provenance. This attestation allows consumers to reliably verify a package's origin within the source history, understand and repeat its build process, and customize the build from a known-functional baseline (or maybe even use it to generate more detailed SBOMs).With OSS Rebuild's existing automation for PyPI, npm, and Crates.io, most packages obtain protection effortlessly without user or maintainer intervention. Where automation isn't currently able to fully reproduce the package, we offer manual build specification so the whole community benefits from individual contributions.And we are also excited at the potential for AI to help reproduce packages: Build and release processes are often described in natural language documentation which, while difficult to utilize with discrete logic, is increasingly useful to language models. Our initial experiments have demonstrated the approach's viability in automating exploration and testing, with limited human intervention, even in the most complex builds.Our CapabilitiesOSS Rebuild helps detect several classes of supply chain compromise:Unsubmitted Source Code - When published packages contain code not present in the public source repository, OSS Rebuild will not attest to the artifact.Real world attack: solana/webjs (2024)Build Environment Compromise - By creating standardized, minimal build environments with comprehensive monitoring, OSS Rebuild can detect suspicious build activity or avoid exposure to compromised components altogether.Real world attack: tj-actions/changed-files (2025)Stealthy Backdoors - Even sophisticated backdoors like xz often exhibit anomalous behavioral patterns during builds. OSS Rebuild's dynamic analysis capabilities can detect unusual execution paths or suspicious operations that are otherwise impractical to identify through manual review.Real world attack: xz-utils (2024)For enterprises and security professionals, OSS Rebuild can...Enhance metadata without changing registries by enriching data for upstream packages. No need to maintain custom registries or migrate to a new package ecosystem.Augment SBOMs by adding detailed build observability information to existing Software Bills of Materials, creating a more complete security picture.Accelerate vulnerability response by providing a path to vendor, patch, and re-host upstream packages using our verifiable build definitions.For publishers and maintainers of open source packages, OSS Rebuild can...Strengthen package trust by providing consumers with independent verification of the packages' build integrity, regardless of the sophistication of the original build.Retrofit historical packages' integrity with high-quality build attestations, regardless of whether build attestations were present or supported at the time of publication.Reduce CI security-sensitivity allowing publishers to focus on core development work. CI platforms tend to have complex authorization and execution models and by performing separate rebuilds, the CI environment no longer needs to be load-bearing for your packages' security.Check it out!The easiest (but not only!) way to access OSS Rebuild attestations is to use the provided Go-based command-line interface. It can be compiled and installed easily:$ go install github.com/google/oss-rebuild/cmd/oss-rebuild@latestYou can fetch OSS Rebuild's SLSA Provenance:$ oss-rebuild get cratesio syn 2.0.39..or explore the rebuilt versions of a particular package:$ oss-rebuild list pypi absl-py..or even rebuild the package for yourself:$ oss-rebuild get npm lodash 4.17.20 --output=dockerfile | \ docker run $(docker buildx build -q -)Join Us in Helping Secure Open SourceOSS Rebuild is not just about fixing problems; it's about empowering end-users to make open source ecosystems more secure and transparent through collective action. If you're a developer, enterprise, or security researcher interested in OSS security, we invite you to follow along and get involved!Check out the code, share your ideas, and voice your feedback at github.com/google/oss-rebuild.Explore the data and contribute to improving support for your critical ecosystems and packages.Learn more about SLSA Provenance at slsa.dev
Analysis Summary
The provided context is a snippet from a Google Online Security Blog post announcing "OSS Rebuild: Open Source, Rebuilt to Last." **Crucially, the article content itself is heavily truncated, providing only the title, date, labels (tags), and navigation links, but no substantive security guidance or recommendations regarding the "OSS Rebuild" initiative.**
Therefore, the extracted security recommendations will be based on the **implied focus areas** derived from the available tags (Supply Chain, Open Source, Security, Rust, Memory Safety, Sigstore) related to building resilient open-source software, rather than specific steps outlined in the missing body of the article.
---
# Best Practices: Securing the Open Source Software Supply Chain (Based on OSS Rebuild Context)
## Overview
These practices address the need to strengthen the security posture of Open Source Software (OSS) projects, focusing on mitigating supply chain risks, improving code quality (especially memory safety), and ensuring the integrity and provenance of software artifacts.
## Key Recommendations
### Immediate Actions
1. **Inventory Critical OSS Dependencies:** Complete an immediate audit of all direct and transitive dependencies used in production systems, prioritizing those with known vulnerabilities or high criticality.
2. **Enforce Artifact Integrity Checks:** Implement immediate post-download verification checks (e.g., using cryptographic signatures) for all critical third-party OSS libraries before deployment.
3. **Review Access Controls:** Audit and restrict write/merge access to core OSS repositories, ensuring the principle of least privilege is enforced for all core committers.
### Short-term Improvements (1-3 months)
1. **Adopt Memory-Safe Languages:** Begin aggressively migrating legacy components written in C/C++ towards memory-safe languages like Rust where feasible, aligning with industry best practices for vulnerability reduction.
2. **Integrate Automated Fuzzing:** Integrate fuzz testing tools into the Continuous Integration (CI) pipeline for all in-house developed or heavily modified OSS components to discover unintended behavior and memory safety issues.
3. **Establish Clear Vulnerability Reporting Channels:** Formalize a clear process for external researchers to report vulnerabilities, potentially adopting the vulnerability disclosure policy (VDP) model.
### Long-term Strategy (3+ months)
1. **Implement Software Bill of Materials (SBOM) Generation:** Mandate the creation and retention of standardized SBOMs (e.g., using CycloneDX or SPDX formats) for every build artifact to maintain clear visibility into composition.
2. **Adopt Digital Signing Infrastructure:** Implement and enforce the use of standardized signing infrastructure (like Sigstore) to cryptographically attest to the source, build, and integrity of all released binaries and artifacts.
3. **Sustain Memory Safety Migration:** Establish a long-term roadmap and allocated resources for systematically replacing significant portions of memory-unsafe codebases to reduce the attack surface area related to buffer overflows and use-after-free vulnerabilities.
## Implementation Guidance
### For Small Organizations
- **Focus on Dependency Vetting:** Prioritize monitoring vulnerability feeds for the top 5-10 critical dependencies being used.
- **Leverage Managed Tools:** Utilize integrated security scanners (SAST/SCA) provided by modern CI/CD platforms rather than building custom tooling infrastructure.
- **Mandate MFA:** Enforce Multi-Factor Authentication (MFA) on all developer accounts accessing source code repositories immediately.
### For Medium Organizations
- **Establish Minimum Bar for Contribution:** Define and document security requirements (e.g., mandatory successful security scan results) that must be met before any OSS contribution is merged into production branches.
- **Begin Phased Rust Adoption:** Identify one non-critical, newly developed service or module to be written entirely in Rust as a pilot program for memory safety.
- **Automate SBOM Generation:** Integrate SBOM generation into the standard build process for all deployable artifacts.
### For Large Enterprises
- **Full Supply Chain Visibility:** Implement end-to-end tracing from source code commit through build systems to final deployment, using cryptographically verifiable metadata for every step.
- **Implement Tuf/Sigstore Architecture:** Deploy an internal signing infrastructure that mirrors industry best practices (similar to Sigstore) to secure internal artifact repositories and deployment pipelines.
- **Establish Security Champions Program:** Appoint security champions within every major development team responsible for driving memory safety remediation and secure coding practices within their respective domains.
## Configuration Examples
*(Note: Since the article content is missing, these examples reflect industry standard practices commonly associated with "OSS Rebuild" concepts like supply chain security and memory safety.)*
| Security Control | Configuration Focus | Example Action |
| :--- | :--- | :--- |
| **Dependency Integrity** | Enforce cryptographic verification on source code fetching. | Configure package manager settings (`npm`, `pip`, `go mod`) to **only install packages with verified checksums** or signatures where available. |
| **Memory Safety Adoption** | Set compiler flags aggressively. | For new Rust components, enforce strong compile-time checks by setting compiler invocation arguments like `-C overflow-checks=on` (or leveraging default configurations in modern Rust builds). |
| **Artifact Signing Enforcement** | Policy for CI/CD Gateways. | Configure GKE/Kubernetes Admission Controllers or deployment pipelines to **reject any image or artifact lacking a valid Sigstore Fulcio certificate** or similar verifiable signature. |
## Compliance Alignment
- **NIST SP 800-218:** Secure Software Development Framework (SSDF) – Particularly P1 (Prepare the Organization) and P2 (Protect the Software) sections regarding vulnerability management and code integrity.
- **ISO/IEC 27034-1:** Information technology security techniques — Application security.
- **SLSA (Supply chain Levels for Software Artifacts):** Use SLSA framework levels as maturity targets for build integrity and provenance requirements.
## Common Pitfalls to Avoid
1. **Focusing Only on Direct Dependencies:** Failing to scan and secure deep, transitive dependencies, which often introduce the most significant supply chain risk.
2. **Ignoring Historical Debt:** Deferring memory safety remediation because existing C/C++ codebases are too large; this creates a persistent, high-severity attack surface.
3. **Treating Signing as Optional:** Implementing artifact signing only as a suggestion rather than a mandatory gate in the deployment pipeline, leading to potential unverified builds reaching production.
4. **Stale SBOMs:** Generating an SBOM at release time but failing to update it continuously as minor patches or dependency updates occur in maintenance branches.
## Resources
- **SLSA Framework Documentation:** Documentation detailing best practices for achieving verifiable build integrity. (Defanged Link: secure-software-supply-chain-framework-docs)
- **Sigstore Initiative:** Resources detailing standard open-source tools for artifact signing and verification. (Defanged Link: sigstore-project-homepage)
- **Rust Language Documentation:** Official documentation emphasizing memory safety guarantees and best practices for leveraging Rust in security-sensitive code. (Defanged Link: rust-lang-official-docs)