search

cncf / tag-security

🔐CNCF Security Technical Advisory Group -- secure access, policy control, privacy, auditing, explainability and more!
https://cncf.io/projects
Other
1.99k stars 496 forks source link

Document Recommendations for Vulnerability Report Handling #1259

Open eddie-knight opened 1 month ago

eddie-knight commented 1 month ago

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.

mlieberman85 commented 1 month ago

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.

anvega commented 1 month ago

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:

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.

eddie-knight commented 1 month ago

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.

mlieberman85 commented 1 month ago

@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.

anvega commented 1 month ago

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.

anvega commented 3 weeks ago

I found this topic to be fairly well covered by a resource within the family/in-house:

The guide that contains those sections is linked here:

eddie-knight commented 3 weeks ago

@mlieberman85 What do you think about linking to this one? It seems to address all of the original concerns.

https://github.com/ossf/oss-vulnerability-guide/blob/main/maintainer-guide.md#troubleshooting-common-challenges-to-coordinated-vulnerability-disclosure

mlieberman85 commented 3 weeks ago

@mlieberman85 What do you think about linking to this one? It seems to address all of the original concerns.

https://github.com/ossf/oss-vulnerability-guide/blob/main/maintainer-guide.md#troubleshooting-common-challenges-to-coordinated-vulnerability-disclosure

I was just reading it. Looks good to me.

eddie-knight commented 3 weeks ago

Any ideas for where we should add the pointer?

anvega commented 3 weeks ago

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.

eddie-knight commented 3 weeks ago

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.

anvega commented 2 weeks ago

Actually, this is already covered under project-resources/templates/incident-response.md