Third Party Code Review?

An Anonymous Coward asks: "It looks like our sale-person is about to land a big contract with a very large US Bank, however there is a large catch in that the bank is demanding that we let them do a full audit on the source code of the software application we are selling them. After the recent rash of identity thefts of credit card and other personal info, they now mandate that all internet facing applications that store potentially private information have to have a full source code audit. This includes software from 3rd party vendors such as my company. They want to run our Java code through some software called Fortify (we looked up the price -- around $80,000) and also do a manual analysis of the code. This software is our company's life-blood. We would be ruined if it fell into a competitor's hands. We aren't storing private information about their customer's; all of the information can be found from government county auditor web sites. I understand their point of view, but it is a very scary step for us to take. Has anyone else done this and how did it work out?"

Comments

NDA

[poopdeville]

Get the bank to sign an NDA, and sue the pants off of them if they leak your source.

Re:NDA

[mikaelhg]

That's why you use RetroGuard or some other such product on your application before giving out your JARs anywhere, if you really think that a source leak of this kind would have any real effect.

Re:Security with closed and open source

[iMaple]

* Closed source is proven to be far more secure in the real world than source that has been picked through by numerous people.

OK, this is flamebait,

Well the gp wasnt flamebait but funny :) lighten up.

Code Auditing

[crmartin]

I've done quite a lot of this over the years, and I can see how you'd find it scary. here's the key things:

* get a good tight NDA from the auditors
* get a well-respected firm to do it, one that has something to lose. Someone like Ernst-Young.
* insist on it being done on your site, and that you receive all work products at the end of the audit. This won't keep someone from walking off with a copy of the code anyway (not when you can buy a 2 gig USB key for a hundred bucks) but will strengthen your case if anything does get pirated.
* Look for a firm that doesn't have a software business in your area of expertise. You don't need to be buildign bank apps to audit the code; if you pick someone who doesn't have bank apps in their product line, and they suddenly start some after the audit, you'll have a good hint that there's a balrog in the woodpile.

Sarbanes-Oxley

[mwvdlee]

The whole Sarbanes-Oxley regulations really leave the bank (or any financial institution) with little choice; they are legally required to guarantee the security and accountability of their systems, without being able to audit your code, they cannot give such guarantee and thus cannot use your system whilst still following Sarbanes-Oxley regulations.

So you've only got two choices: "Let them audit the code" or "Lose a customer".

FYI, I work as a programmer at a bank.

Things to consider

[Sven Tuerpe]

I work for a lab that does seurity reviews and evaluations. There are a few things you might want to consider:

• There is nothing wrong with the bank's request. Think of it as additional quality assurance: your customer requests that your product provides a certain level of quality, and that you prove that.
• Having the security of your product certified in whichever way can gain you a considerable advantage in the market. Make sure that after successfully passing the review you get some written document that certifies the evaluation and can be used elsewhere.
• If you do not fully trust your customer, involve an independent party. Check whether your customer would accept a review by someone else if properly documented.
• Plan ahead for worst case. Everyone makes mistakes so the review may find issues. Make sure that you can fix them and reevaluate.
• If your company does not employ mature development processes and quality assurance, don't even think about passing a code review.
• As pointed out by others already, not handing over the source code may not really protect you. One can find out a lot about the inner workings of a system even in a black-box test, and there is no effective protection against reverse engineering.
• There may be easier places to steal your source code than a properly operated security lab. Make sure that the security precautions of whoever is going to review your software match those of your own company. You do have security management, don't you?
• If you really don't like to hand over the source code to anybody, there may be an alternative: indemnify your customer against all damages that may emerge from security issues in your product. This may be costly, though.