Create TI-Gives+Gets.md #226
Conversation
first draft for debate to determine requirements of and benefits for TIs. Signed-off-by: CRob <[email protected]>
typos Signed-off-by: CRob <[email protected]>
more typos Signed-off-by: CRob <[email protected]>
last typo? Signed-off-by: CRob <[email protected]>
process/TI-Gives+Gets.md
Outdated
| @@ -0,0 +1,52 @@ | |||
| # "Gives and Gets" for OpenSSF Technical Initiatives (TI) | |||
| The OpenSSF has a large community of contributors and efforts that span the broad spectrum of open source security interests. The Technical Initiatives (TIs) of the foundation are where our members collaborate and help craft unique solutions to addressing improving the security of the open source ecosystem. | |||
There was a problem hiding this comment.
Do we want to also highlight that his gives and gets is a bit vague on details and how someone should approach understanding more?
May post project updates and tutorials to the OpenSSF blog.
How many? How often?
I know we don't have an answer to that but we might want to highlight that this is access to these benefits but the details will depend on time, scope, staffing, etc.
There was a problem hiding this comment.
I would suggest to make the guidance as broad as possible. I'm not sure telling someone they can post 4 blogs a year really adds anything. If folks have work output to share that adds value, they should get it shared; if they don't or on working on a long-running project, that's ok too. But that's just my opinion.
lined 2nd table up better-ish Signed-off-by: CRob <[email protected]>
more lining Signed-off-by: CRob <[email protected]>
There was a problem hiding this comment.
Thanks for taking a crack at this and getting the ball rolling @SecurityCRob !
Co-authored-by: Arnaud J Le Hors <[email protected]> Signed-off-by: CRob <[email protected]>
Co-authored-by: Arnaud J Le Hors <[email protected]> Signed-off-by: CRob <[email protected]>
process/TI-Gives+Gets.md
Outdated
| | | Projects may use the OpenSSF logo to promote their project (in accordance with the trademark guidelines). Projects may be referred to as an "OpenSSF Project" or "OpenSSF $ProjectName." | | ||
| | | May request considered for Grants | | ||
| | | May request consideration to get Contract Developers | | ||
| | | Requests for one time funding needs to include: Tech writer, Graphic designer, Security audit, Event support, Outreach, Dashboard/reports, Recognition awards, Infrastructure support for software projects (like special build, QA) (will have ongoing operational expense), Cloud hosting (will have ongoing operational expense) | |
There was a problem hiding this comment.
A lot of this feels like it should be under incubating. If the goal of graduation from OpenSSF end is to have a well structured, well governed, well written, well documented project some of these projects are coming to OpenSSF to support there. I think things like security audits and documentation in particular should be things that OpenSSF helps provide to take a project from incubating to graduation.
There was a problem hiding this comment.
sounds fine to me, do you want to suggest how/where to move the text?
|
So, I played a bit with the layout to see what I could suggest and here is what I've got: If we want to stick to a table layout with two columns I think it should look something like this: I think we should let go of the table layout and adopt a simple list based layout which can be easily maintained in pure markdown: In any case, once we have agreement on one way or the other I'll be happy to push a commit accordingly. |
Agree - I think this will make it easier to link directly to these subsections of the document. |
|
I prefer the second option, using the list
Cheers,
CRob
Director of Security Communications
Intel Product Assurance and Security
From: Arnaud J Le Hors ***@***.***>
Sent: Tuesday, November 28, 2023 9:52 AM
To: ossf/tac ***@***.***>
Cc: Robinson, Christopher ***@***.***>; Mention ***@***.***>
Subject: Re: [ossf/tac] Create TI-Gives+Gets.md (PR #226)
So, I played a bit with the layout to see what I could suggest and here is what I've got:
If we want to stick to a table layout with two columns I think it should look something like this:
Screenshot.2023-11-28.at.3.43.30.PM.png (view on web)<https://github.com/ossf/tac/assets/6464618/24c3cb75-e7c0-4615-9742-0a100f115a4f>
The problem is that because markdown doesn't support lists within tables this requires switching to encoding the whole table in html instead. Not a big deal but not as convenient to maintain as pure markdown.
I think we should let go of the table layout and adopt a simple list based layout which can be easily maintained in pure markdown:
Screenshot.2023-11-28.at.3.45.41.PM.png (view on web)<https://github.com/ossf/tac/assets/6464618/1e1cd01d-7c9e-4653-82a8-e84a2fb3ef15>
In any case, once we have agreement on one way or the other I'll be happy to push a commit accordingly.
—
Reply to this email directly, view it on GitHub<#226 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AQRFDLFTUF3VOKNF3PNMHXLYGX3CXAVCNFSM6AAAAAA74CMT7GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMZQGAYDINRZGY>.
You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>
|
Signed-off-by: Arnaud J Le Hors <[email protected]>
|
Ok, I just pushed a commit changing the layout from tables to lists. I compared the 2 side by side to check so I'm pretty confident I didn't screw up anything while doing so. :-) |
Signed-off-by: Arnaud J Le Hors <[email protected]>
Signed-off-by: Arnaud J Le Hors <[email protected]>
|
thanks @lehors . I like the way you arranged it better. +1 |
There was a problem hiding this comment.
I'm done for now. I think @mlieberman85 raised a couple of points that we should try to address.
process/TI-Gives+Gets.md
Outdated
| ### Gets/Benefits | ||
|
|
||
| TI eligible to receive all Gets from Sandbox plus: | ||
| * Receives infrastructure support |
There was a problem hiding this comment.
qq: is infrastructure support in the sense of cloud hosting, etc. I think there is a similar point in both sandbox and graduated, is the infrastructure support different? E.g. up to $X per project?
There was a problem hiding this comment.
The idea was limited hosting (GH repo basically for Sandbox) and as a project matures they could request more (website, cloud credits, etc.). We'll adjust to be more explicit. TY.
process/TI-Gives+Gets.md
Outdated
| * Implements, practices, and refines mature software development and release practices, such as adherence to semantic versioning, and having a declared policy for stable releases and backported fixes. | ||
| * Projects must have documented project governance and be able to demonstrate that governance in action. | ||
| * When applicable, projects must have completed a security audit through a third party and addressed audit findings and recommendations. | ||
| * When applicable, Projects should achieve **BLAH** level of SLSA |
There was a problem hiding this comment.
yeah, that's also what I had in mind but I am wondering whether we need to say SLSA Build Level 3 until more is defined.
There was a problem hiding this comment.
Like I commented above, very specific security requirements tend not to age well. As it stands, there are multiple interpretations of "prevent secret material used to sign the provenance from being accessible to the user-defined build steps" which is part of SLSA v1.0 Build Level 3.
... but I don't have a great suggestion here. Maybe leave this off? Or say something like "Projects should harden their build systems in accordance with the SLSA Framework"?
process/TI-Gives+Gets.md
Outdated
| * Maintains a point of contact for vulnerability reports in the security.md | ||
| * Implements, practices, and refines mature software development and release practices such as following a version schema. | ||
| * TI Follows security best practices (as recommended by the OpenSSF and others), including passing the OpenSSF Best Practices criteria | ||
| * Project should be integrating with Scorecards |
There was a problem hiding this comment.
Does "should" mean that these requirements are recommended but optional?
There was a problem hiding this comment.
This covers all TIs, so yes, it is optional for things that are not code in my opinion.
process/TI-Gives+Gets.md
Outdated
| * TI Follows security best practices (as recommended by the OpenSSF and others), including passing the OpenSSF Best Practices criteria | ||
| * Project should be integrating with Scorecards | ||
| * Begins to establish the appropriate governance that enables its sustainment for potential graduation. | ||
| * Projects should be Securing Code Repository -> Managing Contributions Commit Signing , Secret Scanning, Code Scanning (OSFUZZ at a minimum) + Self-assessment Should OpenSSF require these if the SCM supports it, especially using Sigstore? |
There was a problem hiding this comment.
I'm always hesitant when I see very prescriptive security requirements, as best practices change over time. What if we struck this line and add "... including secret scanning and code scanning" to "TI Follows security best practices..." above?
There was a problem hiding this comment.
Thanks a good suggestion, do you want to propose that wording change?
process/TI-Gives+Gets.md
Outdated
| * Implements, practices, and refines mature software development and release practices, such as adherence to semantic versioning, and having a declared policy for stable releases and backported fixes. | ||
| * Projects must have documented project governance and be able to demonstrate that governance in action. | ||
| * When applicable, projects must have completed a security audit through a third party and addressed audit findings and recommendations. | ||
| * When applicable, Projects should achieve **BLAH** level of SLSA |
There was a problem hiding this comment.
Like I commented above, very specific security requirements tend not to age well. As it stands, there are multiple interpretations of "prevent secret material used to sign the provenance from being accessible to the user-defined build steps" which is part of SLSA v1.0 Build Level 3.
... but I don't have a great suggestion here. Maybe leave this off? Or say something like "Projects should harden their build systems in accordance with the SLSA Framework"?
Co-authored-by: Zach Steindler <[email protected]> Signed-off-by: CRob <[email protected]>
added booth space to graduated Signed-off-by: CRob <[email protected]>
Co-authored-by: Zach Steindler <[email protected]> Signed-off-by: CRob <[email protected]>
Co-authored-by: Zach Steindler <[email protected]> Signed-off-by: CRob <[email protected]>
Co-authored-by: Zach Steindler <[email protected]> Signed-off-by: CRob <[email protected]>
Co-authored-by: Zach Steindler <[email protected]> Signed-off-by: CRob <[email protected]>
Co-authored-by: Arnaud J Le Hors <[email protected]> Signed-off-by: CRob <[email protected]>
Co-authored-by: Arnaud J Le Hors <[email protected]> Signed-off-by: CRob <[email protected]>
Co-authored-by: Arnaud J Le Hors <[email protected]> Signed-off-by: CRob <[email protected]>
Co-authored-by: Arnaud J Le Hors <[email protected]> Signed-off-by: CRob <[email protected]>
added version/approval date at head of doc Signed-off-by: CRob <[email protected]>
|
we have 4 of 7 needed approvals in with at least 2 more in-flight for today/tomorrow. I'm going to merge this 1.0 draft for people to see, and we can manage updates via PRs going forward. |
first draft for debate to determine requirements of and benefits for TIs.