Many, many companies rely on vendors to do some level of development for them.  Even Microsoft, with its 50,000 someodd full time development staff (probably larger now) and equally large number of contingent staff, ends up outsourcing certain development projects to third party companies (in the case of MS, the reason for this is myriad; for one shot projects it makes no sense to form a team that will be disbanded in a couple months.  For established teams, due to the corporate structure, it is actually easier to get millions of dollars more in a budget than a couple more full time employees, so vendor development ends up being a practical way of filling a manpower gap).  For non-software companies vendors play an even larger role.

In my experience with vendor developed code, from a security standpoint it has largely been absolute crap, with few exceptions (just ask the TSA with their recent disclosure fiasco because of a vendor developed website).  The implementation is a mess, and during pentesting the hardest part is documenting all of the myriad of flaws found.  The cause of this seems to be two fold.  First, most vendor companies have no security mindset to speak of and second, the hiring company didn’t make security a requirement during negotiations (though it is sad that security needs to be an explicit requirement but such is the sad state of software development).

To increase the quality of vendor developed code I have a couple practices.  To begin with, anyone interfacing with a vendor should have a degree of expertise in doing so or be accompanied by someone who does.  Having a marketing guy with no product development knowledge to speak of being the sole liaison with a particular vendor is a really bad idea.  You don’t send an accountant to interview potential pilots, so why send a marketing person to interview potential developers?  They are not going to know the correct questions to ask when determining which vendor company to employ.

Speaking of which, one of the correct questions to ask is “Describe your secure engineering practices and policies”.  A vendor that knows anything about security will immediately start citing policy. “At design time we do this, at implementation time this, at test time this” and so forth.  If they hesitate, have very vague or uncertain answers, or just start talking BS, your conversation should be done.  What they mean to say is that they have no secure engineering plan.  As a followup question, assuming they answered positively to the first question, ask them about the security training their developers and testers have.  What percentage have had training, who gave the training, what sort of training was it, how often do they receive followup training?

As fair warning, Vendor companies that can adequately answer such questions are few and far between.  Companies have to search these vendors out, and those vendors rightly charge more than their competitors.  This premium is money saved in the long run.  Insecure implementations by vendors typically need to be heavily modified if not out right discarded to fix the vulnerabilities, and if exploited in the interim often times the cost of the exploit  is many many times the cost of competent engineers.  Choosing a security ignorant vendor will simply lead to needing to hire the competent vendor three months after the project is done (or alternatively hire another security incompetent vendor and repeat ad nauseam until you learn your lesson). 

Security standards need to be part of vendor requirements as much as any other development standards should be (you do have dev standards you give vendors, right?).  The level of security you expect in the finished product is a feature as much as any other functionality that you want the vendor to implement.  The standards should be thorough and often time explicit: stored passwords should be hashed, sensitive data protected, input verified, output sanitized, authorization and authentication requirements should be specific, windows client side apps should enable ASLR and NX (if getting binaries instead of source) for C++ as well as pass prefast, .Net client side apps should pass fxcop, etc.  The vendor’s paycheck should be as contigent on these things as the implementation of any other functionality.

Ideally, you would get the vendor to agree to some sort of maintenance contract, and if so, security issues need to be called out along with every other bug.  In fact, ideally you would make the contract contingent on the vendor being responsible for fixing vulnerabilities regardless of whether there is a maintenance contract in place or not.  Vendor companies pick up secure practices real fast after the execution of such a support clause a couple hundred times, destroying any profit they might make many times over.

If you do these things you will go a long way to improving the security of code you receive from a vendor.  In the end they should be held to standards at least as high as any internal developer.  You are paying through the teeth (or what ever the saying is; I am unclear wear exactly you should pay through) for their time.  It might as well be worth it.

~ Joshbw