Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×

Third Party Code Review? 89

Posted by Cliff from the who-would-you-trust-with-your-code dept.
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? More

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.

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

      by Embedded2004 ( 789698 )
      That's retarded.

      There is nothing fundamentally wrong with selling software.

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

        by chaves ( 824310 )
        >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.

    • Re:ruined? (Score:5, Funny)

      by iMaple ( 769378 ) on Wednesday February 22, 2006 @01:26AM (#14774343)
      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.

      • Re:ruined? (Score:5, Funny)

        by LLuthor ( 909583 ) <lexington.luthor@gmail.com> on Wednesday February 22, 2006 @01:45AM (#14774462)
        I think we have finally solved the infamous 2. ??? puzzle.

      • Re:ruined? (Score:4, Funny)

        by cerberusss ( 660701 ) on Wednesday February 22, 2006 @03:59AM (#14774896) Journal
        You forgot an important step.

        At some point in the above-mentioned plot, mostly around the end, you should laugh like a maniac, like "BWA HAH HA HA HA HAAAAAAaaah". For more information, see this entry on Wikipedia [wikipedia.org]

      • I know you were being sarcastic, but you do bring up a good point: how can the bank trust Fortify?

        First off, I know nothing about this Fortify product, so you may want to take what I say with a grain of salt. However, it does appear as if the bank is putting a LOT of faith in this product that it will find these supposed security holes. A wise man once said that there is no such thing as a "silver bullet", but it appears as if this bank has not taken this wisdom to heart. They are under the false impres
    • A better way to put it is if your competitor got the source code for the software!
      It takes money to write software, yes they will make money on support and updates but with the source to your software your competitor can easily take the work that you have done for free. Then they can offer an initial lower cost purchase and make the same on support as you did.
      In the real world it would be like releasing your software under BSD! I know the RMS faithful will understand that.
      A small company probably doesn't ha

  • Give them the code (Score:5, Interesting)

    by BadAnalogyGuy ( 945258 ) <BadAnalogyGuy@gmail.com> on Wednesday February 22, 2006 @12:40AM (#14774111)
    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.

  • NDA (Score:4, Informative)

    by poopdeville ( 841677 ) on Wednesday February 22, 2006 @12:43AM (#14774125)
    Get the bank to sign an NDA, and sue the pants off of them if they leak your source.

    • 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.

      • To make this work, in addition to an NDA, you would need to make the source for each customer just a little bit different. Then, if it turns up elsewhere, you know, and can prove in court if necessary, where it came from.

        Having said that, I still think that the "sell disks with ones and zeroes on it" model is flawed. In my long experience, most custom software should be a thin layer of Open Source glue around Open Source components, distributed under an approrpriate and most likely Open Source license,

  • It they steal your code (Score:5, Interesting)

    by dtfinch ( 661405 ) * on Wednesday February 22, 2006 @12:43AM (#14774128) Journal
    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.
    • Not to defend the submitter and his Mickey Mouse operation, but Fortify's pricing isn't really too much of a secret [infoworld.com].
    • And it all does not matter anyway. Unless you have done something outrageously stupid, a vulnerability in a Java program is more likely to arise from a bad design choice, not from a coding implementation. No "Snake Oil (TM)" regardless of the "Fortification" level is going to catch this type of vulnerabilities.

      You need a human for that. Not a developer by the way. You need someone with a good architectural view that will not get bogged down into the details for that.
    • 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.

      So what? Keeping the price secret helps producers to dictate the price, knowing it benefits the consumer. Capitalism is a constant battle between consumers and producers, do you want to allow producers to use the weapons they have available, while depriving consumers from the same right?

    • You'll sue. You'll win. You'll be fine. Your competitor will be ruined. The person who leaked the code will be ruined.

      This is it exactly. I don't understand how it got to be this way, but the "Oh, no! Our source code must be kept secret or we'll be ruined! Ruined, I say!!" attitude is almost as silly as it is widespread. That's what copyright is *for*: You can hand out copies of your source all over the place and no one is even allowed to compile it without your permission. Certainly no one is going

  • Not too sympathetic. (Score:5, Insightful)

    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 ) <centurixNO@SPAMgmail.com> 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.

    • Re:NDA (Score:4, Interesting)

      by (H)elix1 ( 231155 ) <slashdot.helix@nOSPaM.gmail.com> on Wednesday February 22, 2006 @12:50AM (#14774172) Homepage Journal
      Non Disclosure Agreements and Really Good Lawyers, that's what it's all about.

      Spot on. With that in place, no real reason to worry about the source code. The Java decompilers out there (try JAD for instance) are good enough I stopped bringing source with me and would just decompile the class files if I needed to look at something. If you think a Java class file will keep code out of your competitor's hands - you are in for a real shock.

    • Re:NDA (Score:1, Insightful)

      by jipis ( 677451 )
      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 dolla

  • Uhh, java class == source code (Score:4, Insightful)

    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.
    • While this may be useful for some small program with an unusual algorithm to protect, any medium to large program would most likely be easier to replicate by redevelopment than by decompiling. That's why hardly anyone worries about obfuscating.
      • Only if you've lost unit tests or something else that you don't distribute. If 100% of your source is included in class files that you can get access to you can retreive 100% of your source will little to no effort. Naming local variables and writing comments is no effort. Now native executables, that's a different story.. there's so much information missing that the reverse engineering effort is significant, even for the original developers. Oh, and BTW, we weren't talking about recovering lost source
        • Being able to recover 'source code' and being able to recover useful source code are different things. When you have a code base in the million line range, decompiling the jars will get you somewhere, but not anywhere useful. You aren't going to be able to turn out a competitive product any time soon. There's just soo much information stored in the heads of developers that stealing a useful product by decompiling jars is effectively impossible. And that's on top of the stuff you don't ship, such as test
          • Well duh, stealing anything from a competitor is pointless. It's not like software developers come up with big giant secrets that are the lifeblood of the company that, if revealed, would lead to the downfall of mankind. It's only pointy headed managers who think that. My company could give its competitors our source code and there'd be nothing they could do with it. That's the thing about copyright law.

  • Single you out? (Score:3, Interesting)

    by bondsbw ( 888959 ) on Wednesday February 22, 2006 @12:51AM (#14774178)
    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.
  • You get paid no matter how you do on the audit, right?

    If I were your competitor, and i wanted your code that badly, I would have already disassembled it by now. If it's Java, I would have had a really easy time of it.

  • 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.

  • It ain't windows. (Score:2, Insightful)

    by Anonymous Coward
    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

    • Re:It ain't windows. (Score:1, Informative)

      by 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 li
  • Why doesn't your company audit the auditor?

  • Banking MO (Score:4, Interesting)

    by ScrappyLaptop ( 733753 ) on Wednesday February 22, 2006 @02:00AM (#14774544)
    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.

  • Code Auditing (Score:4, Informative)

    by crmartin ( 98227 ) on Wednesday February 22, 2006 @02:26AM (#14774640)
    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.
    • Stealing source code is irrelevent for all but the most complex algorithms.

      Generally, production code is not of excellent quality since there is no time in the real World of business to make it super-duper. What is really important is something you can't steal: the knowledge and experience in your employees head.

      Anybody who has had to maintain other people's code knows that often it is easier just to re-write it (or large chunks of it) anyway.

      As for getting somebody reputable like Ernst and Young: be

  • Simply allow them their audit: Here is a room, we've prepared for your audit. It doesn't have any communications links, leave your cell phone at the door. There are two computers with the source code. Feel free to audit it all you want.

    • That is what I thought about.
      Allow audit of the source under full NDA and without leaving any technical means to circumvent the NDA.
      As an extra: advise and provide help of lead programmers of your company - they will be able to immediately explain any doubts, possibly fix immediately all easier security bugs found by the audit (no waiting for feedback: "here's an error, fix it", week later "here's a fixed version, audit it", another week later "the fix is not satisfactory, fix again" and so on), and in the

  • Government code reviews (Score:4, Interesting)

    by scottsevertson ( 25582 ) on Wednesday February 22, 2006 @04:11AM (#14774939) Homepage
    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/ [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/ [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!

  • Sarbanes-Oxley (Score:5, Informative)

    by mwvdlee ( 775178 ) on Wednesday February 22, 2006 @04:11AM (#14774940) Homepage
    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.
  • Just make the application in Obfuscated C! by the time the audit has finished, new computers will be able to play DNF!

  • What does Fortify do, anyway? (Score:3, Insightful)

    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
    • One example of things you may want to check is whether the code ever calls Thread.stop(). If it does, it is suspect. I am sure there are numerous pitfalls like this to search for once you start thinking about it.
    • I would believe that some company that puts their whole reputation on the line by handling people's lifeblood code in their hands would make sure to do a little more then just check names of variables...

      I would think first that they have a big database of source code (of which they probably put a disclaimer for in their license agreement and put your code in their db for further use...) and compare to see if you have not already used someone else's code signature or even GPLed code for that matter.

      Second, t

    • DISCLAIMER - I work for a software company that specializes in application security. Just not Fortify.

      High-level languages like Java tend to have high-level security weaknesses, just like low-level languages like C/C++ have low-level weaknesses. Especially in web-accessible code (just because it's not an applet doesn't mean it's not web-accessible), there are right ways to do things (such as parameter validation, proper encoding, crypto usage, etc.) that even simple static analysis (or hand-scans, if yo

    • Re:What does Fortify do, anyway? (Score:1, Informative)

      by 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,

    • It turns out there's a fair number of things you can do to screw up security, even in Java. Think SQL injection and cross-site scripting. Check out http://vulncat.fortifysoftware.com/ [fortifysoftware.com] for a longish list of code-level defects that can cause security problems.

      Static analysis has a lot more to offer than looking at the names of methods and variables. FindBugs ( http://findbugs.sourceforge.net/ [sourceforge.net] ) is an excellent open-source tool for finding common problems in Java, though it's focus is much more on code quali

  • Things to consider (Score:5, Informative)

    by Sven Tuerpe ( 265795 ) <{sven} {at} {gaos.org}> on Wednesday February 22, 2006 @05:58AM (#14775228) Homepage

    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.

  • 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.

  • just think about it a minute.... (Score:3, Insightful)

    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.

    • The bank/auditor have employees, who have very different agenda from the bank/auditor itself. They can be fired, become upset an distribute your code. The bank's board of directors won't do their best to stop it - it's your problem. I'm not saying letting someone see your code is bad - we're giving out our source code to our most important customer. But doing it mindlessly, without sufficient (legal/technical) precautions is not a good idea.
  • You have the bank sign some legal document that says they pay for the harm if your source code gets out due to their fault. The lawyers know how to take care of this. Get one. Problem solved.
  • I worked for a company that sold software to banks, and we had to satisfy the same requirements. We ended up negotiating an arrangement where a consultant from IBM who would show up on our premesis, check out a laptop with no network or removable storage support that had a copy of our source code on it, read source code all day, then check it back in and go home.

    We thought it was pretty draconian, but the bank thought it was a great idea; bank IT staff by necessity live in a paranoid world, so I guess they
    • The beauty of this approach is that it works for the bank too -- they don't want to have to deal with any potential legal exposure if they decide not to use your software for some reason.
  • Often companies will use a 3rd party auditor - particularly if they don't have the skills themselves. We've been through that several times, no problems. They can also help by spotting things you weren't.
  • OK, With the NDA you may have legal grounds to sue their asses off, but what happens when you have to do this with some other company, and the one after that? How can you know who leaked it? Just do what the CIA/NSA/DOD et al have been doing for years. Make small almost insignificant modifications, (comments, variable names, etc) so that each version is slightly different. Get the names of who will actually be handling the code from their side and supply each with a different tainted version. So, when
  • Let's review real quick:

    1. you are a software developer with big clients such as US banks
    2. you must submit your source code to a 3rd party auditor
    3. you think slashdot is a good source of advice

    Well, seeing as you're in business I'll assume #3 is just a temporary brain fart on your behalf. If you're really worried about your code falling into the wrong hands, then have a lawyer write up a nice contract that expressly forbids the bank and any other party from using the code for purposes other than security
  • Do the code review and testing in your office. Set up some review stations connected on an independent net--ie. not on the Internet or company network. Remove the burners,floppy drives and USB ports to be safe. That will stop most leaks from getting out.

    Give them access to a another machine if they need Internet access.

  • Send the bank a hard copy of all the posts on this topic, sign the contract.
  • Big financial markets, certain medical devices (huge liability), anything nuclear and intelligence/defense.

    'Most of the code audits though, are for the low hanging fruit only, since a huge codebase can take a very long time to become familiar with, and the auditors never attain the same level of understanding as the original authors' (paraphrased as told to me by a defense code auditing guru).

Slashdot Top Deals

Two can Live as Cheaply as One for Half as Long. -- Howard Kandel

Close