search

slsa-framework / slsa

Supply-chain Levels for Software Artifacts
https://slsa.dev
Other
1.53k stars 221 forks source link

SLSA v1: Explain that you must define a security model for your build system #706

Open MarkLodato opened 1 year ago

MarkLodato commented 1 year ago

The spec should (somewhere) explain that the build system implementer must define a security model for the build system, with clear boundaries, actors, and interfaces. This will then inform how to fix the system and implement provenance. Maybe on the provenance page?

Related discussion: https://github.com/slsa-framework/slsa/pull/700#discussion_r1142073167

/cc @arewm

arewm commented 1 year ago

In order to have a reasonable guarantee about the authenticity of the provenance (i.e. L3), all build activity needs to happen within the trust boundary and the threat model needs to ensure that appropriate mitigations have been made with all entities outside the trust boundary (as needed).

arewm commented 1 year ago

I started to fix this in #810 but then the PR exploded to unify on platform. In the PR, however, I did call out whether the wording that I added should also be added to system verification.

Does this MUST mean that we should add this to verifying-systems? [ref]

MarkLodato commented 1 year ago

Does this MUST mean that we should add this to verifying-systems? [ref]

Yeah, I think so, now that you say it. This is similar https://github.com/slsa-framework/slsa/pull/789#discussion_r1156334736 by @lehors. I think his argument was that all requirements on the build platform should be in requirements.md.

arewm commented 1 year ago

Should the change then be to include the MUST wording and to include it in verifying systems or to change it to SHOULD (and still include it in verifying systems)?

MarkLodato commented 1 year ago

I lean towards SHOULD.

MUST means that a build platform failing to define such a security model cannot be considered SLSA conformant. But this seems more like guidelines than a strict requirement. Could there be a situation where a build platform does not do this and yet one would still consider it SLSA conformant? I imagine so. Also if we make it a MUST, we'd probably need guidelines on how to verify it.

arewm commented 1 year ago

SHOULD + noting in verifying systems or without the note?

I support having it as a SHOULD as it is a best practice and can be used to inform other aspects of the specification. The ideas that I have about when this might not be needed seem to revolve around simpler systems that can make determinations like this without any formal modeling.

MarkLodato commented 1 year ago

I'd say in two or three places:

arewm commented 1 year ago

Provenance: Maybe as a new subsection under Model talking about the platform implementer carefully thinking about the security model and defining trust boundaries? I worry about adding yet another bullet to the main list of Model, since it's already long.

This is where I had proposed adding it as a sub-bullet (direct link to commit change). My rationale was that it was relevant information to defining the system's builder.id(s).

Producing Artifacts: Seems like we should have something here as well, since we talk about "trusted control plane" and "external parameters" in this doc. Maybe a brief paragraph under Provenance is Authentic after the first paragraph of Accuracy?

I see what you are saying, but I think it would add a lot of additional content here for minimal benefit. We are already directing readers to the provenance page by saying "(i.e. within the trust boundary identified in the provenance)" so I think it is reasonable to just leave the definition to the provenance page. We also don't talk about the control plane in the Authentic section -- that isn't referred to until Unforgeable.

Verifying Systems: Optionally update the language of Build system components to mention the security model?

I like this as well. We tell readers to identify the components, but we can also tell them to use the security model to understand risk/assign trustedness to various components.

MarkLodato commented 1 year ago

This is where I had proposed adding it as a sub-bullet

I don't feel strongly. Let's try it where you had it and see what it looks like? I just worry about hitting the user with too much detail up front.

I see what you are saying, but I think it would add a lot of additional content here for minimal benefit.

Makes sense. I'm fine with omitting it from requirements.md.

arewm commented 1 year ago

PR #816 is up for review.