[rapind]

I hear this attitude a lot and it always rubs me the wrong way.

It's a corporation... Why should he care about it's feelings? What does he owe CircleCI? Are they paying him? What claim do they have to his time to jump through their hoops / process?

I'm positive in this case that they weren't intentionally messing with people's security, but shouldn't we and their customers be able to judge that ourselves instead of getting it swept under the carpet via private channels?

I do believe it's good practice to "not be a douche", especially at a personal level, but I wouldn't even come close to categorizing this as douche behaviour.

* Note: this comment is not actually directed at CircleCI, just the attitude that we all somehow owe it to companies to tell them about their goofs privately.

[ukd1]

This is, imho, douche behavior when it's the accepted norm to approach a company through their (listed and public!) security page. Why? So they can fix things before they get fucked. Yes of course you don't actually have to, but that makes you a douche imho.

Also, it's not swept under the carpet - it ends up usually getting $ for the reporter and a better story as they'd also know how the company fixed it. If they refuse to fix, then publish away.

https://en.wikipedia.org/wiki/Responsible_disclosure

[kevinburke]

That would have been appropriate if I had found e.g. an endpoint that did not accept CSRF tokens, or a vulnerability in Ring. It's not appropriate when the problem is they made a business decision to expose my source code to Quora.js.

[otterley]

How do you know it was a conscious decision, as opposed to ordinary human oversight? As the old saying goes, never ascribe to malice what can be adequately ascribed to incompetence. (Though I wouldn't go so far as to call CircleCI "incompetent" -- security issues are rampant in this industry, despite everyone's best efforts.)

[rapind]

I'd say it's more of a tossup. I mean they write software for people who write software.

I think we can rule out a malicious decision regardless though. I'd wager if it was flagged by the annoyingly pedantic but super smart developer, then it's still sitting in their Trello board buried under a few hundred features that were considered a higher priority by the product manager. In this case, the decision felt mostly harmless.

Or yeah, probably just as likely that no one noticed.

[michaelbuckbee]

It's rarely about the company and much more about those affected by a potential issue. This issue's a little different as it's the potential for a vulnerability more than an actual vulnerability.

A typical case for responsible disclosure is something like a bug in Apache or Nginx that's serious and if a security issue is found that they're given time to address it. So when they make an announcement its:

1. Here is the issue

and

2. Here is the fix

Instead of just spreading and publicizing a vulnerability.

[rapind]

I'm mostly with you when there's potential damage to their customers, especially when those customers are individuals (like a database of social profiles being compromised), which was not the case here. However I think saying it's "rarely" about the company is a bit naive.

There's been some really high profile breaches where the extent of the impact to the customer has taken an unacceptably long time to be made public... which results in increased fallout damage.

A company's natural inclination is going to be to minimize losses (generalizing of course), and that often means dragging their feet, or dealing with it privately and never notifying their customers.

We should recognize these incentives and be a bit more aggressive about holding their feet to the fire, instead of criticizing the researcher who discovers the security flaw. Unless of course his / her behaviour is blatantly malicious.

It anecdotally feels a bit lopsided in favour of the corporations at the moment. Especially when someone like in this post, who clearly didn't endanger any customers, gets criticized...

[ukd1]

^ this