docs: add adoption guidance docs and example files#130
docs: add adoption guidance docs and example files#130eddie-knight merged 1 commit intoossf:mainfrom
Conversation
This change updates `README.md` to provide greater clarity to projects adopting insights and polishes some existing guidance that was inaccurate/out-of-date. The new example files provided extend the guidance in the README and are referred to within that guidance. This closes ossf#126 This updates ossf/security-baseline#257 Signed-off-by: Travis Truman <trumant@gmail.com>
| The data tracked within this specification is intended to fill the gaps between simplified solutions such as `SECURITY.md` and comprehensive automated solutions such as SBOMs. In that gap lay elements that must be self-reported by projects to allow end-users to make informed security decisions. | ||
|
|
||
| ## Usage | ||
| ## Usage by project maintainers |
There was a problem hiding this comment.
@jranson as a recent adopter in the Trickster project, your view on this particular documentation would be very helpful. If you can give it a review and feedback/comments - I'd appreciate you.
There was a problem hiding this comment.
@trumant always doing first rate work. 😍
I like the flexibility here, which is great for busy maintainers who want to be good stewards around project security without it becoming burdensome . But with that flexibility comes questions. How will a maintainer know what elements that (a: apply to their project, and b: are in the gap) warrant self-reporting and which ones do not? Is there / should there be a benchmark for adequate exhaustiveness of self-reporting, and if not, how can a naive maintainer like me know what is good enough? (not that we want to just do the bare minimum, but those of use who aren't security engineers can probably use some guidance to help get it right the first time).
I didn't see that anywhere in this PR, but maybe it's elsewhere in the project? if not, is more info on acceptable self-reporting something that can be put together in a future contribution? Linking to it from the Readme when it's ready would be 👌
There was a problem hiding this comment.
Really appreciate your feedback @jranson
The template-minimum.yml example is meant to highlight the absolutely bare minimum, but I think the more project-specific questions a maintainer has would likely be answered by us illustrating a more clear link between https://baseline.openssf.org/versions/2025-02-25 and the usage of Insights.
That is feedback we've heard from other maintainers and community members before and something we're intending to address as part of ossf/security-baseline#256
|
This is excellent. Leaving this open as you've called for additional community input- let me know when it's ready to go. |
|
@eddie-knight I think we are ready to merge whenever now that we have more maintainer signal here. |
3 participants
This change updates
README.mdto provide greater clarity to projects adopting insights and polishes some existing guidance that was inaccurate/out-of-date.The new example files provided extend the guidance in the README and are referred to within that guidance.
This closes #126
This updates ossf/security-baseline#257