Enhance security guidelines for software supply chain#387
Enhance security guidelines for software supply chain#387JustinCappos wants to merge 2 commits intoossf:mainfrom
Conversation
Signed-off-by: Justin Cappos <justincappos@gmail.com>
funnelfiasco
left a comment
There was a problem hiding this comment.
I like the general direction. I think we need more clarity (and also feedback from others, of course)
| - id: OSPS-SA-04.01 | ||
| text: | | ||
| A project MUST perform a security assessment of the software | ||
| supply chain security practices of the project. This should |
There was a problem hiding this comment.
| supply chain security practices of the project. This should | |
| supply chain security practices of the project to |
If we don't introduce new instances of "should" in the title or text fields, I won't have to go back and remove them when I get around to doing that. :-)
|
|
||
| - id: OSPS-SA-04 | ||
| title: | | ||
| The project MUST assess the security risks inherent in their software supply chain practices. |
There was a problem hiding this comment.
This might need some wordsmithing to be a little more clear, but I wouldn't block on this if we can't think of anything.
There was a problem hiding this comment.
Are there projects that are doing this well, doing this poorly today? What does good enough look like?
| - Maturity Level 2 | ||
| - Maturity Level 3 | ||
| recommendation: | | ||
| Performing a security assessment informs both project members as well |
There was a problem hiding this comment.
This is a place where we'll really want some reference implementations to direct people to.
| practices. Ensure this is updated as practices change. | ||
|
|
||
| - id: OSPS-SA-04.02 | ||
| text: | |
There was a problem hiding this comment.
I'm not clear on what distinction you're drawing between 04.01 and 04.02. It seems like some of 04.02 is duplicative, and if so, we can drop that. Is the idea that 04.02 says "do what you did for 04.01, but also include your dependencies in it"?
The text should also be shorter here, ideally 1-2 sentences, and we can expand in the recommendation if needed.
There was a problem hiding this comment.
I also mean to look at your tooling. Are you using appropriate VCS controls? Are you generating attestations? Is your software update infrastructure compromise-resilient? Do you have a recovery plan for a compromise in these areas?
|
|
||
| - id: OSPS-SA-04 | ||
| title: | | ||
| The project MUST assess the security risks inherent in their software supply chain practices. |
There was a problem hiding this comment.
Are there projects that are doing this well, doing this poorly today? What does good enough look like?
| title: | | ||
| The project MUST assess the security risks inherent in their software supply chain practices. | ||
| objective: | | ||
| Provide project maintainers an understanding of the risks in their software |
There was a problem hiding this comment.
Is this "tooling" specific or should that be removed?
| that could occur in the supply chain of the software, including | ||
| both the tool. |
There was a problem hiding this comment.
What is "including both the tool."?
| text: | | ||
| When the project has made a release, the project MUST perform a | ||
| security assessment of their software supply chain practices and | ||
| have analyzed their dependencies. This should also include means |
There was a problem hiding this comment.
Dependency management should be effective covered by existing controls.
| applicability: | ||
| - Maturity Level 3 | ||
| recommendation: | | ||
| Threat modeling of the software supply chain is an essential part |
There was a problem hiding this comment.
Are there existing examples of open source projects doing this well?
This PR which needs community feedback and also needs a more precise linking to the specific standards which apply.