Description: Execute a pilot that introduces and encourages one or two projects to complete a self-assessment with a CNCF SIG-Security person assigned to walk them through and guide them on completing the self-assessment.
It is not intended to be a joint-evaluation, more to be as a touch point with security insights to guide projects in jump starting their security considerations for their software project.
Ideally we would select one or two projects that are not security focused (don't provide security in the ecosystem) that are very early in their maturity, sandbox preferred, to test this out with. At the end of this we want to capture:
ContainerD has a similar concept however it is more for day-to-day security advisement
Impact: We believe this will be immensely helpful for early maturity, non-security projects to begin thinking about and considering their security. The product of this also is an input to the joint-review under the Security Review Process.
Scope: We would need to research and select one or two projects, determine if they are amenable to trying this out, and then have them complete the self-assessment. Overall the assessment completion is relatively light-weight, and should take no more than a few hours, with overall commitment from the SIG-member to be about a week or two.
TO DO
I'm a fan of getting security stuffs outside our bubble to non-infosec peeps, so count me in. :)
Likewise, happy to help out however I can with this.
Same here, but my vote still goes to Security Champions for the name of this program! =)
Breaking things down in more detail, I guess what we need to cover...
I think we can figure this out on slack without a zoom call, but lemme know if desired @apmarshall / @magnologan
@TheFoxAtWork - I'd suggest we pick 3 projects vs 2, then each of us can work with one...
From ContainerD (emphasis mine): https://github.com/containerd/project/blob/master/GOVERNANCE.md#security-advisors
A security advisor is an advisory role in the project responsible for helping classify and advise on embargoed security disclosures. Security advisors are individuals trusted by maintainers and representing significant users of the project.
Security advisors are part of the organization without write access, but with read access to security disclosures and advisories before becoming public. There is no expectation of advisors to become reviewers or participate in issue triage and code review. Security advisors help maintain the integrity of the security review process and encourage responsible disclosure.
A reviewer may also be a security advisor, however, maintainers do not need this role as it is part of regular maintainer duties. The security advisor duties are not part of the duties of being a reviewer.
Candidates should contact a maintainer and request sponsorship for becoming a security advisor. Once a maintainer is willing to sponsor a candidate, the maintainer will open up a pull request to the SECURITY_ADVISORS files adding the candidate. Since it is not expected that candidates are active in the project, there is no expectation that they are well known by a majority of maintainers. Approving the pull request requires a two LGTM threshold of maintainers.
Security advisors may be removed by the same sponsoring maintainer with a two LGTM threshold or by any other maintainer with approval of 33% of current maintainers.
So there's a slightly different focus here than what I think we're doing (which is helping sandbox projects start thinking through security and perform their own security self-assessments), but similar structure for the role (outside advisor, not necessarily a code contributor/reviewer, focused on security).
Current list of ContainerD Security Advisors, if we want to follow up with them about their experience: https://github.com/containerd/project/blob/master/SECURITY_ADVISORS
@apmarshall concur - not quite the same thing. This to me is almost more of a welcoming committee -
I sorta like the term "security buddy" as it sounds less formal, more friendly. This will probably be a new projects first interaction with this SIG, so important to start on the right foot, but get them to realize we care about appsec...
Security Champion - Pretty common descriptor for an embedded security aware member of an existing team usually supported by an external security office or program. Not typically an outside advisor but rather an 'in-group' confidant and ...champion. Seems potentially clash-y with the use case here.
Security Advisor - Generic enough to take on whatever role. Advisor typically does infer hands above rather than hands on.
Security Buddy - I believe 'buddy' is not considered strictly gendered but in some places in the world it definitely leans that way in my experience (replacing mate or dude often). IMHO.
Security Partner - This is defined within quite a few larger orgs (facebook, netflix etc) to indicate a liaison role between a specific BU or product and a broader governance and security assurance program. Different from Champion in that champion is usually an embedded role within a team (say agile)
Security Pal - I wonder if Pal translates well to non-Germanic languages. It would probably be convered to "Friend" or equivalent. Not a downfall necessarily but maybe literally using "Friend" in english would make more sense.
Advisor or Partner seem to be the most palatable idioms here to me :)
@jlk can you list the pilot projects on the issue?
I will like to be included in this as a security Pal for any upcoming projects...Please include me.
Here's the projects we're working with at this time:
We've engaged with the four, and have initial positive interactions. As these teams are working on other things, it'll probably take a month or two to fully understand how things are working out. Will try to keep this updated along the way.
@achetal01 I've added you to the #sig-security-secpals slack group.
Thank you. Sure Lets sync up next week...