search

disclose / diodb

Open-source vulnerability disclosure and bug bounty program database
https://disclose.io/programs/
Creative Commons Zero v1.0 Universal
987 stars 320 forks source link

Public Disclosure Field Discussion: disclosure_timeline_days type requirement is overly strict for some policies #357

Open JLLeitschuh opened 2 years ago

JLLeitschuh commented 2 years ago

I'm noticing that none of the policies currently listed have disclosure_timeline_days set. However, it's a requirement if co-ordinated is set. This seems like overly restrictive for a org declaring their disclosure policy. Our policy states:

Provide us with a reasonable amount of time to remedy the vulnerability before sharing the details of the vulnerability with the public, and in any event, avoid sharing any details of the vulnerability publicly until you have at least received an acknowledgement from us regarding the reported vulnerability; - https://github.com/gradle/.github/blob/master/SECURITY.md

Our policy is attempting to allow public disclosure, but not set any hard deadlines on anyone's disclosure timeline. Not sure how to communicate this with the current schema requirements:

https://github.com/disclose/diodb/blob/a624b0c367053a6de2883e71005e848c288c3f3b/program-list-schema.json#L96-L105

sickcodes commented 2 years ago

Really appreciate you pointing that out @JLLeitschuh, I hadn't looked in a long time!

CC: @yesnet0 regarding public_disclosure in the JSON array

Schema is completely flexible and was last edited Jan 23, 2021 :)

  1. I'd personally would like to change any "yes" to true, and "true" to true for a start. Same goes for "no" -> false, "false" -> false, etc.

  2. Since this is totally Open Source and run by visitors, users, maintainers (anyone who commits!) I'd love to see some expansion on the public_disclosure field.

Currently, only 13/4000 with a value for key public_disclosure

...
      "public_disclosure": "",
      "public_disclosure": "",
      "public_disclosure": "",
      "public_disclosure": "",
      "public_disclosure": "",
      "public_disclosure": "co-ordinated",
      "public_disclosure": "discretionary",
      "public_disclosure": "discretionary",
      "public_disclosure": "discretionary",
      "public_disclosure": "discretionary",
      "public_disclosure": "discretionary",
      "public_disclosure": "discretionary",
      "public_disclosure": "no",

A radical approach could be default to true otherwise false, as per:

https://www.cisa.gov/coordinated-vulnerability-disclosure-process

Verbatim via CISA:

The CISA coordinated vulnerability disclosure process involves five basic steps:

1. Collection: CISA collects vulnerability reports in three ways: CISA vulnerability analysis, monitoring public sources of vulnerability information, and direct reports of vulnerabilities to CISA. After receiving a report, CISA performs an initial analysis to assess a vulnerability’s presence and compare with existing reports to identify duplicates. CISA then catalogs the vulnerability report, including all information that is known at that point.

2. Analysis: Once the vulnerability reports are catalogued, vendor(s) and CISA analysts work to understand the vulnerabilities by examining the technical issue and the potential risk the vulnerability represents.

3. Mitigation Coordination: After analyzing a vulnerability, CISA will continue to work with the affected vendor(s) for mitigation development and the issuance of patches or updates.

4. Application of Mitigation: When possible and where necessary, CISA may work with vendor(s) to facilitate sufficient time for affected end users to obtain, test, and apply mitigation strategies prior to public disclosure.

CISA is default disclose. See the end of part 4. As per normal good faith research, where possible, don't release before fixed.On the contrary, the last two words are default to public disclosure.

On the contrary, public vulns, that wouldn't get a CVE (config, webapp, vendor facing, etc.) is the other thing. As @disclose isn't the CVE project, nor CISA, nor a Bounty Platform, I'm personally of the opinion that:

...in absolutely any case whatsoever, the researcher owns their own research, period.

The researcher found it, and it's their research and their journey. So unless they've happily signed an NDA etc. or are happy to do private bug bounty, vulnerability research remains the property of the researcher, which would include their discretion whether to disclose or not.

If the vendor wants to be a part of that, that's what the "joint and "coordinated" words are there for.

HackerOne has a simplified interpretation of their viewpoint, which makes sense for their view point, which would be non-public submissions (a.k.a private programs): https://www.hackerone.com/vulnerability-management/your-tldr-summary-cert-guide-coordinated-vulnerability-disclosure

More reading material, if appropriate: https://vuls.cert.org/confluence/display/CVD

Obviously full disclosure can't be a boolean hard true/false, so here's some possible things that could be discussed for the public_disclosure key:

"joint" "coordinated" sometimes written co-ordinated "public" "NDA" "no" "private" ? ... "sometimes"