content: Threat model for the BuildEnv track (take 2) #1479
Conversation
✅ Deploy Preview for slsa ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
marcelamelara
changed the title
|
marcelamelara
left a comment
marcelamelara
left a comment
There was a problem hiding this comment.
Thanks @paveliak ! I mostly have nitpicky/clarifying changes actually, though I think there's still an open question about the BuildEnv L3 threat and whether it should be two separate threats or just one.
Co-authored-by: Marcela Melara <[email protected]> Signed-off-by: Pavel Iakovenko <[email protected]>
Co-authored-by: Marcela Melara <[email protected]> Signed-off-by: Pavel Iakovenko <[email protected]>
Co-authored-by: Marcela Melara <[email protected]> Signed-off-by: Pavel Iakovenko <[email protected]>
Co-authored-by: Marcela Melara <[email protected]> Signed-off-by: Pavel Iakovenko <[email protected]>
Co-authored-by: Marcela Melara <[email protected]> Signed-off-by: Pavel Iakovenko <[email protected]>
Co-authored-by: Marcela Melara <[email protected]> Signed-off-by: Pavel Iakovenko <[email protected]>
Co-authored-by: Marcela Melara <[email protected]> Signed-off-by: Pavel Iakovenko <[email protected]>
Co-authored-by: Marcela Melara <[email protected]> Signed-off-by: Pavel Iakovenko <[email protected]>
Co-authored-by: Marcela Melara <[email protected]> Signed-off-by: Pavel Iakovenko <[email protected]>
| Trustworthiness of the build process largely depends on the trustworthiness of the [build environment] the build runs in. | ||
| The Build track assumes full trust into the [Build Platform], and provides no requirements to verify integrity of the build environment. | ||
| BuildEnv track intends to close this gap. |
There was a problem hiding this comment.
Is this an accurate representation? Is it that the trustworthiness depends on the build environment or is it that intentional and recordable mitigation of build environment threats can provide further assurances for the build provenance? It seems reasonable that a consumer may trust the entity running the build platform, but it also seems reasonable that a different consumer may not want to trust that same entity.
Should this be worded in terms of the build process generically or the build provenance specifically?
There was a problem hiding this comment.
@arewm This might be a good continuation for #1479 (comment)
Initially I had "build provenance" in this text and later changed it to the "build process" (see the linked discussion) 😁 What I would like to convey in this text is that trustworthiness of build artifacts (as captured by the build provenance) depends on the trustworthiness of the build environment. Would that be a better wording?
There was a problem hiding this comment.
I'm going to try to fold this into the PR for #1520 , but may decide to do this separately.
| 4. *Build execution*: Finally, the build agent within the environment executes | ||
| the tenant's build definition. | ||
|
|
||
| ### Build environment threats |
There was a problem hiding this comment.
The wording of this section feels odd. We are inconsistent with leading articles like "the," for example. Are these meant to just inform the information in the mermaid chart? If so, should the chart be before the text?
|
|
||
| BuildEnv track assumes full trust in the software that comes with the build image or is installed at runtime. | ||
| Malicious software having privileged access within the build environment might be able to circumvent protections provided by the BuildEnv track. | ||
| Image providers should manage vulnerabilities in the image components to reduce the risks of such attacks, e.g. by using SLSA Dependency track and hardening images with mandatory access control (MAC) policies. |
There was a problem hiding this comment.
Is this something that needs to be included here? It falls into the broader cross-track workflows.
There was a problem hiding this comment.
I am Ok with removing the e.g section. I do think it is important to mention that vulnerabilities in the image tools and dependencies are out of scope in the BuildEnv track. In fact BuildEnv track relies on the kernel security mechanisms and if build is running with "sudo" and image vulnerabilities get exploited then "all bets are off"
| Build environment is bootstrapped from a [build image], which is expected to be an artifact of a SLSA build pipeline. | ||
| Build platform verifies image security properties including provenance upon starting up the environment and makes evidence of the verification available to tenants or other auditors. | ||
|
|
||
| BuildEnv track assumes full trust in the software that comes with the build image or is installed at runtime. |
There was a problem hiding this comment.
This feels odd to me -- switching between talking about the BuildEnv track and the different entities in the process. Should there be headings or sections in here somewhere?
| Bootstrapping the build environment is a complex process, especially at higher SLSA levels. | ||
| [Build L3] usually requires significant changes to existing build platforms to maintain ephemeral build environments. | ||
| It is not uncommon for the build platforms to rely on public cloud providers to manage the compute resources that power build environments. | ||
| This in turn significantly expands the attack surface because added build platform dependencies become part of the [TCB]. | ||
| Cloud providers are big companies with complex infrastructure that often provide limited abilities to scope the context of trust and continuously validate it over time when using their services. |
There was a problem hiding this comment.
Should this be separated as the two threats -- bootstrapping and cloud providers -- are not closely related?
There was a problem hiding this comment.
They are. Bootstrapping is L2, cloud providers (which is a common case of an external compute platform) is L3. Bootstrapping may not be a good wording here. This paragraph tries to convey the complexity of operating a compute platform that provides ephemeral build environments.
| <div class="mermaid"> | ||
| flowchart LR | ||
| BuildImage>Build Image] ---> |L1|BuildPlatform[[Build Platform]] | ||
| BuildPlatform[[Build Platform]] ---> |L2|ComputeProvider[[Compute Provider]] | ||
| ComputeProvider[[Compute Provider]] ---> |L3|BuildEnvironment[(Build Environment)] | ||
| </div> |
There was a problem hiding this comment.
I don't know what @MarkLodato has used for graphics in the past, but this renders as something that is starkly different from the rest of them.
Including mermaid is nice because it makes maintenance of the diagrams easier. Is there any way that we can be more consistent though?
There was a problem hiding this comment.
There was a problem hiding this comment.
Sounds good. I will convert those to Figma. I do like diagrams as code though 😁
Signed-off-by: Marcela Melara <[email protected]>
marcelamelara
left a comment
marcelamelara
left a comment
There was a problem hiding this comment.
I think this is a good first iteration on the BuildEnv threat model. We'll continue refining this text in a subsequent PR.
7 participants
This is an alternative PR for the #1267
For the most part it reiterates threats expressed in the original PR but it takes an effort to group threats differently into these classes:
L1levelL2L3We think that such an alignment provides a better mental model for BuildEnv track levels and gives users a clear picture of what kind of threats are expected to be mitigated if certain BuidlEnv level is implemented by a Build Platform.
CC @marcelamelara