(8/25/21 I've moved this to cncf/tag-security#554 (comment))
This is meant as an overview of the Security Pals project to help get people up to speed.
This is a TAG Security pilot to smoothe the security aspects of onboarding a new CNCF project. The "security pals" act as a friendly initial point of contact, help projects understand what the security self assessment is, and act as a security guide/mentor through the assessment. In a nutshell, we don't expect the average open source project to have application security expertise, so we reach out with an offer to assist as we can.
- Artifact Hub
- Crossplane
- Kyverno
- Tinkerbell
What seems to be working is just figure out where the project hangs out, and go say hi. Usually they have a slack channel or server somewhere - probably listed on their website. A slightly softer/friendlier version of "Hi! I'm from TAG Security, and I'm here to help!" seems to get met with surprised positive response.
Approaching a project with an open-ended request doesn't seem to be getting much traction. I'm starting to think having a defined timeline would keep things moving and set better expectations. As an example:
- Week 1: Initial meet and greet, give overview of project, where the project can find the Self Assment, answer any initial questions (give the team a few weeks to digest all of this)
- What might be useful here is to get a sense for where the project stands, regarding graduation. If they're new into the sandbox, and forsee many months of work to prepare for graduation to Sandbox, then security might not be top-of-mind.
- Week 4: Followup - see if any questions, what progress has been made, is there anything the security pal can help unblock, from a security POV (or make connections to other CNCF resources)?
- Week 6-8: Soft target for a draft of self-assessment
- Week 12-16: Submit self-assessment for review
To help with this, I think a few slides or doc of some type would be very useful to help communicate the ways we're open to engage (I'm avoiding the word "process"), as well as being a take-away for the project to look at after initial communication. I've got some ideas here, will try to get a draft together to test out on Argo, whom I'm engaging with over coming weeks.
There's also value in having a doc (that one, or maybe separate) that guides the security pal through how to engage, questions to expect, example timelines, what's worked to-date, etc. This writeup's a step towards that...
Another alternate idea would be for the pals to ask one question of the project every few days, gathering the info that way. But that puts a little more burden on the security pal, and I'm not sure that's where we want to go...
In the GH Issue for this pilot, there's a reference to this process taking a "week or two." So far we're seeing months. That's a pretty significant difference, so there's opportunity for navel-gazing on how to improve focus on this. Teams are busy, the pals have their own thing going on - so while I don't want to walk into a meeting with a project with a structured timeline, some structure would help. So maybe part of that engagement is a frank communication on what works for both sides, along with executing well on the followups.
Part of the problem here is we want to be friendly, the project contacts are either volunteers or have a dayjob. I suspect there's hesitancy in getting started, so just suggesting to start the assessment by filling what's known and then discussing the other bits might help. At least I've taken a "why don't you guys give it a read and let me know where I can assist" stance - that's welcomed, but perhaps "let's get on a call and go through this one by one, get the easy ones out of the way and let's see what's left" would accomplish more.