Outsourcing software development and its effect on security

Question

Some companies build their own software. Others outsource software development by hiring contractors or other companies to build software they need.

When we need to build new custom software, is there any evidence whether the choice to develop in-house vs outsource software development has an effect on security? All else being equal, does developing in-house tend to lead to more secure software than hiring third parties to do the software development?

One could hypothesize that maybe outsourcing software development has a greater risk of leading to insecure software, all else being equal. Maybe when you develop in-house, you own the risk, so developers are properly incentivized to make it as secure as it needs to be -- but maybe when you outsource to a third party, since the third party doesn't operate the software and doesn't bear any of the risk during operation, maybe the third-party developer isn't sufficiently incentivized to use good security development practices and maybe you're more likely to end up with poor security (since that cuts the third party's costs). Or, rather, one could worry there might be some effect like this. But is that really what happens? Is there any evidence one way or the other? Or is there any general experience or conventional wisdom from industry about the effect on security of outsourcing vs developing in-house?

I'm especially thinking of a government agency who has to make this decision, but I imagine the question is generally applicable.

Answer 1

I'd say that there is nothing per se which would always lead to outsourced software being less secure than an in-house development but there are some common factors which may in practice lead to this commonly being the case

1. Cost concerns. If a key factor in winning the work is low cost, then the risk of insecure software is likely to increase. Whichever way you cut it good software security costs money (IIRC Microsofts early SDL estimates was a 10% overhead), so where a 3rd party has to be cost competitive to win, non-functional aspects of the project (e.g. security may suffer). This leads to the second point.
2. Failure to adequately describe the required security level in the contract. A general problem with outsourcing is that the requirement has to be clear in the contract. Things which aren't in the contract are likely not to be focused on (see point 1). Specifying exact requirements for security in a software contract is hard. Language like "it should be secure" isn't prescriptive enough to produce a good result, and the contracting company and outsourced provider are likely to have a very different idea of what "secure" is.
3. "Market for Lemons". Along with that you have the general problem that in secure development there's a market for lemons. What's meant by this is that it's very hard for a buyer to adequately assess the security practices of a development company. There aren't really any good qualifications that can be assessed and buyers are unlikely to go to the effort of manually assessing the security knowledge of the individual developers.

All that said, I'd say that it's entirely possible for an outsourcing company to produce more secure software than an in-house team, the key would be for the buying company to actually prioritize security in a meaningful way during the purchase process, take efforts to assess the claims of the bidding companies, and have good descriptive security requirements in the contract.

Answer 2

The level of security you receive from software is almost entirely determined by the talent and experience of the software developers, rather than the relationship you have with them. Consider two developers, let's call them A and B. A knows how to write the software very securely, and B does not. Both A and B may be hired as employees or as contractors, and there is no reason for them to write the software any differently based on which method you choose to pay them.

That being said, here are some potential factors that I believe could make a slight difference.

Pro Employee

• 3 months later the developer wakes up in the middle of the night and realizes he has a bug in the code, or that there is a better way to do something. The employee is more likely to take action to fix it than a contractor who is now working for another client would be. (Though if the contractor deemed the issue to be important enough, then at least contacting the client would be expected.)
• If an employee's personal wealth is directly correlated to the company's success (such as an owner), they would have a greater incentive to prevent security disasters, so they may spend more energy to ensure better security. (Typically though it is unlikely that the developer(s) on the project are owners with enough equity for this to matter, unless the company is extremely small.)

Pro Contractor:

• If security is well defined in the scope of the project, the contractor may need to adhere to the scope in order to get paid. An employee gets paid regardless if they do the job they are asked to do. (They could be fired or laid off, but they'd still be paid for the job until then.) In other words, it's easier for an employee to be lazy than a contractor.
• Contractors/Third parties are more likely to have "done this before" since they typically do many shorter projects that may be similar to what you are doing.

Final note: the question specifically mentions government agencies. Internal employees (who are software developers) of non-profits and government agencies generally do not have any financial motivation for a project's success, other than continued employment. It could be argued that contractors and third parties actually have more financial incentive to succeed in this regard. Of course there are other incentives beyond financial, but I don't see them factoring in to the developer's mindset regarding security.

Answer 3

As a rule of thumb involving a third party complicates security. It does not mean the product (software or otherwise) cannot be secure, but it does add another factor into the equation. Things to consider:

1. Quality of the staff
2. Experience of the third party in creating software with a focus on security, i.e. the organization as a whole needs the right focus, not just the programmers
3. Budget
4. Availability of internal resources to review code and follow up on the project
5. Contract stipulations: if security is the priority it pays to put in measurable requirements to determine the third party delivered

To name but a few...

Bottom line: it is entirely possible to get secure software when outsourcing, and when the available programmers internally are not up to the job you have little choice. However, in my opinion there is always an added risk when outsourcing that needs to be managed properly to make it work.

Answer 4

Even when hiring reputable, highly skilled external developers, code security is a serious concern. Before signing a contract, be sure it specifies what security checks and monitoring will take place during the life cycle of the application, and the outsourcing provider’s responsibility for fixing any flaws found at a later date. As security testing is a separate exercise from functional and operational testing, it should be made clear who will conduct these tests and which tools and methods will be used. Testing should certainly cover all the risks identified in the contract. Although the outsourcing provider will run its own security tests to check the robustness of its code, tests using an independent third party specialising in application security are essential to obtain unbiased verification and validation.

Answer 5

There are so many variables here. There are good coders as well as bad ones everywhere. If you are looking for a simple answer to this you won't get it. I don't thing you will get any solid evidence indicating which direction to go. If you are working with a reputable third party, someone you know is good - as in you know their quality of work and know they use good coding practices, you can have good security. Yes you can limit the security risk when using third parties but know who they are and how they operate.