Comment by spijdar
4 years ago
Thanks for the clarification/correction.
I have just one more thought on the matter. I'm still early in my career, but in the years I've spent so far working with small business-types on security, and watching my colleagues, a month and a half is practically no time at all. I have little love for the big vendors, especially for behavior like this, but the reality I've seen is they often take months to do anything, and it takes further months for customers to actually patch their systems.
So I'm a little sympathetic to the desire to have an embargo of half a year or even longer, even with the downsides mentioned. Still, Theo clearly didn't actually breach his trust with Mathy, that's my mistake.
> a month and a half is practically no time at all
A month and a half is plenty of time, but it requires (1) the company decides that fixing security bugs is top priority. (2) They need a senior engineer or two on hand who are smart enough to understand the issues involved and implement a fix. And (3) They need a decent release process which allows security fixes to be promptly rolled out to users.
I’m not sure where most companies fail here. It’s certainly easy to downplay and deprioritize security fixes from the inside, when you have a big deadline coming up, or your customers are yelling at you or a refactor is blocking other people from doing their job. Security issues from the inside never feel like the “all hands on deck” emergency situations that security researchers believe them to be. (And I’m not sure if this is right or wrong, just, the experience I’ve always had from the ground when security issues potentially affected us.)
The best way to get vendors to make security a priority is to not perpetually coddle them. At this point in time if a vendor cant react to something in under a month in a half that's more on them than the rest of us.
If anything the security community should be steadily decreasing the amount of embargo time. I wouldn't be opposed to different classes/criticality of vulnerabilities having different timelines. But for vulnerabilities where everyone's collective ass is proverbially hanging out there the times should be VERY short.
Oh, I 100% agree. The companies are more than capable of preparing fixes in that time. I meant from the perspective of the end user businesses, even if they prioritize the patches (which isn't a given) these vendors take ages to fix anything.
And I mean, that's a part of why you release these vulnerabilities publicly anyway, to pressure them into fixing their crap. I just worry a bit that if the window is too small, they'll just shrug their shoulders and put out a PR piece about how the vuln isn't actually that big a deal or something.
IME they fail at all 3.
IME, the most common reason for delaying fixes are due to organizational dysfunction, not technical complexity. You can spend a lot of time arguing whose job it is to make the fix, what the best way to make the fix is, what sprint it all should go into, and are you sure it's not team Y that really should change their code to deal with this? Let's meet to discuss that..