Open Source Supply Chain Security: Protecting Your Pipeline from Malicious Packages

The Supply Chain Threat Has Changed

The traditional model of software supply chain risk was about vulnerable dependencies: a CVE in a library you use transitively. That risk is real and well-understood. But the threat landscape has expanded. The XZ Utils backdoor (CVE-2024-3094), the event-stream npm compromise, the PyPI malware campaigns, and a dozen similar incidents since 2020 demonstrate a different and in some ways more dangerous attack category: malicious code inserted into packages that pass all conventional security reviews because the malice is in the logic, not a known CVE.

Attack Pattern Taxonomy

Typosquatting

Typosquatting attacks register package names that closely resemble popular packages — reqeusts instead of requests, colourama instead of colorama — and publish malicious payloads under those names. Developers who mistype a package name or copy an install command with a typo install the malicious version. PyPI and npm have been the primary targets; automated detection and removal has improved significantly but remains reactive.

Maintainer Account Compromise

If an attacker compromises the npm, PyPI, or RubyGems account of a popular package maintainer, they can publish a new malicious version that distributes to all downstream consumers. This attack was demonstrated with the ua-parser-js npm package in 2021, where a hijacked account was used to publish three malicious versions that installed cryptocurrency miners and credential stealers on developer machines. The package had 8 million weekly downloads.

Build System Injection

The XZ Utils backdoor represented the most sophisticated public example of this category: a multi-year social engineering campaign targeting the project's maintainer, ultimately resulting in the injection of a backdoor into the build system that affected the SSH daemon on systems using the compromised liblzma library. The attack was caught only by a performance anomaly noticed by a Microsoft engineer. Build system injection attacks are difficult to detect because the malicious code is not in the repository's primary codebase but in the tooling used to build it.

Defence Controls That Work

Lockfile Integrity

Package lockfiles (package-lock.json, yarn.lock, Pipfile.lock, Cargo.lock) pin the exact version and integrity hash of every dependency. Enforcing lockfile presence and verifying that CI installs match the lockfile prevents opportunistic version substitution. Any CI pipeline that runs npm install without --frozen-lockfile or pip install without hash verification is operating without this control.

SLSA Build Provenance

Supply chain Levels for Software Artifacts (SLSA) is a framework for expressing and verifying build provenance. SLSA level 2 requires that build provenance is generated by a hosted build system and that the provenance is signed. Level 3 adds requirements on the build system itself (non-falsifiable provenance, isolated builds). Publishing and verifying SLSA provenance for internal artifacts provides a cryptographic chain of custody from source code to deployed binary.

Sigstore and Cosign

Sigstore provides keyless signing infrastructure for open source artifacts. cosign can sign and verify container images and other artifacts against the Rekor transparency log, which provides an immutable audit trail of what was signed, when, and by what identity. OSSeva signs all patch builds with cosign against the OSSeva signing identity, providing a verifiable chain from the patched source to the delivered binary.

Dependency Review in CI

GitHub's dependency-review-action, and equivalent tooling for GitLab and other platforms, provides a diff of dependency changes on every pull request, highlighting new dependencies, version changes, and newly introduced license or vulnerability issues. This creates a review gate at the point of introduction — where the cost of catching a bad dependency is lowest.

OSSeva's Supply Chain Controls

OSSeva's patched builds are delivered with full supply chain provenance: SLSA level 2 build attestations, cosign signatures, SBOM in CycloneDX format, and SHA-256 checksums for all artifacts. Customers can independently verify the integrity of every artifact they receive before deployment.

Conclusion

Open source supply chain security has become a first-class engineering discipline. The controls — lockfiles, provenance attestations, code signing, and dependency review — are mature and available. The gap is implementation consistency: ensuring that these controls are applied uniformly across all build pipelines, not just the highest-visibility products. That consistency is where most enterprise supply chain programs still have work to do.