KEVWire

Security intelligence, with context.

Response snapshot Oct 26, 2026, 23:11 UTC

Back to the wire
Permalink
Advisorygoogle-security-introducing-oss-rebuild-open-source-a3fe29cc0706

Introducing OSS Rebuild: Open Source, Rebuilt to Last

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.

At a glance

Sources
1 source

What to do

Read the exact official research article before applying its defensive techniques or drawing conclusions.

Read Google Security Research: Introducing OSS Rebuild: Open Source, Rebuilt to Last (opens a new tab)

What happened

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.

Continue reading

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.

Challenges

Open 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 Aim

Our 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 Works

Through 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 Capabilities

OSS 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@latest

You 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 Source

OSS 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

Sources

  1. Primary source

    Google Security Research: Introducing OSS Rebuild: Open Source, Rebuilt to Last (opens a new tab)

    Exact official article/advisory identified by the feed; title, source dates, and any supplied article excerpt.

    Published Checked

  2. Primary source

    Google Security Research syndication feed (opens a new tab)

    The RSS/Atom/RDF entry supplied this exact link and any available title, date, and excerpt.

    Published Date not suppliedChecked

Cite this record

For factual claims, cite the primary sources above; cite KEVWire for its compilation, dates, and classifications.

APA

KEVWire. (2025, August 4). Introducing OSS Rebuild: Open Source, Rebuilt to Last. https://kevwire.com/record/google-security-introducing-oss-rebuild-open-source-a3fe29cc0706

MLA

"Introducing OSS Rebuild: Open Source, Rebuilt to Last." KEVWire, 4 Aug. 2025, kevwire.com/record/google-security-introducing-oss-rebuild-open-source-a3fe29cc0706.

Chicago

KEVWire. "Introducing OSS Rebuild: Open Source, Rebuilt to Last." Last modified August 4, 2025. https://kevwire.com/record/google-security-introducing-oss-rebuild-open-source-a3fe29cc0706.

Evidence summary (plain text)

Introducing OSS Rebuild: Open Source, Rebuilt to Last (Jul 21, 2025).
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. 

 Challenges 

 Open 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 Aim 

 Our aim with OSS Rebuild is to empower the security community to deeply understand
Sources:
Google Security Research: Introducing OSS Rebuild: Open Source, Rebuilt to Last: https://security.googleblog.com/2025/07/introducing-oss-rebuild-open-source.html
Google Security Research syndication feed: https://security.googleblog.com/feeds/posts/default?alt=rss&redirect=false&max-results=50
Record ID: google-security-introducing-oss-rebuild-open-source-a3fe29cc0706.
Record origin: Ingested record.
AI evidence: Not assessed.
About this data

This record was ingested from a data source. Retrieved: Oct 26, 2026, 22:35 UTC. Ingestion is not an independent editorial investigation.

This is an excerpt of official research, not a reproduced result or evidence of exposure to a scored vulnerability.

Technology tags indicate possible relevance, not verified exposure. Confirm the affected product, version, and configuration against your own inventory; KEVWire does not scan your systems.

A personal reading checklist on this device, not verified remediation.

Record JSON

Your account

Email alerts

Email alerts are not available yet. To follow your stack today, use its RSS feed, which honors your filters, or connect an AI agent through the API.

Suggest an improvement

Ideas, missing sources, corrections, and bugs are all welcome. No account needed. Suggestions are reviewed by a person before anything changes.

Record details

Record detail