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?"

14 of 89 comments (clear)

  1. ruined? by croddy · · Score: 4, Insightful
    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.

    1. Re:ruined? by iMaple · · Score: 5, Funny

      Better idea. Ruin Fortify.

      Talk to the bank manager, let him know that you whole heartedly support security audits. Then ridicule him for trusting Fortify, a closed source tool, for sucah an important audit. Enlighten him about the possible conspiraces involving Fortify, Nigerian Scammers, Dick Cheny , ... you get the idea. Then offer to audit the Fortify source code for free. Start a new company in China (they dont have freedom of speech, but neither do have strong copyright protection) and start selling Fortify+ (or FortifyLight depending on your marketing strategy). You will be a multi millionaire soon. Dont stop, claim that the original Fortify stole your source code and sue them (dont care if its obviously untrue, remember SCO ?). And then finally when you have a few billion dollar in you bank account GPL the code under GPL 3 and post the news on slashdot.

      Whew, another success story for the books.

    2. Re:ruined? by LLuthor · · Score: 4, Funny

      I think we have finally solved the infamous 2. ??? puzzle.

      --
      LL
  2. Give them the code by BadAnalogyGuy · · Score: 5, Interesting

    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.

  3. NDA by poopdeville · · Score: 4, Informative

    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.
    1. Re:NDA by WebCrapper · · Score: 4, Insightful

      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.

  4. It they steal your code by dtfinch · · Score: 4, Interesting

    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.

  5. Not too sympathetic. by tinkertim · · Score: 5, Insightful

    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.

    1. Re:Not too sympathetic. by tinkertim · · Score: 4, Funny

      >> Order happy meal first. Big mac later.Good starting point for a haiku. Work on it.

      Pointless Haiku
      containing big mac
      always ends with
      toilet flushing.

      I doubt that qualifies. But then I don't qualify for much either :) So it fits.

    2. Re:Not too sympathetic. by smallfries · · Score: 4, Funny

      Happy meal first.
      Order a Big Mac later.
      Fries with that?

      My god its late and I need to go home

      --
      Slashdot: where don knuth is an idiot because he cant grasp the awesome power of php
  6. NDA by Centurix · · Score: 5, Insightful

    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
  7. Banking MO by ScrappyLaptop · · Score: 4, Interesting

    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.

  8. Sarbanes-Oxley by mwvdlee · · Score: 4, Informative

    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?
  9. Things to consider by Sven+Tuerpe · · Score: 4, Informative

    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.
    --
    http://erichsieht.wordpress.com/category/english/