Issue with "keeping vulnerabilities confidential" about diodb HOT 10 CLOSED

Thanks @JLLeitschuh.

Our goal here is to make sure people like yourself don't end up in a position where a) they've violated CFAA and/or DMCA, and b) they've self-incriminated by sending the vulnerability over. You're absolutely right - If you've found something, what you do with it is up to you, but you do so at your own risk and with a legal backdrop that does make imposing these sorts of terms as non-negotiable riskier than it ideally should be.

Two little nits in your policy wording:

• The word "Responsible" is generally being phased out, since it has been used with a negative moral loading against researchers in the past. "Vulnerability disclosure" is a good generic substitute, and the particular flavor of vulnerability disclosure you're using is called "Co-ordinated disclosure".
• "Full disclosure" is dropping the vulnerability to the vendor at the same time as you publish it on the internet. If publishing happens at the end of 90 days, it is still "Co-ordinated disclosure".

from diodb.

I know that this bucks the expectations of many of BugCrowd's customers and many of them won't be happy with this, but the question we need to be asking here is if disclosure is to protect companies or their users.

The best way to protect users is to force companies to respond quickly to security vulnerability reports.

from diodb.

How would you like to go about that then? Agreed that those "edge cases" must be tempered with.

90 days may be too little depending on the company, and the scale of the vulnerability.

from diodb.

In a majority of cases, companies can adequately respond to vulnerabilities within 90 days without issue. Google has historical data from its vulnerability reporting to back this up as well.

I think that the Google Project Zero team can cover this topic better than I can, so I've quoted their reasoning below:

Why are disclosure deadlines necessary?

We were concerned that patches were taking a long time to be developed and released to users, and we felt that disclosure deadlines set up the right balance of incentives.

Software vendors have responded to disclosure deadlines in a way that other options were historically unable to accomplish. Prior to Project Zero our researchers had tried a number of different disclosure policies, such as coordinated vulnerability disclosure. Coordinated vulnerability disclosure is premised on the idea that any public disclosure prior to a fix being released unnecessarily exposes users to malicious attacks, and so the vendor should always set the time frame for disclosure.

We used this model of disclosure for over a decade, and the results weren't particularly compelling. Many fixes took over six months to be released, while some of our vulnerability reports went unfixed entirely! We were optimistic that vendors could do better, but we weren't seeing the improvements to internal triage, patch development, testing, and release processes that we knew would provide the most benefit to users.

But why do slow patch timelines matter? If you assume that only the vendor and the reporter have knowledge of the vulnerability, then the issue can be fixed without urgency. However, we increasingly have evidence that attackers are finding (or acquiring) many of the same vulnerabilities that defensive security researchers are reporting.

We can't know for sure when a security bug we have reported has previously been found by an attacker (recent attempts to quantify the rate of bug collision can be found here and here), but we know that it happens regularly enough to factor into our disclosure policy. We think that our policy introduces an appropriate level of urgency into the vulnerability remediation process.

Essentially, disclosure deadlines are a way for security researchers to set expectations and provide a clear incentive for vendors and open source projects to improve their vulnerability remediation efforts. We tried to calibrate our disclosure timeframes to be ambitious, fair, and realistically achievable.

While every vulnerability disclosure policy has certain pros and cons, Project Zero has concluded that a 90-day disclosure deadline policy is currently the best option available for user security. Based on our experiences with using this policy for multiple years across hundreds of vulnerability reports, we can say that we're very satisfied with the results. No one on Project Zero is happy when a deadline is missed, but a consistent and fair approach to enforcing disclosure deadlines goes a long way.

For example, we observed a 40% faster response time from one software vendor when comparing bugs reported against the same target over a 7-year period, while another software vendor doubled the regularity of their security updates in response to our policy.

- Project Zero Vulnerability Disclosure FAQ

from diodb.

I believe so too, to be honest. Just looking at the edge cases, and startups are an edge case.

For instance, being kinda solo maintaining 30+ repositories by myself, I'm not quite sure I'd have the time to fix a vulnerability given 90 days, depending on the impact, priority, scale, difficulty, etc. But that's an edge case.

Even though, in such edge cases, it may still be important not to disclose anything too soon, especially if the company doesn't have the means to fix it, it'd just make things worse, IMHO.

I'm interested in this topic and just created our https://github.com/UnlyEd/Unly terms regarding vulnerabilities, if you have any feedback on it that'd be great! :)

from diodb.

@Vadorequest Looks fine to me. I'm pleased to see nothing in there about 'responsible' disclosure. There's a line I heard somewhere, researchers are going to research whatever they want, regardless of what moral line you may put out there. I agree with just calling it 'Vulnerability Disclosure'.

from diodb.

Well, from my newbie point of view about "disclosure", "responsible disclosure" would be more about how disclosure is done rather than what's being disclosed. What matters is the "how", not the "what". I don't "care" if you report a big security vulnerability that would grant access to massive personal information, or a minor vulnerability, as long as you use proper channels to report those.

Nothing to do with any "moral line", IMHO. But again, not so familiar with the subject.

from diodb.

@JLLeitschuh - Have a look the proposed changes in master...yesnet0-patch-2. The language in the GLOBAL terms is a discretionary disclosure model (which, btw, is nothing to do with alignment of particular platforms or organizations). Dropping public disclosure on organizations which haven't invited it in advanced under a CVD model risks inviting legal recourse for the Finder, which is against the spirit of the project - This adjustment strikes a happy balance and provides (encourages) proactive disclosure deadlines.

from diodb.

This adjustment strikes a happy balance and provides (encourages) proactive disclosure deadlines.

I think it's overly optimistic to say that it encourages anything.

I've read over your proposed changes. I think they make sense.

I've got my opinions, but in the spirit of the project, protecting researchers from being bit, I feel like this is reasonable. I'm still sticking with my policy though.

This is what I'm using currently (in emails and other communication formats):

Responsible Disclosure Policy

This responsible disclosure follows Google's 90-day vulnerability disclosure policy (I'm not an employee of Google, I just like their policy). Full disclosure will occur either at the end of the 90-day deadline or whenever a patch is made widely available, whichever occurs first.

Bug Bounties are appreciated but not expected or required.

from diodb.

@yesnet0 thanks, I'll update my template accordingly.

from diodb.