Yes, I would say so.. especially since this is a 'duplicate' meaning that multiple people were already aware of this, and on top of that it seems the only reason it was eventually fixed was because they couldn't delay fixing the problem any more.
I don't think anyone would consider this reasonable.
Then again, how hard is it for a company of their size to hire some 1099's for a brief time...
I think the guys over at US could work a bit faster, but I will grant them they aren't exactly in an unregulated industry where they can "challenge the status quo". When kalanick bears down on the red tape, people aren't reminded that taxis were the attack vector of America's biggest security event.
But yeah, out-source it to one of the hundred or so DoD contractors or security professionals allowed to work on something like this, it likely wasn't that big of a job to patch that vuln.
I'll bet you a nickel that the json is generated by a stored procedure. In that kind of environment, you can't really run a local version of the system. if you're lucky there's a prod, qa, and development version. the development version is shared by everybody.
What winds up happening is the dev system has lots of in-progress stuff, and i can't release my stuff till the other in-progress stuff is ready to go, or is rolled back.
Also high priority stuff tends to go to "that one wizard guy". Unfortunately that one wizard guy is backed up with 6 months of other projects, cause he's the wizard.
Is it "right"? no, of course not. These systems evolve from people making good decisions in the moment, that don't really take into account the global state of the system.
Finally, every few years a new CIO comes into power and wants to clean things up. a few new folks buy in, but the older entrenched interests just pay lip service, because they know the only way to actually get software out the door is to do it their way. (They tried and were burned by at least one of the prior CIO approaches)
I think those organizations are pretty screwed. they are incapable of change at the layer they need. Banks, schools, airlines, machine shops, anyplace there's a large sized in house dev team (30+), that team is going to very likely kind of suck. There are exceptions, but generally, it's a rough state.
So, yes, i agree, but actually solving that problem in a way that won't kill the business is incredibly hard.
I'm not saying these companies need to magically become less bloated, but they do need fix security problems with the urgency they require. If that means that we all need to make a stink so it starts actually seeming important to them, then so be it. Another way to look at this is that they've reaped the benefit of having a web presence for years, but haven't had to pay some of the associated costs (since they apparently don't have the internal structure in place to review and/or fix these problems). In that respect, they've been playing the odds for a long time and come out ahead (wittingly or not), but that doesn't mean they don't need to pay up when it bites them in the ass.
1. They don't have a formal QA process or an independent QA team.
2. They don't have source control (or it's very rudimentary, like storing ZIP backups of source code on a network server).
3. Their issue tracking system is an excel sheet on a shared drive.
4. 75%+ of the code was written by someone not currently working for the company. 10%+ of the code is considered "untouchable" because it works and nobody remaining knows how it works.
5. Compiling the final executable takes more than 1 manual step, resulting in screens full of compiler warnings.
6. Management is resistant to any effort to fix any of the above because software is a COST and not an investment.
(EDITed because I can't seem to count to 6)
It's just so damn hard to get people to change.
Which is why there needs to be pressure on management.
it's not pilots and flight attendants coding that application. they've got an IT department whose bread and butter IS releasing software.
I don't think you've dealt with UA much...
I am not saying delaying a critical vulnerability patch for 6 months is right, but I think airline systems will typically need that much time to plan it well.
On the bug difficulty totem pole, this one hangs rather low. Hell, they even claimed it was a duplicate report.
I'm surprised the newspaper didn't run the story anyways, because on a data leak bug like this the work isn't done when you patched the original problem, only when you have combed through all the application logs, identified malicious requests and notified customers and authorities of possible leaks can you claim to have dealt with the issue at hand.
(Yes, if your app server isn't logging all requests, you should probably start today, otherwise you end up like the NSA when Snowden took off and you first learn of lost data when it appears in a newspaper)
It's unreasonable for anyone, no matter how big and bureaucratic they are. The fact that they're bloated and incompetent doesn't excuse their incompetence.