Slashdot Mirror
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?"
then it sounds like you are in the business of selling disks with programs on them. in that case, you're already sunk. you need to move NOW to a model where you make your money deploying and supporting software.
show them the bleeding source code, you pansy.
This is why your company has lawyers.
Handing over the source code should be part and parcel of any non-retail software package. Like Free Software, but without all the philosophical bullshit.
Get the bank to sign an NDA, and sue the pants off of them if they leak your source.
After all, I am strangely colored.
You'll sue. You'll win. You'll be fine. Your competitor will be ruined. The person who leaked the code will be ruined.
As for the use of a $80k code audit tool. If the bank's paying for it, that's how it's going to happen. BTW, expensive niche software companies don't always like it when their quotes become public knowledge. Companies like that often try to guess what each customer is willing to pay, within reason.
I was almost sympathetic until I re-read:
.. )
... "
very large US bank
What, pray tell did you expect? It looks as though you blundered into a pot of gold and kept going despite the fact that you're not large enough yet to carry it away.
Of course they'd demand third party review. I hope *my* bank would! What I also don't see mentioned is any mention of a three inch NDA that would be signed.
Established companies like Microsoft can sell stuff with some (or all) of the hood welded shut. They are an authority. They dictate who our browsers trust. They're huge and they could afford to pay for resulting damages (good luck pinning any on them
If you really want to use this as a spring board I'd let them have at the code. Unless you're in the middle of an "Oh SHIT we gotta re-code all that GPL stuff we used
Why would you worry if there wasn't anything to worry about? And why risk your "life's blood" on one single venture?
Order happy meal first. Big mac later.
Off my soapbox.
Non Disclosure Agreements and Really Good Lawyers, that's what it's all about. And if you think it's too much of a risk, just turn the job down. Big fat contracts are look appealing when they arrive on your doorstep, but if they come with massive provisions which are too risky for your business then don't be scared in turning them down. Especially when it's your business, your life and your way of thinking/sanity which is exposed.
Of course, there is the bargaining position of if they are really in need of your software, then you could be in a good position to strike up a trust and maybe negotiate your way out of being audited.
I've done a few defence contracts where they've demanded the same type of auditing, and in a few I've managed to get out of the auditing process for non-mission-critical systems by negotiation.
Task Mangler
The only thing missing is the names of local variables and the comments. If you're distributing your program unobsfucated (and studies have shown that 99% of companies do) then they already have your source code.
How we know is more important than what we know.
I'm assuming the bank and its software is running on a closed operating system, like Windows. Does this bank require source code from Microsoft?
The system will fail security at its weakest link, whether it be your banking software or the operating system it runs on.
All my liberal friends think I'm a conservative, all my conservative friends think I'm a liberal.
As others have pointed out just get a really good NDA (which I'm sure the bank has probably already insisted on anyhow). The benefit of 3rd party code review is that they just might actually turn up a vulnerability in your software. This is just like having someone pay you to help you validate your software. At the end of this you can say your software has been validated by Fortify.
Author of Enyo: Up and Running from O'Reilly Media
OK, this is flamebait, but what the hell. It annoys me when people claim something is proven, without actually supplying any proof.
As a thought experiment, try this out. Start off with a software project that forks into two branches. One branch is developed with an open source model. The other branch becomes closed source. Assume that the original software project had a certain number of bugs. Now I ask you, as time goes on, which branch would contain less bugs? The closed source, or the open source?
It seems obvious to me that the open source project would quickly have its bugs fixed, because of two reasons. The coders on the project would have ego on the line, and would therefore be much more careful with publicly available code. Due to the immense availability of peer review, issues are discovered and reported much more quickly and thoroughly.
It also seems obvious that the closed source project would have many more bugs, for many different reasons. Programmers are more likely to ignore issues, because "nobody can see it". The pressure of getting a release out means that things are quickly cobbled together without much thought for security. If there is a review of code, it is not likely to be as thorough as what is available to open source.
If the code is hidden, a program is not more secure. Otherwise, how do you explain the numerous security issues found in closed source software every year?! Whoever found the bugs, didn't have access to the source, yet they were still found. And once it is found, how can you fix it? I'd say that closed source software is far more insecure than open source, because not many have access to the source.
That's how the mainframe COBOL guys used to work; they put the source up on the really big bank's mainframe and work with the banks systems people to compile it and customize it. I've worked for two companies that followed that model and let me tell you, it is really really lucrative. It is ingrained in some really big banks' cultures, be it a holdover from the true "big iron" days, but so are the wonderful amounts that you are expected to charge them. Now, you and I realize that times have changed a bit, but many banks still call it DP, not IT and consider this; once you are in, they begin to build systems and protocols around your software. Before it even goes live, they will have their technical writers creating binders just for interoperation with your system. Your software becomes part of the machine. Do you have any idea how expensive it is after a couple of years to rip all of that out and start over? Like others have said, get a good non-disclosure written by pit bull lawyers and laugh all the way to the bank. Just take care of them (the banks decision makers) by doing a good job and catering to their whims (and charging them for it) and they will take care of you.
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.
I contracted with an electronic voting systems company last summer; one task was preparing code for an audit as mandated by the FEC. This was to be a manual audit (versus an automated audit like Fortify), conducted by a 3rd party government contractor.
:)
Notes from the experience:
* We requested examples of code that met specific auditing criteria, and received back several somewhat-anonymized methods, apparently taken from competitor's products. You should verify that the bank has appropriate "handling procedures" for protecting 3rd party source code.
* Our audit criteria was spelled out in an FEC ruling in decent detail. We found that 50% of the rules could be easily expressed as existing Checkstyle "checks" [http://checkstyle.sourceforge.net/ ]; it was pretty easy to build custom "checks" to catch another 30%. We then used an Eclipse plugin [http://eclipse-cs.sourceforge.net/ ] to get real-time highlighting of detected issues (plus Ant scripts for command-line checking).
In your case, Fortify "rulepacks" appear quite proprietary/complex, so using their product is probably your only option for pre-audit auditing. If licensing is out of the question, and you can't strike a cross-promotional bargain (i.e. you market with "Secured by Fortify", they use you as a case study, you get a discount), try and get access to the tool through the bank before the official audit, or negotiate an appropriately flexible window of time in which to address any discovered issues.
* You're not "innocent until proven guilty" in an audit. In *many* situations, we had to argue against rules that were nonsensical in Java, or false-positive issues discovered by the audit. Some we won, most we lost; we faced an uphill battle on all.
* Our auditor was apparently not fluent in Java, and flagged several issues regarding the method names on classes in java.lang.*. Be thankful for automated auditing
Good luck!
Scott Severtson
Senior Architect, Digital Measures
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.
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
I work for a lab that does seurity reviews and evaluations. There are a few things you might want to consider:
http://erichsieht.wordpress.com/category/english/
As a buyer of software I would not only expect (not demand: expect) access to the code for an audit, I would also expect you to keep the source code in escrow, in case you fold and are no longer able to support the software.
As the other poster said, if you're in the business of moving bits on discs, you're already ruined. You're just waiting for the time delay to kick in.