From 908014761b5af19597c48e2e01c6d6854a50c955 Mon Sep 17 00:00:00 2001 From: Joshua Lock Date: Mon, 5 Jul 2021 15:50:44 +0100 Subject: [PATCH 1/3] Minor tweak to description of event-stream Add word "later" to brief description of event-stream attack to better indicate that the attacker was deliberate and patient. --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 9b84214b6..57b3e3f0a 100644 --- a/README.md +++ b/README.md @@ -67,7 +67,7 @@ example: | B | Compromise source control platform | [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. | C | Build with official process but from code not matching source control | [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. | D | Compromise build platform | [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](requirements.md), making it more difficult to compromise and gain persistence. -| E | Use bad dependency (i.e. A-H, recursively) | [event-stream]: Attacker added an innocuous dependency and then 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. +| E | Use bad 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. | F | Upload an artifact that was not built by the CI/CD system | [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 repository | [Attacks on Package Mirrors]: Researcher ran mirrors for several popular package repositories, 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 | Trick consumer into using bad package | [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. From 073352587f9dbc52ef79e6eda15c1af395ed9167 Mon Sep 17 00:00:00 2001 From: Joshua Lock Date: Mon, 5 Jul 2021 15:52:02 +0100 Subject: [PATCH 2/3] Link directly to build requirements from threat D In the "How SLSA could have helped" column of the row describing threat D "Compromise build platform" instead of linking to the generic requirements document, link directly to the build requirements section. --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 57b3e3f0a..be697ef5e 100644 --- a/README.md +++ b/README.md @@ -66,7 +66,7 @@ example: | A | Submit bad code to the source repository | [Linux hypocrite commits]: Researcher attempted to intentionally introduce vulnerabilities into the Linux kernel via patches on the mailing list. | Two-person review caught most, but not all, of the vulnerabilities. | B | Compromise source control platform | [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. | C | Build with official process but from code not matching source control | [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. -| D | Compromise build platform | [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](requirements.md), making it more difficult to compromise and gain persistence. +| D | Compromise build platform | [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](requirements.md#build-requirements), making it more difficult to compromise and gain persistence. | E | Use bad 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. | F | Upload an artifact that was not built by the CI/CD system | [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 repository | [Attacks on Package Mirrors]: Researcher ran mirrors for several popular package repositories, 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. From 30f09ef86b546c81901167060f9cb6dbd55f2e8a Mon Sep 17 00:00:00 2001 From: Joshua Lock Date: Mon, 5 Jul 2021 15:52:39 +0100 Subject: [PATCH 3/3] Convert terminology table to Markdown --- README.md | 46 +++++++--------------------------------------- 1 file changed, 7 insertions(+), 39 deletions(-) diff --git a/README.md b/README.md index be697ef5e..bcc5ccf0d 100644 --- a/README.md +++ b/README.md @@ -107,45 +107,13 @@ dependencies' supply chains plus its own sources and builds. ![Software Supply Chain Model](images/supply-chain-model.svg) - - - - - - - - - - - - - - - - - -
Term - Description - Example -
Artifact - An immutable blob of data; primarily refers to software, but SLSA can be used for any artifact - A file, a git commit, a directory of files (serialized in some way), a container image, a firmware image. -
Source - Artifact that was directly authored or reviewed by persons, without modification. It is the beginning of the supply chain; we do not trace the provenance back any further. - Git commit (source) hosted on GitHub (platform). -
Build - Process that transforms a set of input artifacts into a set of output artifacts. The inputs may be sources, dependencies, or ephemeral build outputs. - .travis.yml (process) run by Travis CI (platform). -
Package - Artifact that is "published" for use by others. In the model, it is - always the output of a build process, though that build process can be a - no-op. - Docker image (package) distributed on DockerHub (platform). -
Dependency - Artifact that is an input to a build process but that is not a source. In - the model, it is always a package. - Alpine package (package) distributed on Alpine Linux (platform). -
+| Term | Description | Example | +|------|-------------|---------| +| Artifact | An immutable blob of data; primarily refers to software, but SLSA can be used for any artifact. | A file, a git commit, a directory of files (serialized in some way), a container image, a firmware image. | +| Source | Artifact that was directly authored or reviewed by persons, without modification. It is the beginning of the supply chain; we do not trace the provenance back any further. | Git commit (source) hosted on GitHub (platform). | +| Build | Process that transforms a set of input artifacts into a set of output artifacts. The inputs may be sources, dependencies, or ephemeral build outputs. | .travis.yml (process) run by Travis CI (platform). | +| Package | Artifact that is "published" for use by others. In the model, it is always the output of a build process, though that build process can be a no-op. | Docker image (package) distributed on DockerHub (platform). | +| Dependency | Artifact that is an input to a build process but that is not a source. In the model, it is always a package. | Alpine package (package) distributed on Alpine Linux (platform). | Special cases: