Hacker News new | ask | show | jobs
by blktiger 3189 days ago
Why didn't you fix it? (I don't mean this harshly, just curious.)

Ultimately, this kind of stuff is something IMO a professional programmer should just do. It's irresponsible to let stuff like this go and you should do whatever it takes to make management understand. In a healthy organization it shouldn't even be questioned by management, you just tell them you found a security issue that will cost the company billions and has to be fixed immediately. In an unhealthy organization, maybe you just slip this into some other work without telling management.

5 comments

Not to sound patronizing, but you've clearly never worked in a large enterprise.

Teams are siloed. Code is siloed. The deployment process is siloed. Etc.

Do I know where the code lives? If I do, do I -have access to the code-? Write, as well as read? Will my checking in code trigger a huge change review process that will cause people to yell at me for touching code I'm not in charge of? Will my checked in code be picked up as part of what goes to prod? If not, do I have a way to get the code into that process? Etc.

Very few companies of that scale are just a "check the code out, fix it, create a pull request, and watch it work its way into prod".

Not even a large enterprise, just anywhere there's any sort of formal process. Very, very few companies outside a startup with a single product+handful of employees are able to just make code changes like that all willy nilly. Especially to something as sensitive as authentication.

It's like saying "why didn't the NASA engineers just fix the o-rings on the Space Shuttle Challenger? After all, they knew there was problems with them and people's lives were ask risk." They did what they could, which was this: http://www.lettersofnote.com/2009/10/result-would-be-catastr...

Well, you can have a formal process that allows contributions from anyone, which is what I was trying to allude to with "watch it work its way into prod". But I agree, generally speaking if you have a formal process, and you're not on the team, and/or can't convince a product owner of the need, there is no way to get it done.
I worked at Garmin previously which is definitely a big company. On my team I don't think I'd have had trouble convincing management that it needs to be done or otherwise been able to sneak it into other work. I'm concerned that as a profession we're too accepting of "well management won't let me do it" even when the consequences are high. To me it feels like designing a bridge that will collapse and kill people just because your manager said to.
Great question, and in the end it comes down to politics and team siloing. A large corporation with a lot of projects and priorities, and no single Security person to raise the issue with. At the time I wasn't in a position to Just Do It and then tell everyone "Hey, this needed to be done, I got it done, now I need a QA resource to test it and then we need to deploy it to prod" without some backlash from multiple source (my boss, the team that owned the product, etc).

Now (and given everything that's happened in the industry in recent years) I would definitely push more, and maybe fix it on my own, but at the time I just shook my head, and sent follow-up emails every few months to try to keep visibility on the issue.

Negatory. I vividly remember being chewed out at a mega-company for even downloading the source code to `touch`. Yes, touch.

Obviously I got out of that environment pretty quickly, but you're not in a position to just do things at big companies. Probably most of them.

At many big-ish companies, you're not allowed to work on codebases not in your jurisdiction.
At large companies with politics and bureaucracies you can't really just come in and create a PR for a bug you've found like you'd do in a smaller shop or a startup.

If the code is not responsibility of you (your team / department) all you can do is create work requests / JIRA tickets for people/team responsible for the code.

You wouldn't even have access to the repository or dev/test environments for the affected system most likely.

And it might just sit there for months until it eventually gets picked up and fixed. Or it will never be fixed.