Commit 03699118 authored by Mark Lodato's avatar Mark Lodato
Browse files

Remove Resource and Deploy to simplify the model.

Previously, we differentiated between Resources and Artifacts, and SLSA
was a property of a Resource's security policy. However, many readers
found this concept very confusing.

Now, SLSA is purely a property of the artifact. If provenance exists
showing that it met the requirements, the artifact meets the level. No
policy or notion of "resource" is required. This simplifies the model at
some cost of security, which we have collectively decided is worth the
trade-off.

NOTE: The Vision section will be updated in a future change.
parent 9873d440
...@@ -108,8 +108,8 @@ significant manual effort, guesswork, and blind trust. Working backwards: ...@@ -108,8 +108,8 @@ significant manual effort, guesswork, and blind trust. Working backwards:
* It claims to have come from a Dockerfile in the * It claims to have come from a Dockerfile in the
[curl/curl-docker](https://github.com/curl/curl-docker/blob/d6525c840a62b398424a78d792f457477135d0cf/alpine/latest/Dockerfile) [curl/curl-docker](https://github.com/curl/curl-docker/blob/d6525c840a62b398424a78d792f457477135d0cf/alpine/latest/Dockerfile)
GitHub repository. GitHub repository.
* That Dockerfile reads from the following resources, assuming there are no * That Dockerfile reads the following artifacts, assuming there are no further
further fetches during build time: fetches during build time:
* Docker Hub image: * Docker Hub image:
[registry.hub.docker.com/library/alpine:3.11.5](https://hub.docker.com/layers/alpine/library/alpine/3.11.5/images/sha256-cb8a924afdf0229ef7515d9e5b3024e23b3eb03ddbba287f4a19c6ac90b8d221?context=explore) [registry.hub.docker.com/library/alpine:3.11.5](https://hub.docker.com/layers/alpine/library/alpine/3.11.5/images/sha256-cb8a924afdf0229ef7515d9e5b3024e23b3eb03ddbba287f4a19c6ac90b8d221?context=explore)
* Alpine packages: libssh2 libssh2-dev libssh2-static autoconf automake * Alpine packages: libssh2 libssh2-dev libssh2-static autoconf automake
...@@ -157,7 +157,7 @@ are confirmed.) ...@@ -157,7 +157,7 @@ are confirmed.)
* Attack any of the systems involved in the supply chain, as in the * Attack any of the systems involved in the supply chain, as in the
[SolarWinds attack](https://www.crowdstrike.com/blog/sunspot-malware-technical-analysis/). [SolarWinds attack](https://www.crowdstrike.com/blog/sunspot-malware-technical-analysis/).
SLSA intends to cover all of these threats. When all resources in the supply SLSA intends to cover all of these threats. When all artifacts in the supply
chain have a sufficient SLSA level, consumers can gain confidence that most of chain have a sufficient SLSA level, consumers can gain confidence that most of
these attacks are mitigated, first via self-certification and eventually through these attacks are mitigated, first via self-certification and eventually through
automated verification. automated verification.
...@@ -209,7 +209,7 @@ satisfy all of the SLSA build requirements. ...@@ -209,7 +209,7 @@ satisfy all of the SLSA build requirements.
That said, verified reproducible builds are not a complete solution to supply That said, verified reproducible builds are not a complete solution to supply
chain integrity, nor are they practical in all cases: chain integrity, nor are they practical in all cases:
* Reproducible builds do not address source, dependency, or deployment * Reproducible builds do not address source, dependency, or distribution
threats. threats.
* Reproducers must truly be independent, lest they all be susceptible to the * Reproducers must truly be independent, lest they all be susceptible to the
same attack. For example, if all rebuilders run the same pipeline software, same attack. For example, if all rebuilders run the same pipeline software,
...@@ -230,61 +230,63 @@ For more on reproducibility, see ...@@ -230,61 +230,63 @@ For more on reproducibility, see
## Terminology ## Terminology
A **resource** is what we are trying to protect: a uniquely identifiable thing An **artifact** is an immutable blob of data. Example artifacts: a file, a git
that can be associated with a software artifact. It is often the way that a commit, a directory of files (serialized in some way), a container image, a
consumer retrieves, uses, or verifies the software. An **artifact** is a raw firmware image. The primary use case is for _software_ artifacts, but SLSA can
blob of data, such as a file or a configuration value, identified by its be used for any type of artifact.
contents.
A **software supply chain** is a sequence of steps resulting in the assignment A **software supply chain** is a sequence of steps resulting in the creation of
of an artifact to a resource. We represent a supply chain as a an artifact. We represent a supply chain as a
[directed acyclic graph](https://en.wikipedia.org/wiki/Directed_acyclic_graph) [directed acyclic graph](https://en.wikipedia.org/wiki/Directed_acyclic_graph)
of sources, builds, dependencies, and deployments. A resource's supply chain is of sources, builds, dependencies, and packages. Furthermore, each source, build,
a combination of its dependencies' supply chains plus its own sources, builds, and package may be hosted on a platform, such as Source Code Management (SCM) or
and deployment. Continuous Integration / Continuous Deployment (CI/CD). Note that one artifact's
supply chain is a combination of its dependencies' supply chains plus its own
sources and builds.
The following diagram shows the relationship between concepts. The following diagram shows the relationship between concepts.
![supply-chain](images/supply-chain.svg) ![Software Supply Chain Model](images/supply-chain-model.svg)
<table> <table>
<thead> <thead>
<tr> <tr>
<th>Term <th>Term
<th>Description <th>Description
<th>Examples <th>Example
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<th>Source <th>Source
<td>Resource containing only artifacts authored or reviewed by persons. It is the beginning of the supply chain; we do not trace the provenance back any further. <td>Artifact that was directly authored or directly by persons, without modification. It is the beginning of the supply chain; we do not trace the provenance back any further.
<td>Git repository. <td>Git commit (source) hosted on GitHub (platform).
</tr> </tr>
<tr>
<th>Dependency
<td>Resource that either is "imported" software or does not meet the definition of source.
<td>Debian package.<br>
Container base image.<br>
Library git repository.<br>
Firmware image.
</tr>
<tr>
<th>Build <th>Build
<td>Process that transforms a set of input artifacts into a set of output artifacts. The inputs may be sources, dependencies, or ephemeral build outputs. <td>Process that transforms a set of input artifacts into a set of output artifacts. The inputs may be sources, dependencies, or ephemeral build outputs.
<td>Compiling a binary.<br> <td>.travis.yml (process) run by Travis CI (platform).
Creating a zip archive.<br> </tr>
Building a docker image. <tr>
<th>Package
<td>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.
<td>Docker image (package) distributed on DockerHub (platform).
</tr> </tr>
<tr> <tr>
<th>Deployment <th>Dependency
<td>Process that associates an artifact with a resource, granting the artifact special privilege. <td>Artifact that is an input to a build process but that is not a source. In
<td>Uploading an image to a container registry.<br> the model, it is always a package.
Code signing a mobile app. <td>Alpine package (package) distributed on Alpine Linux (platform).
</tr> </tr>
</tbody> </tbody>
</table> </table>
Special cases:
* A ZIP file is containing source code is package, not a source, because it is
built from some other source, such as a git commit.
## Proposed SLSA definitions ## Proposed SLSA definitions
_Reminder: The definitions below are not yet finalized and subject to change. In _Reminder: The definitions below are not yet finalized and subject to change. In
...@@ -348,10 +350,6 @@ Each SLSA level has a set of requirements. ...@@ -348,10 +350,6 @@ Each SLSA level has a set of requirements.
<tr><td>Service Generated <td> <td><td><td></tr> <tr><td>Service Generated <td> <td><td><td></tr>
<tr><td>Non-Falsifiable <td> <td> <td><td></tr> <tr><td>Non-Falsifiable <td> <td> <td><td></tr>
<tr><td>Dependencies <td> <td> <td> <td></tr> <tr><td>Dependencies <td> <td> <td> <td></tr>
<tr><td rowspan="3">Deploy
<td>Provenance Chain <td><td><td><td></tr>
<tr><td>Policy <td> <td><td><td></tr>
<tr><td>Logging <td> <td> <td><td></tr>
<tr><td rowspan="3">Common <tr><td rowspan="3">Common
<td>Security <td> <td> <td><td></tr> <td>Security <td> <td> <td><td></tr>
<tr><td>Access <td> <td> <td><td></tr> <tr><td>Access <td> <td> <td><td></tr>
...@@ -416,18 +414,8 @@ nuanced. We only provide a brief summary here for clarity. ...@@ -416,18 +414,8 @@ nuanced. We only provide a brief summary here for clarity.
artifact that was available to the build script. This includes the initial artifact that was available to the build script. This includes the initial
state of the machine, VM, or container of the build worker. state of the machine, VM, or container of the build worker.
**[Deploy]** An artifact deployed to a resource meets SLSA 3 if:
* **[Provenance Chain]** There is an unbroken chain of provenance linking the
artifact back to its original sources and dependencies.
* **[Policy]** The resource's security policy only accepts artifacts with
provenance by specific builders and specific top-level source repositories.
The policy itself is a SLSA 3 source.
* **[Logging]** The history of deployed artifacts and their provenances is
retained for 18 months and is resistant to tampering.
**[Common]** In addition to the requirements above, every trusted system **[Common]** In addition to the requirements above, every trusted system
involved in the supply chain (source, build, deploy, etc.) must meet the involved in the supply chain (source, build, distribution, etc.) must meet the
following requirements: following requirements:
* **[Security]** The system meets some TBD baseline security standard to * **[Security]** The system meets some TBD baseline security standard to
...@@ -443,16 +431,16 @@ following requirements: ...@@ -443,16 +431,16 @@ following requirements:
## Scope of SLSA ## Scope of SLSA
SLSA applies to a single resource and is not transitive. It describes the SLSA is not transitive. It describes the integrity protections of an artifact's
security strength of the resource's own sources, build processes, and deploy build process and top-level source, but nothing about the artifact's
processes. Dependencies have their own SLSA ratings, and it is possible for a dependencies. Dependencies have their own SLSA ratings, and it is possible for a
SLSA 3 resource to be built from SLSA 0 dependencies. SLSA 3 artifact to be built from SLSA 0 dependencies.
The reason for non-transitivity is to make the problem tractable. If SLSA 3 The reason for non-transitivity is to make the problem tractable. If SLSA 3
required dependencies to be SLSA 3, then reaching SLSA 3 would require starting required dependencies to be SLSA 3, then reaching SLSA 3 would require starting
at the very beginning of the supply chain and working forward. This is at the very beginning of the supply chain and working forward. This is
backwards, forcing us to work on the least risky component first and blocking backwards, forcing us to work on the least risky component first and blocking
any progress further downstream. By making each resource's SLSA rating any progress further downstream. By making each artifact's SLSA rating
independent from one another, it allows parallel progress and prioritization independent from one another, it allows parallel progress and prioritization
based on risk. (This is a lesson we learned when deploying other security based on risk. (This is a lesson we learned when deploying other security
controls at scale throughout Google.) controls at scale throughout Google.)
...@@ -478,7 +466,7 @@ Initially the Docker image is SLSA 0. There is no provenance and no policy. It ...@@ -478,7 +466,7 @@ Initially the Docker image is SLSA 0. There is no provenance and no policy. It
is difficult to determine who built the artifact and what sources and is difficult to determine who built the artifact and what sources and
dependencies were used. dependencies were used.
The diagram shows that the (mutable) resource `curlimages/curl:7.72.0` points to The diagram shows that the (mutable) locator `curlimages/curl:7.72.0` points to
(immutable) artifact `sha256:3c3ff…`. (immutable) artifact `sha256:3c3ff…`.
#### SLSA 1: Provenance #### SLSA 1: Provenance
...@@ -554,9 +542,9 @@ heuristics. ...@@ -554,9 +542,9 @@ heuristics.
### Composition of SLSA levels ### Composition of SLSA levels
A resource's SLSA level is not transitive, so some aggregate measure of security An artifact's SLSA level is not transitive, so some aggregate measure of security
risk across the whole supply chain is necessary. In other words, each node in risk across the whole supply chain is necessary. In other words, each node in
our graph has its own, independent SLSA level. Just because a resource's level our graph has its own, independent SLSA level. Just because an artifact's level
is N does not imply anything about its dependencies' levels. is N does not imply anything about its dependencies' levels.
In our example, suppose that the final [curlimages/curl] Docker image were SLSA In our example, suppose that the final [curlimages/curl] Docker image were SLSA
...@@ -573,6 +561,9 @@ easier. ...@@ -573,6 +561,9 @@ easier.
### Deployment policies ### Deployment policies
**TODO: Update this section now that policies/resources have been
de-emphasized.**
Another major component of SLSA is enforcement of security policies based on Another major component of SLSA is enforcement of security policies based on
provenance. Without policy enforcement, there is no guarantee that future provenance. Without policy enforcement, there is no guarantee that future
revisions will not regress. revisions will not regress.
...@@ -628,8 +619,8 @@ out: ...@@ -628,8 +619,8 @@ out:
* Agree on the principles, terminology, and high-level strategy. * Agree on the principles, terminology, and high-level strategy.
* Define a threat model describing specific threats we intend to address. * Define a threat model describing specific threats we intend to address.
* Specify detailed requirements for Source, Build, Deploy, and Common to meet * Specify detailed requirements for Source, Build, Provenance, and Common to
those principles. meet those principles.
* Agree on a leveling system. * Agree on a leveling system.
* Document more end-to-end examples to show real threats and mitigations. * Document more end-to-end examples to show real threats and mitigations.
* Examples showing how to use common platforms to achieve SLSA (or an * Examples showing how to use common platforms to achieve SLSA (or an
......
This diff is collapsed.
This diff is collapsed.
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment