Being the creator of a program, you are probably in a better position than anyone to be aware of security vulnerabilities and potential hacks. If you know of a vulnerability in a system you wrote, is that a sign that increased security MUST be added before release, or should this be evaluated on a case by case basis to determine the severity of the security gap?

  • 7
    Sure, the NSA does this all the time :)
    – Jaap
    Commented May 31, 2011 at 19:39
  • 3
    @Jaap: The NSA gets accused of this all the time. In the one case I'm aware of where people found out what really went on, that being the DES encryption standard, it turns out the NSA's modifications actually made the encryption stronger, not weaker, making it less likely to be hacked by a technique that nobody but the NSA had even discovered yet, because they knew that someone else would figure it out eventually. Commented Mar 14, 2012 at 17:17
  • 6
    @MasonWheeler I think recent events have made your comment, here from 2012, out of date. Commented Mar 20, 2014 at 12:56

5 Answers 5


I would say it should be done on a case-by-case basis. You are the author, you know many of the holes. Some vulnerabilities might only be known to you. Of course that means that if any of them are exploited, you might have some difficult questions to answer so it might be a good idea to reduce these vulnerabilities if possible. More important is if someone can easily hack it as a blackbox system.

  • 3
    I only wish I knew all the holes in software I wrote. Then I could leverage that to find all the bugs, and it would be much easier to get the stuff properly written. Commented May 31, 2011 at 18:40
  • 1
    @David: Ok, many... Commented May 31, 2011 at 18:42

I've had the unfortunate experience of being in the situation twice. The business in both cases were putting out products with serious security problems with very sensitive data.

In both cases the business did not seem to care, despite my best efforts to make them aware of the risks that they were taking.

The only thing you can do is protest as loudly *(and professionally) as possible, being as clear as you can about the potential consequences, and while you are doing that document everything. Print out your relevant emails to PDFs and keep those files at home, or bcc your personal email address, or however you do it. This is the only solution for when something bad inevitably happens.

You would hope that management would respect you for your technical advice, and take that into account but unfortunately, you have to respect whoever the decision maker is at the end of the day. Bad business decisions are made every day.

Edit: jasonk mentioned "Please be very careful BCCing your home address", and I very much agree. Please do not violate company policy, and risk putting the security vulnerability more out in the open than it already is.

  • 21
    +1 for DOCUMENT EVERYTHING!!! When a major disaster occurs and the manager's job is on the line, he/she will do ANYTHING to shift blame in ANY way they can. If you document issues, emails, notifications, memos and other documentation related to the decision then you are protecting yourself from a bad situation.
    – maple_shaft
    Commented May 31, 2011 at 18:31
  • 11
    A-fcking-men. Anyone sleazy enough to knowingly ship seriously defective product can, and will, do *anything to dodge the eventual bullet. Commented May 31, 2011 at 19:18
  • Please be very careful BCCing your home address.
    – jasonk
    Commented Mar 14, 2012 at 2:22
  • 2
    @jasonk: Why do you say that? BCC means other recipients can't see it... Commented Mar 14, 2012 at 17:23
  • 3
    @Mason: The recipients can't, but IT can, and if you're sending sensitive information (which security vulnerabilities most definitely are) offsite, you are likely to get into a world of hurt.
    – Eclipse
    Commented Mar 14, 2012 at 18:17

I'd argue the opposite - being the creator, you're frequently too close to the code to see vulnerabilities.

If you know or are told about vulnerabilities, they're like any other bug - evaluate, prioritise, then fix.

  • +1: You know how my program should work and to an extent only think about using it like that. Having someone who doesn't know the "correct" way to use the program is one of the best tests you can do. Commented May 31, 2011 at 18:41
  • As someone relatively new to QA, I came into the work expecting "security flaw" bugs to be met with extreme gravity. But I've found that the label "security" doesn't always constitute a need for a zero-tolerance response. Some companies are perfectly happy to take security risks if the vulnerability doesn't appear to endanger the brand reputation, or offers hackers little to gain, and future releases are likely to include a fix (or feature change) anyway. Commented May 31, 2011 at 19:10

I think the answer depends on the degree of harm that would come about if the system were compromised by a malicious hacker. Obviously a civil engineer could not approve the design of an unsafe bridge in good conscience. The construction of such a bridge could result in injury or death. It would also be illegal for the engineer to knowingly do this, but the fact that software engineers (at least in the USA) are not legally bound in the same way does not absolve them of the professional duty to take a stand against faulty systems. Unfortunately, your company may not need your signature to release the software.

You don't specify the exact nature of the system you're working on. If it's related to medical records, banking, air traffic control, or some other really critical infrastructure, I'd say you'd be well-justified in insisting on the highest level of security possible before release.

  • +1 For context, I would add that any data which includes social security numbers, identification numbers, or credit card numbers should also have attention to security. Systems that don't store any of this information and are not critical systems have low risk data and you wouldn't need to worry about security as much.
    – maple_shaft
    Commented Jun 1, 2011 at 11:07

Yes you SHOULD fix it before the release goes out. Never underestimate the ingenuity of a hacker. Would you go on vacation for a week with your back door hanging wide open? Would your excuse be,

"Oh its in the back and it doesn't face the street directly. Nobody would see it hanging wide open.."

Probably not.

But I do understand these days with the clueless PM how the most sacred release date is more important than a potentially huge liability issue with security. If this is your case then I suggest calling it to attention, log the issue, make sure it is well documented, well known and the risks clearly explained and let the PM decide what to do.

If the PM makes a poor decision and decides to ignore this and go ahead with release on schedule then you are absolved of responsibility since you blew the whistle.

Otherwise if you find this and keep it to yourself and something happens then YOU can be personally held responsible for the consequences.

The choice is yours.

  • 4
    In the US, at least, it isn't a potentially huge liability issue, because approximately no software comes with any sort of guarantee. Medical device software is an exception, and there are probably others, but most software and software-based services are essentially on a "no guarantees" basis. Commented May 31, 2011 at 18:39
  • 1
    No guarantee? Why don't you tell that to the millions of Sony customers who had their social security numbers and other sensitive data stolen because of EXACTLY such security holes as the OP is suggesting.
    – maple_shaft
    Commented May 31, 2011 at 18:45
  • 2
    While David is correct, the lack of enforceable civil liability may be cold comfort when your company's reputation is ruined, or your small firm is simply litigated out of existence by a larger one. Commented May 31, 2011 at 19:22
  • @maple_shaft: And what liability does Sony have? They've offered a year of credit protection services, but I don't think they have any legal liability. It is a hit to their reputation, but they've survived such before. Commented May 31, 2011 at 20:29
  • 1
    @Rory: Let's look at it two years from now. I'd like to think that the rootkit fiasco, the arbitrary removal of OtherOS, and this leak would make Sony less popular in the long run, but I'm not at all confident. Commented Jun 1, 2011 at 15:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.