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?
- Anybody can ask a question
- Anybody can answer
- The best answers are voted up and rise to the top
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.
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.
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.
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.
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.."
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.