feat: Update titles & objectives for brevity and consistency#456
feat: Update titles & objectives for brevity and consistency#456eddie-knight wants to merge 2 commits intoossf:mainfrom
Conversation
Signed-off-by: Eddie Knight <knight@linux.com>
eddie-knight
requested review from
SecurityCRob,
david-a-wheeler,
evankanderson,
funnelfiasco,
puerco and
trumant
Signed-off-by: Eddie Knight <knight@linux.com>
eddie-knight
changed the title
trumant
left a comment
trumant
left a comment
There was a problem hiding this comment.
These changes add clarity and I don't see any obvious downsides
funnelfiasco
left a comment
funnelfiasco
left a comment
There was a problem hiding this comment.
I like these overall. I want to come back to it again in a day or two and look in detail to see if there are changes I want to suggest tweaks to.
evankanderson
left a comment
evankanderson
left a comment
There was a problem hiding this comment.
Thanks for simplifying these! If we could enforce an e.g. 70-character limit on the titles, it would make it a lot easier to present the different OSPS checks with human language in addition to the lovely category-number-subnumber that we all know today.
There was a problem hiding this comment.
I think these changes are heading in the right direction, but they also expand the scope of the baseline controls. The existing items mostly talk about managing the version control system, but the new wording would reasonably also include other project resources such as distribution channels (e.g. NPM publishing, etc).
| title: | | ||
| The project's version control system MUST prevent unintentional | ||
| modification of the primary branch. | ||
| Protect the Primary Branch. |
There was a problem hiding this comment.
I feel like this needs a little more description of the protection (i.e. protect from accidental modification).
Also, this title ends with a ., while none of the others do.
There was a problem hiding this comment.
| Protect the Primary Branch. | |
| Protect the Primary Branch from Accidental Modification |
| objective: | | ||
| All released software assets MUST be signed or accounted for in a | ||
| signed manifest including each asset's cryptographic hashes. | ||
| Ensure released software assets can be verified by users to ensure |
There was a problem hiding this comment.
It seems like we're also removing MUST language from a bunch of places. What's the rationale there?
There was a problem hiding this comment.
We started moving the "MUST" bits to requirements statements with the objective being more of a summary statement... but we didn't ever swing back to make sure there is consistency in those objectives
| title: | | ||
| The project documentation MUST provide user guides for all basic | ||
| functionality. | ||
| Publish User Guides for All Basic Functionality |
There was a problem hiding this comment.
| Publish User Guides for All Basic Functionality | |
| Publish User Guides for Basic Functionality |
I'm not sure that "all" is doing useful work here. You can simply move the functionality line if you have something not well documented, as long as there is some documentation existing.
| - id: OSPS-DO-02 | ||
| title: | | ||
| The project MUST provide a mechanism for reporting defects. | ||
| Provide Mechanism for Reporting Defects |
There was a problem hiding this comment.
| Provide Mechanism for Reporting Defects | |
| Provide Mechanisms for Reporting Defects |
| - id: OSPS-SA-03 | ||
| title: | | ||
| The project MUST assess the security posture of all software assets. | ||
| Publish Security Assessment |
There was a problem hiding this comment.
"Publish" seems to be a new requirement -- is it required that the assessment be made public, or can it be held privately by the maintainers?
| Enable external parties to easily understand who they should contact | ||
| in the event that a vulnerability is found, and what process they should | ||
| follow. |
There was a problem hiding this comment.
I liked the old version better, I think, though I could be convinced otherwise.
| Consumers of the project must be informed about known vulnerabilities | ||
| found within the project. | ||
| Ensure that project end users have a well known mechanism to understand | ||
| vulnerabilities found within the project. |
There was a problem hiding this comment.
This feels like it moved from "publish CVEs" to "analyze previous vulnerabilities". Maybe it's "Publish Data About ..." with the shorter title. Would "Publish Discovered Vulnerabilities" be an acceptable title?
| Identify and address defects and security weaknesses in the project's | ||
| imported code early in the development process, reducing the risk of | ||
| shipping insecure software. |
There was a problem hiding this comment.
The previous version included the idea of a "threshold for remediation" -- i.e. that vulnerabilities below a certain threshold might not be addressed. (Hello JS ReDOS spam!)
I'm indifferent to the "before software is merged" part -- that feels like a nice-to-have rather than a requirement.
| title: | | ||
| The project documentation MUST enforce a policy that defines a | ||
| threshold for remediation of SAST findings. | ||
| Publish and Enforce an Application Security Testing Policy |
There was a problem hiding this comment.
We didn't previously have a lexicon entry for SAST, but "Application Security Testing Policy" feels a little vague if we're trying to say "there are many fine SAST tools free for OSS, use one!".
I guess we have "publish" because the previous version says that the documentation MUST enforce the policy, to give wiggle room for "run this SAST tool locally before sending a PR".
We've also lost the "threshold" idea here.
5 participants
Rewrite all titles, and adjust some objectives to ensure consistency