I worked for a big company that made some really popular networking equipment. Of all people you would expect them to handle security ... fairly ok.

Yet they struggled to get headcount for people to respond to security researchers, and despite having seemingly trained the executives there was a regular "Oh man I contacted legal we should sue this guy!" type email every few months.

Meanwhile they had a separate technical support team who knew how to respond to customers in a timely fashion, make people feel like they're being listened to, but for some reasons they had to reinvent the wheel / fail repeatedly at dealing with security researchers as if nobody had ever done basic customer service before. I was on the support team and I sat next to the security guy(s) and I would show them what to do and how to keep a customer or security researcher on track. It wasn't rocket science, but nobody thought to teach them that.

And that was beyond training engineering to stop with the "well you're using it wrong" type responses.

The scale of, incompetence in the security field is astounding as a lot of folks with security written all over their resume don't know jack squat. And the scale of incompetence just DEALING with security researchers is also bizzaro world terrible, even among companies that should know better.

> security written all over their resume don't know jack squat.

While working in a F500, I found on github the company credentials of a security consultant coming from Thales ... hem

The head of security for Panera Bread seemed to become upset / confused when a security researcher asked about exchanging pgp keys... he worked at Equifax previously.

Par for the course, "security" industry people, especially the higher ups rarely make an effort to secure their communication.

The best you can hope for is they likely use Signal, good luck getting their contact details or verifying keys with them though!

Could it be so because features sell products, not security (yet)?

If their customers (which are not u) and them feel like security is only a cost and not a selling point then they won't work much on it. After all they already sold those products and have orders for more.

I think security just isn't an instinctive priority in most organizations when it comes to engineering operations. Also I don't blame them for the results very often as they're simply not given time / budget to do so very often.

It's a cultural thing that just hasn't taken hold (normally I hate using "cultural" but it seems to fit here).

One solution to this problem is to post a PGP key on your security response web page. Then, whoever reports problems will encrypt the message such that it is only readable by the proper people inside your organization (because they control that PGP key and regular support, suits etc don't)

Certainly for communication that is the right way to go.

Having said that the suits have to be in the loop to some extent, they just need to be able to control those "I don't like this sue them" instincts and understand how to better channel that energy.

Security needs an executive level person to be able to directly work with the other executives to push things if only because the inclination to hide or not fix things is so common. Security just isn't a part of a lot of engineering teams mindset / time budget.

I think it would take at least another 20 years to have people that are really security expert in most of the big companies!

Stuff changes. Today's young Turks, when factoring in the time and energy to get to the point they would be listened to, will have antiquated skills too.

Old people can certainly keep up! But corporate climbers often can't (I do know of exceptions)

Yeah it will be a while. I've spoken to some newly minted security experts that are really good.... and security executives who I swear struggle to operate a computer.

I mean, this seems realistic. Product Security is contacted, the issue goes into some queue somewhere. Eventually it becomes a priority and the correct engineers have to be found to understand the researcher's paper and replicate the issue to their satisfaction.

Here’s what could have happened:

March 20: Confirmation of receipt of issue, boilerplate response detailing expected next steps

And as far as we know, this might have actually happened! Maybe it wasn’t deemed interesting enough to include on that timeline.

It actually does say confirmation of receipt, on March 19 (the same day it was submitted)