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. |
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?
|
|
||
| </details> | ||
|
|
||
| ### Build environment model |
There was a problem hiding this comment.
This section should probably be moved to a separate terminology.md file under /build-env/draft/ because this content wasn't part of the build track 1.0
| | [Build L0] | (none) | (n/a) | ||
| | [Build L1] | Provenance showing how the package was built | Mistakes, documentation | ||
| | [Build L2] | Signed provenance, generated by a hosted build platform | Tampering after the build | ||
| | [Build L3] | Hardened build platform | Tampering during the build |
There was a problem hiding this comment.
It looks like the links to the individual levels for this and the other tracks are missing. I think it may actually be ok to remove these links from this page since the actual track specs are referenced below each table.
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.