Sony was recently hacked with a SQL injection and the passwords of their user's was stored in plain text. These are rookie mistakes. In such a large company, how does this pass QA? How do they not have better teams than to know better than this?

The sheer size of the company that was hacked makes this different. It affects all of us because we all may one day find ourselves on a team that is responsible for something like this, and then we get the ax. So what are the factors that lead to this, and how do we prevent them?

  • This question has not invited constructive answers based on facts and references: it's a list of various speculations about how crappy a company Sony is. See the related question sidebar for several questions about steps to deal with SQL injections, QA, and security. (Apologies for clearing the close vote count: there were 3 "not constructive" close votes when I accidentally closed it for the wrong reason)
    – user8
    Commented Jun 4, 2011 at 4:42
  • Commenters: comments are meant for seeking clarification, not for extended discussion. If you'd like to discuss this question with others, please use chat. See the FAQ for more information.
    – user8
    Commented Jun 4, 2011 at 4:42
  • 4
    @Mark Odd, it has garnered some wildly constructive answers, which are probably very close to the mark. That said, a better question would be, “why is there no legislation in place to punish such a reckless behaviour in such a big corporation?” Commented Jun 4, 2011 at 15:56
  • 3
    It is rather odd that this question got closed again. Draconian. Again.
    – richard
    Commented Jun 4, 2011 at 19:04

6 Answers 6


First thing that comes to mind is, because they're big enough to grow a few layers of bureaucracy. This means, among other things, that you no longer have really smart coders in charge of the hiring process, which means they lose their ability to weed out potential programmers and QA people who are incompetent. Which leads to bad code getting written and making it into production, and we all know what happens next...

  • 3
    I think you hit the nail on the head with bureaucracy, but there are also other problems stemming from it. If you have a smart developer who spots a significant problem, it takes an act of God to get approval to work on a fix, get it tested, and move it to production. All it takes is for one person in the bureaucracy to think that the risk of making the change (delays in other projects, production errors, etc.) outweighs the risk of not making the change (who could hack a company this large?).
    – Mayo
    Commented Jun 3, 2011 at 21:51

Because the programmers weren't told to test for that and the crushing corporate culture didn't give them enough leeway to have their sense of professional ethics kick in and demand another couple of weeks to test for security vulnerabilities. Or to insist that they be secure from the start.

Because the boss didn't want to spend a couple of extra weeks testing for security issues for... whatever reason. An extra bonus at the end of the year. Showing up Johnson from the next department. Bragging rights. Duty to the company. Laziness. Distrust of underling's advice.

Because the big boss demanded more profit and promoted Johnson over Bob because his numbers looked better as opposed to demanding a better product. Because quality and security are difficult values to display on a spreadsheet. Because corporations exist to make money.

Things like this are a systematic problem. It boils down to "because they're fools".

Edit Programmers can avoid being the sacrificial goat by, upon noticing a deficiency, bring up the issue to their boss. He'll either do the right thing and make a plan to fix it, or tell you to ignore it. If he doesn't fix it, make it official, ask about it in e-mail. Use keywords pertanent to the issue, like "vulnerability", "injection", "security breach" in this case. Stuff that an email search would pick up.

This is passing the buck. It's now your bosses responsibility. If it's important, like people are going to die when this thing fails, go over his head and bring up the issue to his boss. You can get fired for merely passing the buck, and you can still get fired even if you do pass it on, but it's the right thing to do. Not quite as right as actually fixing the problem, but close.

  • 3
    My vote for you as CEO of the company!!!
    – Wajih
    Commented Jun 3, 2011 at 16:36
  • 3
    @Cheshire It wasn't "common sense" when it was first done. People are not inherently security-minded; they have to learn and constantly be reminded that there are evil jerks out there that only exist to grab your data. Commented Jun 3, 2011 at 16:51
  • 3
    @Michael Todd: But this isn't 1996 any more. This is common sense now, and there's no excuse for it.
    – richard
    Commented Jun 3, 2011 at 17:09
  • 1
    @Cheshire Agreed. And developing with security in mind is vastly better then testing for it afterwards.
    – Philip
    Commented Jun 3, 2011 at 17:59
  • 1
    @Richard DesLonde: If it were common sense, I think I'd be seeing fewer people saying to do it right. Commented Jun 3, 2011 at 21:35

The bigger the corporation, farther away the decision makers are from any real-life responsibility.

Knowing how corporations work, the site design was probably outsourced to some consulting company chosen based on the lowest price per developer. That company would in turn hire bunch of random people on similar criteria, with average person staying on the project for not more than 3 months before being rotated to something else.

  • 4
    +1 for outsourced. I hadn't thought of that. When you offshore, the developers develop exactly what you spec out, no questions asked, so maybe security wasn't in the spec.
    – richard
    Commented Jun 3, 2011 at 16:25
  • 1
    @Richard DesLonde: I see you're an optimist. Commented Jun 3, 2011 at 17:04
  • @David Thornley: No, just experienced. :-)
    – richard
    Commented Jun 3, 2011 at 17:05
  • 2
    @Richard DesLonde: And all of your offshored projects came in doing everything the spec said? Not bad. Commented Jun 3, 2011 at 17:15
  • 1
    @David Thornley: LOL Absolutely not. That wasn't the part I was emphasizing. You are definitely right, that was a bit too optimistic. :-)
    – richard
    Commented Jun 3, 2011 at 17:16

How does anyone make mistakes? Through laziness, lack of knowledge, lack of expertise, expedience, lack of process, etc. How do we prevent mistakes? Through diligence, experience, safeguards, etc. This situation is no different categorically from the thousands of small mistakes made by every programmer; it's only different in scale.

What can we learn from this? Not much.

  • I think it is different. Sony makes billions of dollars and yet they can't get these basic things right? There's something seriously wrong with that. And it's not just Sony. Many big companies have been hacked by SQL injection recently.
    – richard
    Commented Jun 3, 2011 at 16:29
  • 1
    No, it's really not different. Decisions are made by people, not by companies. Commented Jun 3, 2011 at 16:31
  • @Richard: They've always had a bad security record. This is the same company that invented the Sony rootkit, remember? Commented Jun 3, 2011 at 16:32

One possible explanation is a skewed priority list. Many companies that I've worked with have placed more importance on getting a product to market, rather than the quality of the product/code they were producing. This effect is doubled because not only are the programmers rushed to completion, but so is the QA department (if they even have one). I've also noticed that this attitude coincides with pushing on to the next product before the prior was completed, compounding the problem even farther.

One common denominator in each of these companies has been non-technical management. Project Managers, IT Managers, and Product Managers, basically everyone with a say in what the development team works on, are all non-technical and don't understand the importance of producing high quality, secure, code. This is something that I look for when I interview with companies now. Who holds the reigns to the asylum, the inmates or the doctors?

I would not be surprised if something similar, compounded by deep bureaucracy, were contributing factors in Sony and other company's security issues.


People work in big companies, and people will make mistakes, being it out of ignorance, laziness, bad procedures, bad documentation, etc. The size of the company will only affect mistakes in that there can be more sources of errors or mistakes.

Not the answer you're looking for? Browse other questions tagged or ask your own question.