Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×

Third Party Code Review? 89

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?"
This discussion has been archived. No new comments can be posted.

Third Party Code Review?

Comments Filter:
  • ruined? (Score:4, Insightful)

    by croddy ( 659025 ) on Wednesday February 22, 2006 @12:37AM (#14774093)
    you would be ruined if a competitor got the software?

    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.

  • by tinkertim ( 918832 ) * on Wednesday February 22, 2006 @12:44AM (#14774132)
    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.
  • NDA (Score:5, Insightful)

    by Centurix ( 249778 ) <centurix@gmail.cBLUEom minus berry> on Wednesday February 22, 2006 @12:44AM (#14774136) Homepage
    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.
  • by QuantumG ( 50515 ) <qg@biodome.org> on Wednesday February 22, 2006 @12:50AM (#14774169) Homepage Journal
    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.
  • Just do it (Score:3, Insightful)

    by El Royo ( 907295 ) on Wednesday February 22, 2006 @12:59AM (#14774208) Homepage
    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.
  • Re:ruined? (Score:3, Insightful)

    by Embedded2004 ( 789698 ) on Wednesday February 22, 2006 @01:17AM (#14774299)
    That's retarded.

    There is nothing fundamentally wrong with selling software.
  • It ain't windows. (Score:2, Insightful)

    by Anonymous Coward on Wednesday February 22, 2006 @01:21AM (#14774315)
    I'm a manager at a fortune 10 company, and parts of our business run SAP. Maintenance licensing runs into the tens of millions of dollars per year. So it would make sense to try to steal this product, right? Wrong.

    If we somehow got hold of the source to SAP R/4 and MySAP, outside of a quality review, it would be worthless to us. The support, maintenance fixes, and configuration assistance SAP provides are worth far far more than the code. And the risk that comes with internally-compiling the code (and we can do it) could cost the business far more than $10M.

    Net: Don't sweat it.

  • by ClamIAm ( 926466 ) on Wednesday February 22, 2006 @01:25AM (#14774337)
    Like Free Software, but without all the philosophical bullshit.

    Yeah, having an opinion is BAD! Only idiots and terrorists have opinions!

  • Re:NDA (Score:1, Insightful)

    by jipis ( 677451 ) on Wednesday February 22, 2006 @03:49AM (#14774861)
    More important possibly than negotiating your way out of being audited, maybe you can negotiate something long term once they have audited you. You must have tech support if you ship a product. Can we say SLA? If they like your product enough that they're going to go through the effort to bring in the big guns, they're going to want some sort of support (once your marketing guys remind them as such).

    This is how many of the govt contractors go from having just a foot in the door to having multi-million dollar contracts. Now that I think about it, isn't this a similar business model as drug trafficking?

    -J
  • Re:NDA (Score:5, Insightful)

    by WebCrapper ( 667046 ) on Wednesday February 22, 2006 @04:51AM (#14775036)
    On top of this, I would transfer the source (on whatever media) encrypted so, if something where to happen, they cannot claim it was stolen somewhere in the middle. Require them to call a specific person when they receive the disk to get the key.

    An NDA and possibly a Non-compete agreement should be fine. This stops them from sharing the source and from giving the source to in-house developers to try to pick through your source to make a product for themselves.

    Also, since they do this with all applications they use, you have the right to ask for the contact info of a few places they've done this with. This allows you to talk to X Company about what happened during and after the process. Tell them this is your security check on them.

    Either way, as with most business related "Ask Slashdot" articles, you need to consult your lawyer.
  • by Myria ( 562655 ) on Wednesday February 22, 2006 @05:04AM (#14775082)
    What kind of things can an automated process do for auditing, anyway? This is Java we're talking about. 90%+ of things that are security problems in other languages aren't even an issue in Java, as the compiler and/or the assembly language verifier already do that.

    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.

    So what can this program do? All I can imagine it doing is checking to make sure that you're not using any function calls that Fortify's authors consider "unsafe", no matter whether the particular context makes it safe. It probably will also yell at you for using variable names that don't follow its stupid rules.

    I can imagine how things like this exist. They approach these security-paranoid companies with offerings of a magic solution that will allow them to verify that their system is secure. Extremely afraid of being the next target of a class-action lawsuit, they are eager to pay large sums of money. The people who make the decisions aren't trained in computer science, so they don't understand that an automated system such as this is truly impossible.

    It is the small companies who have to deal with this that suffer. The magic oracle says that you used a single letter as a variable name, so you absolutely must change it, with no excuses. You spend a lot of time and money "fixing" it to please the oracle, when you have done absolutely nothing for true security.

    Melissa
  • Merely an audit? (Score:3, Insightful)

    by bbc ( 126005 ) on Wednesday February 22, 2006 @07:29AM (#14775444)
    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.
  • by Malor ( 3658 ) on Wednesday February 22, 2006 @09:07AM (#14775738) Journal
    While your code is very, very important to you, to that bank, it's just a program they want to buy. To the auditor (if it's a separate organization, as it probably legally has to be), it's just a bunch of code that the bank wants checked out.

    Your company, virtually certainly, isn't even vaguely important enough to them to mess with. If that code leaked and the word got out, the reputation of both the bank and the auditor would be badly damaged...a financial loss greatly in excess of the net worth of your entire company.

    If for some reason they wanted to leak the code, it would be a lot cheaper for them to just buy you out, lock, stock and barrel.

    Use your brain. Give them the damn code. They'll probably treat it better than you guys do. They have a lot more to lose if they don't.

  • Re:ruined? (Score:2, Insightful)

    by chaves ( 824310 ) on Wednesday February 22, 2006 @10:04AM (#14776010)
    >There is nothing fundamentally wrong with selling software.

    Exactly, this is specially true in the case of niche applications for vertical markets, where open source competition is not an issue.

  • by dougmc ( 70836 ) <dougmc+slashdot@frenzied.us> on Wednesday February 22, 2006 @10:53AM (#14776381) Homepage
    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, but what the hell. It annoys me when people claim something is proven, without actually supplying any proof.
    To be fair, a thought experiment rarely provides proof of anything. Yes, they're useful for figuring things out and demonstrating things, but they don't prove anything.

    As for the `far more secure' claim, there is some truth to it. (Or were you saying that your comment was flamebait rather than the post you were replying to?) If you have a closed source project (and even an open source project may be similar), it probably has lots of bugs -- some you know about, many you don't. The source code may even be riddled with FIX THIS! BIG SECURITY HOLE! type comments. If the source gets out somehow, then people who go over this code may be looking for security holes to use against you and your customers. Which isn't automatically bad, but there's two differences between this model and the traditional open source model -- 1) nobody is supposed to have your source, so anybody who does is pretty much by definition `bad', and 2) bugs found are not likely to be reported back to you, so you can't go and fix them unless you're able to detect and analyze an exploit actually being used.

    That said, the loss of your company's source code isn't as big a deal as some might think. Yes, depending on the software, crackers might interested in using it to find holes in your product. However, if your competitors are legitimate companies, they're not going to touch your source with a 10' pole. Even if they could learn all sorts of neat stuff from it, it could also easily lead to corporate ruination -- all it takes is one disgruntled employee to report it to you or the authorities and provide proof. And really, your software may already be out there -- it only takes one employee and a portable hard drive to take it all off site. (Of course, he'll have a hard time selling it for the reasons I gave above ...)

    That, and just having the source is not everything. Your company probably also provides support and professional services. For large projects, this is really important, and software that doesn't come with support often isn't very useful.

    In any event, even if you do give out your source to this customer, a full code audit is not likely to happen. They'll use their automated tools, they'll look at key parts, but it's very unlikely that they'll have the resources or time to do a full audit like the OpenBSD team did when they forked from NetBSD -- instead, they're just looking for low lying fruit, and are likely to find only a small percentage of the bugs. On the other hand, they'll probably report what they find back to you so you can fix it.

    But as for the dangers, for starters, make sure your legal team makes a iron-clad NDA for the other company to sign. If your company is too small to have a dedicated legal team, get a lawyer for this. Make sure that only a small group of people will have access to the code, and that it's deleted when it's done, with big penalties if this is not done. Perhaps the audit could be done on your premises, on your hardware, supervised by your employees?

The key elements in human thinking are not numbers but labels of fuzzy sets. -- L. Zadeh

Working...