To Whistle Blow or not to blow, that is the question

I would.

I imagine there is a lot of money on the line.

 

Maybe I misread, but this seems kind of important and mentioned nowhere else. Just kind of slipped in at the end.

Did you somehow certify that it was uncrackable or something? The whole thing was a little vague (for obvious reasons) so if I missed it, I apologize. Do you have some perceived personal liability if the dude cracks it?

 

Is the "database" centrally hosted or are there multiple instances hosted in house at client locations? What types of data is exposed? Is your product under any regulations / compliances?

What do you mean "crack" a table? Are the friends company employees?

 

I wasn't sure if the desktop app connected back to a centrally hosted database. The reason I asked was to define security parameters and boundaries. Since this is a locally installed application with a local database, it sounds like its an issue that any customer could also take advantage of. So at the least, I'm assuming that bugfix (or whatever term you use) would be registered.

From you description I don't see malicious intent. Without the exact details its hard to determine this; example : is this as simple as viewing tables in MSSQL/MYSQL/10G or breaking a proprietary DB platform.

The first thing I do is look at the database structure of an enterprise application. The company that I work for doesn't lock users out application databases, neither does Microsoft with enterprise applications, neither does SAP, neither does Oracle/PeopleSoft (at least for the apps I play with).

 

I think it really depends on how brave you are.

When a merger happens, you should know what comes next. Laid off.

To me what they are doing is to protect their positions while making sure it's you guys who will get the boot when the management says there is overlapping and stuffs like that.

I don't think they are trying to really understand your product, just trying to prove your product is not secure enough to be published to the market since they already have something similar in the pipeline.

The thing is, if you blow the whistle, will you get the support... it happens that many people are so dumb and short sighted to NOT see **** coming at them until too late or they actually got some kind of deals secured behind everyone's back so they never cared and actually will kill the whistle blower if there is one pop up.

I am regret to say you are in a very ****ty situation... my advice would be take your chance no matter what you end up decide to do, make sure protect yourself first. If I were you I would look for another job immediately (be one step ahead of them either way), because your owner/higher ups probably already god paid handsomely for the merger and ready to bring down the knife to you guys anyways. No one really cares about company to be honest these days... I've seen my fair share of **** in my own company but because it involves ppl in quite high up I ended up just swallow it because I observed more and found out the whole circle of gangs are much more than I can handle. I also lost trust to HR in the way. The anonymous reporting system shouldn't require my employee number too. Thank god I no longer work in that dept.

Let's hope I am totally wrong.

 

There's no ethics hotline? If you did not already confront / discuss this with someone, you could have reported it anonymously.

 

ps Based on my observations, HR will protect the interests of the person / entity that earns the most money. (Makes sense if the company has to settle down the road.)

 

I think I would very privately consult your company's legal council and let them do any further whistle blowing. Not only will they understand more of the legal relationship of the merger, they can go directly to the top executives if warranted, and you keep a degree of anonymity.


" very privately" = no email, no recorded messages.

 

It looks your software has security holes. If you expose that why would they keep the original team around if the new guys are better?

 

so then you should alert whoever necessary that there is a lack of security and are 'just doing your job'

It sounds like you want to blow so you need to make sure you are looking at the whole picture in terms of evidence and what can and can't be proved later. Keep good notes as you will forget. I was just involved in a court case and I can tell you 2 years later they are looking at facts and evidence only. Dates and timelines along with hearsay but mainly just the facts ma'am.

So if you expose this weakness the guy that can steal is your boss? I understand there is a merger but ultimately you are the guy banging on the code and reporting issues as they arises. Isn't it due diligence to report?

If you report how is it going to affect overall merger and corporate standing negatively? Why would you be fired?

Isn't it a good thing to know there is an open ended-ness that needs to be closed to all.. not just this dude?

you can talk about this more without being so vague. This is almost as confusing all the cfnet game.

 

I recommend consulting Julian Assange regarding this matter. He will know what to do.

 

Y'all don't have trouble tickets you can file with respect to your company's software? If we found any security problem in our software we would immediately file a problem report and label it critical. It then gets reviewed by the responsible manager and assigned to a specific programmer to investigate/resolve. It has exposure throughout the entire company and is there for everyone to see.

 

I'm not entirely clear on the scenario, but it seems to me that the other programmer should not have access to the database. So, the first issue to resolve is whether or not he should. If he shouldn't, then his access should be revoked.

If he his permitted access to the application, then I don't see an issue with his trying to access the data within.

Why does he have access to production data worth $100M in the first place? If there was some legitimate reason to be looking at the application, surely this could have been done with a development/test database that has been scrubbed.