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.

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.