Socializing SLSA level 3 and higher requirements

[tpepper]

We've got the KEP-3027 document published with a scoping of SLSA Level 3 and initial work toward higher SLSA level compliance underway in SIG Release. The doc also notes that level 4 is beyond reach near team. But then we have calls for hardware tokens as in #1790, OpenSSF and other supply chain security initiatives gaining attention, and it's easy to jump to "hey we should do all these security things for all reviewers/approvers". We have an MFA requirement for the org, so hardware keys for all specifically is probably not a huge need for us in the short term, versus other improvements which are more internal to SIG Release from a decision and implementation making perspective. But where SLSA specifically and broader supply chain security improvements may impact the whole project and require change from every contributor, it feels like we have too narrow scoped groups and are missing a common discussion location. SIG Release is obviously release scoped and the Security Response Committee (SRC) is scoped to incident handling. SIG Security is an obvious place for decisions for the whole project from a charter perspective. But I haven't seen SIG Release and Release Management active in that SIG talking about SLSA. Do we have things scoped correctly? Does any of this argue for a cross cutting WG? Or a Slack channel or some other forum for cross-team planning? Or is that #sig-security and #chairs-and-techleads already? Or more outreach from SIG Release on what SLSA is bringing now and may bring in the future?

[saschagrunert]

I was thinking about a Working Group as well recently, especially during the implementation time so keep the SIGs synchronized. I abandoned the idea for now, because I'd like to get more activity into the release engineering subproject first, where SLSA compliance will be our main priority in the next months.