Define Vulnerability Report Process

[dcmiddle]

From Reporting section of https://bestpractices.coreinfrastructure.org/en/projects/5719

1. The project MUST publish the process for reporting vulnerabilities on the project site.
2. If private vulnerability reports are supported, the project MUST include how to send the information in a way that is kept private.
3. The project's initial response time for any vulnerability report received in the last 6 months MUST be less than or equal to 14 days.

Additional information from the badge process:
_A clearly designated mailing address on https://PROJECTSITE/security, often in the form security@example.org. This MAY be the same as its bug reporting process. Vulnerability reports MAY always be public, but many projects have a private vulnerability reporting mechanism.

Examples [of private reporting] include a private defect report submitted on the web using HTTPS (TLS) or an email encrypted using OpenPGP._

[ariel-adam]

@dcmiddle is this issue still relevant or can be closed?
If it's still relevant to what release do you think we should map it to (mid-November, end-December, mid-February etc...)?

[ariel-adam]

@dcmiddle do you think this can converge for the V0.3.0 release?

[dcmiddle]

@ariel-adam Doubtful before v0.5. Updated project fields accordingly.

[dcmiddle]

We need 2 things: A reporting mechanism and a SECURITY.md file.
The mechanism can be an email address or private github issues.

If we opt for an email address then I recommend that we populate the security email list as an alias of the Steering Committee list.
1. That list is actively maintained
2. Those individuals should know who to contact to address a security issue

The other option is private github issues.

Then we just need to document which of those paths in our SECURITY.md file.

I recommend we enable private issues. We can do that on all repos and then in the security.md clarify that if you don't know which repo to use pick our main repo.

[fitzthum]

There was a suggestion about adding these people as part of the security reporting.

I think a CNCF mailing list is a bit of a non-starter. The mailing list we already have isn't up-to-date and we can't manage it ourselves. We could create a new mailing list somewhere else.

I think private issues are a better approach. Users might not be as familiar with this, but the security tab is pretty easy to find in a repo. Private issues are only available at the repository level. Issues are visible to the maintainers of each repo as well as an organization-wide security team. This seems pretty good. I will experiment with the feature a little bit. We shoudl also start drafting a security.md that we can put in each repo.

[dcmiddle]

start drafting a security.md that we can put in each repo.

I've started looking into what's appropriate given our maturity and adoption level. I'll plan to put up a draft PR on the .github repo that will then automagically appear in all the repos.

[fitzthum]

Ok, we can turn on reporting independently from making security.md On Thursday I will ask if there are any objections to turning on the reporting for each repo.

[dcmiddle]

Sounds great. We will want maintainers familiar with private issues before we advertise them in the security.md.