| A
- | Submit unauthorized change (to source repo)
- | SushiSwap: Contractor with repository access pushed a malicious commit redirecting cryptocurrency to themself.
- | Two-person review could have caught the unauthorized change.
+ | 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
- | Compromise source repo
- | PHP: Attacker compromised PHP's self-hosted git server and injected two malicious commits.
- | A better-protected source code platform would have been a much harder target for the attackers.
+ | 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
- | Build from modified source (not matching source repo)
- | Webmin: Attacker modified the build infrastructure to use source files not matching source control.
- | A SLSA-compliant build server would have produced provenance identifying the actual sources used, allowing consumers to detect such tampering.
+ | 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
- | Use compromised dependency (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 have prevented this particular vector, because the provenance would have indicated that it either wasn't built from a proper builder or that the source did not come from GitHub.
+ | 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
- | Compromise build process
+ | 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
- | Upload modified package (not matching build process)
+ | 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
- | Compromise package registry
+ | 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
- | Use compromised package
+ | 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.
@@ -100,7 +111,7 @@ Many recent high-profile attacks were consequences of supply chain integrity vul
| How SLSA could help
|
-| D
+ | 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.
| |