Supply chain threats

Attacks can occur at every link in a typical software supply chain, and these kinds of attacks are increasingly public, disruptive, and costly in today’s environment.

This page is an introduction to possible attacks throughout the supply chain and how SLSA could help. For a more technical discussion, see Threats & mitigations.

Summary

Note that SLSA does not currently address all of the threats presented here. See Threats & mitigations for what is currently addressed and Terminology for an explanation of the supply chain model.

SLSA’s primary focus is supply chain integrity, with a secondary focus on availability. Integrity means protection against tampering or unauthorized modification at any stage of the software lifecycle. Within SLSA, we divide integrity into source integrity vs build integrity.

Source integrity: Ensure that source revisions contain only changes submitted by authorized contributors according to the process defined by the software producer and that source revisions are not modified as they pass between development stages.

Build integrity: Ensure that the package is built from the correct, unmodified sources and dependencies according to the build recipe defined by the software producer, and that artifacts are not modified as they pass between development stages.

Availability: Ensure that the package can continue to be built and maintained in the future, and that all code and change history is available for investigations and incident response.

Real-world examples

Many recent high-profile attacks were consequences of supply chain integrity vulnerabilities, and could have been prevented by SLSA’s framework. For example:

	Threats from	Known example	How SLSA could help
A	Producer	SpySheriff: Software producer purports to offer anti-spyware software, but that software is actually malicious.	SLSA does not directly address this threat but could make it easier to discover malicious behavior in open source software, by forcing it into the publicly available source code. For close source software SLSA does not provide any solutions for malicious producers.
B	Authoring & reviewing	SushiSwap: Contractor with repository access pushed a malicious commit redirecting cryptocurrency to themself.	Two-person review could have caught the unauthorized change.
C	Source code management	PHP: Attacker compromised PHP's self-hosted git server and injected two malicious commits.	A better-protected source code system would have been a much harder target for the attackers.
D	External build parameters	The Great Suspender: Attacker published software that was not built from the purported sources.	A SLSA-compliant build server would have produced provenance identifying the actual sources used, allowing consumers to detect such tampering.
E	Build process	SolarWinds: Attacker compromised the build platform and installed an implant that injected malicious behavior during each build.	Higher SLSA levels require stronger security controls for the build platform, making it more difficult to compromise and gain persistence.
F	Artifact publication	CodeCov: Attacker used leaked credentials to upload a malicious artifact to a GCS bucket, from which users download directly.	Provenance of the artifact in the GCS bucket would have shown that the artifact was not built in the expected manner from the expected source repo.
G	Distribution channel	Attacks on Package Mirrors: Researcher ran mirrors for several popular package registries, which could have been used to serve malicious packages.	Similar to above (F), provenance of the malicious artifacts would have shown that they were not built as expected or from the expected source repo.
H	Package selection	Browserify typosquatting: Attacker uploaded a malicious package with a similar name as the original.	SLSA does not directly address this threat, but provenance linking back to source control can enable and enhance other solutions.
I	Usage	Default credentials: Attacker could leverage default credentials to access sensitive data.	SLSA does not address this threat.
N/A	Dependency threats (i.e. A-H, recursively)	event-stream: Attacker added an innocuous dependency and then later updated the dependency to add malicious behavior. The update did not match the code submitted to GitHub (i.e. attack F).	Applying SLSA recursively to all dependencies would prevent this particular vector, because the provenance would indicate that it either wasn't built from a proper builder or that the source did not come from GitHub.

	Availability threat	Known example	How SLSA could help
N/A	Dependency becomes unavailable	Mimemagic: Producer intentionally removes package or version of package from repository with no warning. Network errors or service outages may also make packages unavailable temporarily.	SLSA does not directly address this threat.

A SLSA level helps give consumers confidence that software has not been tampered with and can be securely traced back to source—something that is difficult, if not impossible, to do with most software today.