nonspec: Split Tracks out of the Draft specification into separate specs #1280
Conversation
Turn the build, build environment, and source track sections into separate specifications. Change the Draft specification to only hold general content and a highlevel description of the tracks with pointers to the individual specs. Signed-off-by: Arnaud J Le Hors <[email protected]>
Signed-off-by: Arnaud J Le Hors <[email protected]>
✅ Deploy Preview for slsa ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
lehors
changed the title
Signed-off-by: Arnaud J Le Hors <[email protected]>
Signed-off-by: Arnaud J Le Hors <[email protected]>
Signed-off-by: Arnaud J Le Hors <[email protected]>
Signed-off-by: Arnaud J Le Hors <[email protected]>
|
For the record: I think this works pretty well but I am struggling with the terminology section. Most of its current content is build related so I moved it into the Build track spec but I actually think that's too radical. The right thing might be to have a global terminology section that stays with the (main) draft spec and can be referenced from the different track specs. Then each track spec can have its own specialized terminology section that extends the main one with terms specific to that track. |
docs/_data/nav/main.yml
Outdated
| url: /build/v1.0/verifying-systems | ||
| description: Guidelines for securing SLSA Build L3+ builders, intended for platform implementers | ||
|
|
||
| - title: SLSA Source WD |
There was a problem hiding this comment.
Looking at the navigation menu, it's not immediately clear that this and the other tracks are "tracks". I'm wondering if these menu items could be renamed to something like "Track: Source WD" or simply "Source Track WD" to be very explicit. I also don't know if "WD" will be clear to everyone, but I do agree that we need something short.
There was a problem hiding this comment.
I agree. Have a look at the latest update. Let me know what you think.
Thanks.
Signed-off-by: Arnaud J Le Hors <[email protected]>
| @@ -74,7 +74,7 @@ For close source software SLSA does not provide any solutions for malicious prod | |||
| <td>E | |||
| <td>Build process | |||
| <td><a href="https://www.crowdstrike.com/blog/sunspot-malware-technical-analysis/">SolarWinds</a>: Attacker compromised the build platform and installed an implant that injected malicious behavior during each build. | |||
| <td>Higher SLSA levels require <a href="requirements#build-requirements">stronger security controls for the build platform</a>, making it more difficult to compromise and gain persistence. | |||
| <td>Higher SLSA levels require <a href="../../build/v1.0/requirements">stronger security controls for the build platform</a>, making it more difficult to compromise and gain persistence. | |||
There was a problem hiding this comment.
@lehors How would we manage threat modeling in this new design? With new tracks coming into SLSA spec I see people taking two approaches:
Sourcetrack proposes to amend existing documentBuildEnvironmenttrack proposes to put threats into a separate document
Looking at this chage I think you adopt the first path with core specification defining the threats across all tracks. And then BuildEnvironment threat PR needs to be updated moving all the changes into threats.md.
How does it sound?
Turn the build, build environment, and source track sections into separate specifications.
Change the Draft specification to only hold general content and a highlevel description of the tracks with pointers to the individual specs.