Complete Initial Draft of v1 Security Program Standards

[ruddermann]

Intro and Review of Standards: https://docs.google.com/document/d/1tvJYtptFXqvS4863dhPwoVmFT5Jwr_WZLralrnulCZs/edit

Standards Checklist:
https://docs.google.com/spreadsheets/d/1GwIsAudAn89xv9DAbr1HUaY4KEVBsYfg--_1cW0uIB0/edit#gid=0

[mcollina]

I have a rough feeling that most of those guidelines are significantly too strict for all our projects and adopting them will bring them to a halt.

Here is a non-exhaustive list:

1. limiting github ownership is problematic. It creates additional work for a few individuals that are usually best used elsewhere.
2. 4 eyes reviews is untenable in most cases. Even Node.js has a rule that drops it after a week, because certain areas of the project have only two active maintainers.
3. Dismissing stale reviews when commits are pushed is problematic and will add a lot of friction.

Note that "default branch must be up to date before merging", 4/6 eyes reviews and dismissing stale reviews will bring any progress on most project to a halt, because essentially it implies have 2 people that spend their days reviewing and landing changes, in order.

There are a lot more like this. I don't think these are helpful for us, as they would require extensive rework of GitHub organizations. Note that LFIT proposes to take over "owner" duties in an GH org and move to a ticketing system for any changes in the GH org. I don't see how this is feasible either.

Last but not least, I don't think it's fair to ask for volunteer work where they cannot trust their fellow volunteers. We should trust (and empower) people.

[ctcpip]

the intro is really well-written. 👏 provided some minor comments/suggestions in the doc. I will take a look at the checklist later. thanks Rudd!

[ctcpip]

went through the checklist, lots of great stuff in there

[tobie]

Second @ctcpip’s comments: great intro. I like how the spreadsheet references documentation on how to implement it. That’s very helpful.

I think the recommendations would benefit from some information as to what threats they’re addressing. This might be obvious to you, but it isn’t necessarily obvious to everyone, myself included. People tend to take recommendations to heart more willingly if they understand their intended purposes.

Finally, I didn’t dig into the specifics of the requirements yet, but I think @mcollina’s comment here are critical; we can’t add requirements that burden maintainers.

[ruddermann]

Thanks folks! I've incorporated a lot of the feedback from @mcollina @ljharb and @ctcpip and will be doing more edits tonight.

@tobie I agree. FWIW, the data you're talking about is usually in the references, but buried very, very deep.

My current preference is to communicate the 'why' through the lens of the risk it's attempting to control for and potentially even an example of an attack that could have been avoided (this is a lot of data gathering tho and may be better in a v2). My preference is also to do this in the most minimalist way possible for quick comprehension. CNCF's guide has fantastic detail, but even as a security guy I find its length overwhelming and I'd prefer to avoid that visceral reaction here.