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:It they steal your code

[Anonymous Coward]

Wrong product.

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.

Re:It ain't windows.

[Anonymous Coward]

Acutally its called R/3, and you do have the source code for it. Its delivered with the system (many millions of lines of ABAP source code), as are the development tools, debugger, api documentation and everything!

Let me clarify - the source code for the kernel is not included - but for the bits that you would actually care about, the business applications that run your company, the full source code is there in the system. The first time you access a transcation after an upgrade you can sometimes see the little 'compiling' message in the status bar...

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.

Re:What does Fortify do, anyway?

[Anonymous Coward]

The main issues in Java are going to be logic errors and misimplementing security protocols. Things like bad packet handling in a network server. There is NO WAY an automated system can detect problems like this: it is the Halting Problem.

I think a lot of people get confused about how the halting problem applies to real world software engineering. The halting problem proves that you can't determine if a program halts with 100% accuracy. However, you could write a program that estimates if a program halts, and then work on making the accuracy better and better. If you could build something that is correct 98% of the time, that might turn out to be useful enough that people would pay money for it, even though many slashdotters would complain that it's a scam.

Banks and other big companies aren't stupid. They're really good at making money. Fixing bugs, especially security bugs, after software has shipped or gone live on the internet is extremely expensive. So these security products must be finding actual problems and giving a good ROI or I doubt they would be dishing out $80k.