Define and advocate a security reporting process for CNCF projects

[joshuagl]

Description: Establish a project resources directory within Security TAG that contains templates and other useful security information for CNCF projects.

Impact: We've had a request from at least two projects that providing resources and templates to ease the security of their projects would be incredible useful to them, save time researching, and allow them to get to a security first mindset.

Scope: Creation of the directory, creation of initial templates, resource and reference discovery, README.md with info on how to maintain the repository so it does not become stale.

Intent to lead:

• I, @TheFoxAtWork volunteer to be a project lead on this proposal if the community is interested in pursing this work. This statement of intent does not preclude others from co-leading or becoming lead in my stead.

Proposal to Project:

• Added to the planned meeting template for mm dd
• Raised in a Security TAG meeting to determine interest - mm dd
• Collaborators comment on issue for determine interest and nominate project lead
• Scope determined via meeting mm dd and/or shared document
  with call for participation in #tag-security slack channel thread
  and mailing list email
• Scope presented to Security TAG leadership and Sponsor is assigned

TO DO

• Security TAG Leadership Representative:
• Project leader(s): @TheFoxAtWork

---

SIG Security should advocate for projects to adopt a security reporting process. This could happen during security assessment where assessors can encourage teams to adopt a process if they don't have one.

As part of this advocacy SIG Security should define a best practices for vulnerability reporting that teams can adopt.

It may even make sense to have a centralised email address that vulnerabilities are reported to where SIG security members can work with project teams to handle and address the vulnerability in a responsible manner?
This will be particularly useful for smaller/emerging projects and larger/more established projects can switch to their own security reporting contact point at a later time if desired.

Defining a best practice/template process could be particularly impactful now when GitHub have just released a feature for defining a security policy: Adding a security policy to your repository

In the same vein it may make sense to try and advocate for (and perhaps centralise, see #170) reporting security vulnerabilities to distributors much as Envoy (and others) have a Private Distributors List

[rficcaglia]

CI certainly encourages it:
https://github.com/coreinfrastructure/best-practices-badge/blob/master/doc/criteria.md#vulnerability_report_process

I also agree a best practices statement/opinion/example is useful!

But whether responsibility resides at the SIG, or is delegated down to each project could be argued both ways. I myself would argue against centralization both in terms of "quis custodiet ipsos
custodes?" (noted in #170), but more so that it encourages tossing the problem over the wall for others to deal with. I think table stakes for projects should be that they invest significant thought and planning in the response process, and make it an ongoing priority (which should inform upstream feature planning and issue prioritization processes.)

[TheFoxAtWork]

IMO its the responsibility of the project, i believe we ask about it in the proposed template changes from #176
That being said, recalling the vulnerabilities reporting presentations given for the k8s vulns, it certainly stands to reason that SIG-Security can provide a standard process to get teams started so when the vuln happens, their response time is faster, the communications more effective, etc. We could even just host it on the microsite @ultrasaurus was discussing.

[joshuagl]

Providing a recommended process (even a template GitHub security policy) would be a good outcome for this issue, the idea for a centralised reporting mechanism admittedly doesn't scale to a nascent volunteer group.

Great to see we're asking teams about this during assessment, the natural response from those that don't have a policy in place will be to ask SIG security for recommendations so this issue ties that up nicely.

[TheFoxAtWork]

clarified it in the pull request so its more explicit.

[TheFoxAtWork]

#182 merged in. Remaining items from this ticket are:

• template creation for responsible disclosure process
• template creation for incident response

[stale]

This issue has been automatically marked as inactive because it has not had recent activity.

[annabellegoth2boss]

With regards to the template work, I recently published a CVD guide for OSS and set of templates; there may be something here that's helpful. (Or all of it? Just fork and edit away?)

[ultrasaurus]

Thanks @annabellegoth2boss! Would be great if another volunteer from the community could review that and suggest next steps and whether it would meet our needs to reference or adopt and if there are gaps that need to be filled in.

[justaugustus]

Happy to help review here from the lens of:

• smaller project maintainer (Dex)
• larger project Release Manager (Kubernetes)

[lumjjb]

Sounds like this is relevant to: #554, perhaps there's something that can be worked out here

[TheFoxAtWork]

@lumjjb it's related for sure. Security pals increase awareness for Cncf projects and assist in completing the self assessment. The self assessment discusses a secure reporting/ vuln disclosure process. But it certainly does not prescribe one.

[annabellegoth2boss]

@justaugustus Any questions about the guide or other things I can answer?

[TheFoxAtWork]

@annabellegoth2boss this actually came up during a presentation in yesterday's meeting. CC: @jlk

I'm going to try to spend some time on this in the next week or so. See if i can drag another member into this as a small project.

[TheFoxAtWork]

Check in to determine if this can be closed. Does the new project security resources in the repo satisfy this issue?

[lumjjb]

bump @joshuagl , ^^^

[stale]

This issue has been automatically marked as inactive because it has not had recent activity.

[anvega]

Closing this issue as it has been stale for a number of years. The TAG believes that project security resources satisfies the ask.