Document Recommendations for Vulnerability Report Handling
eddie-knight opened this issue · comments
Problem
Several inquiries have recently been brought to us regarding how to respond to or address a vulnerability report to a CNCF project. The advice we provide is rarely unique to the situation, but someone from the TAG must spend cycles on the issue before being sure.
Solution
The community could be served by a general guidance document as the entrypoint for such inquiries. For example, a list of frequently asked questions or common situations could conclude with steps to reach the TAG if the situation is unique.
I think also some projects aren't aware of what should be considered a vulnerability vs. what is misconfiguration or similar.
Stuff to put into that document is also highlighting the threat model as well. A common misconception is just because an application if compromised could leak data it's the same as if the application is in fact compromised.
Project teams should assess vulnerabilities themselves following standard practices similar to bug reports, which includes gathering enough information to verify and reproduce, and then triaging. If they find that the reported issue does not constitute a true vulnerability, or if they have doubts about its validity, they should discuss this with the reporter to clarify the situation.
Discussing or sharing the report outside of their group would not adhere to responsible disclosure practices. Private reports should only be shared with those who have a legitimate need to know, such as maintainers of other affected projects they integrate with or individuals with whom they have specific vulnerability sharing agreements (although such agreements are rare in OSS).
What we do look for and ask projects moving from sandbox to incubation is:
- The project must provide a process for users to submit bug reports (e.g., using an issue tracker or a mailing list).
- The project must publish the process for reporting vulnerabilities on the repo and project site.
- The project must include how to send the information in a way that is kept private.
- Respond to reports in a reasonable timeline (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.)
- Offer credit (The project must give credit to the reporter(s) of all vulnerability reports resolved in the last 12 months, except for the reporter(s) who request anonymity.)
- The project must have a documented process for responding to vulnerability reports.
- Publish clear security advisories and changelogs.
*Must explain mitigations when discussing vulnerabilities or security issues in any comms.
While the topic is important, it is already extensively covered in existing resources on vulnerability management as well as incident response. Might be hard to create an exhaustive authoritative document, particularly with the other suggested topics. I suggest instead compiling a list of these existing resources for project teams to reference.
Thanks @anvega. I think the most important part you highlighted is that there are existing recommendations already captured throughout the TAG resources. It'll be helpful to reference those from a centralized recommendation of how to respond to a vuln report.
@anvega Agreed. I think one thing that is missing maybe is just pointing people in the right direction as well as making sure CNCF staff understands this as well. In a few cases they've directed projects to reach out to us.
One particular thing I think we should do I think is point folks to resources on what sorts of things tend to count as a vulnerability. Looking through our existing resources I couldn't find anything but I also don't think we should create one ourselves as I'm sure there' something pre-existing stuff out there.
Sure. To address the need for clarity on what constitutes a vulnerability, project maintainers must understand better than anyone else under what conditions a bug, a particular configuration, or deployment parameters become a security risk. They should be able to perform a contextual risk evaluation to determine if what is being reported can render the software vulnerable to attack.
Something to keep in mind even in compiling recommendations is that while there are obvious vulnerabilities like broken auth, SQL injection, XSS, CSRF, etc., it's hard to give guidance that something counts as a vulnerability without context or intimate working knowledge, as conditions will be variable and project specific. We can call out risks to watch out for but the final determination is something only each project is in a position to do.
A methodical approach to this is to use a standard software security framework, such as the OWASP SAMM Project, BSSIM, or any other standard Software Security Maturity model. This involves identifying threat agents, attack vectors, security weaknesses, security controls, technical impacts, and business impacts of an identified bug in terms of security.
I found this topic to be fairly well covered by a resource within the family/in-house:
- https://github.com/ossf/oss-vulnerability-guide/blob/main/finder-guide.md#understanding-how-the-project-handles-vulnerabilities-aka-security-policy
- https://github.com/ossf/oss-vulnerability-guide/blob/main/finder-guide.md#a-note-about-software-development
The guide that contains those sections is linked here:
@mlieberman85 What do you think about linking to this one? It seems to address all of the original concerns.
@mlieberman85 What do you think about linking to this one? It seems to address all of the original concerns.
I was just reading it. Looks good to me.
Any ideas for where we should add the pointer?
A good place is the README for this repository, possibly under 'Additional Information,' if you add some language on ecosystem guidance or something along those lines, if for whatever reason this turned out to be the place people would come searching for this.
Let's address this during #1260 — We're planning to migrate a page from contribute.cncf.io specifically dedicated to advice for project maintainers. This would be a great addition to that page.
Actually, this is already covered under project-resources/templates/incident-response.md