Outsourced development risks

Have you ever worked with a company that’s outsourced to freelancers or an agency to help deliver on a project?

If you’ve experienced this, you’ll understand how much of a difference coherent onboarding can make to the outcome of the project. Outsourcing development is much the same, though even with efficient onboarding, it does come with its own set of risks. Can you think of what some of these might be? Let’s find out if you got them all. 

Outsourcing: The risks 

Outsourcing is a common approach in business, one which offers potential cost advantages and economies of scale. It allows businesses to grow and achieve their targets without the long-term financial commitment of an expanded team, as well as to benefit from a fresh point of view on their projects. Of course, there are many more benefits to outsourcing resources, but there are considerable risks too, ones that should be measured and provisioned for before committing. Let’s look at some of these now:   

• In some cases, an organisation might look to outsource offshore, but they should be aware that this is considered higher risk because the coding and standard practices of the third-party developer may not meet acceptable standards.
• Loss of intellectual property is also a major concern in countries where the organisation’s national law has no jurisdiction; recovery of intellectual property and enforcement of ‘cease and desist’ orders or lawsuits can be impossible. There is a tendency in China to reverse engineer, for example aircraft technology and design, to see an example of this, click the link here.
• It’s possible that malicious code can be inadvertently - or even purposefully - be introduced by an outside resource. For example, covert channels might be built into the software as a way of bypassing a security control, perhaps for the purposes of fraud or even to sell to criminals. Ideally, software will have passed an open-source testing or a vendor agnostic testing.

So, how can you mitigate some of these risks? 

Mitigating risks 

Knowing where your organisation might be vulnerable is half the battle, so being aware of the points mentioned above is a great place to start. Let’s take a look at some of the things an organisation can do to try and mitigate some of those risks now:  

• Contracts and specifications help to reduce the risk of a solution being delivered that misses the mark, so clear and unambiguous direction should be documented early on. 
• Prototype stages should also be built into the development cycle to validate that the specification has been followed. 
• Software development methodologies should include processes to inspect the delivered solution for malware, or direct visual inspection of the underlying code is possible (this can be automated with the use of scanning tools.) 
• User testing can help to identify covert channels built into the software, so this should be a step implemented when undertaking software inspection.  
• The inclusion of a trusted third-party or Escrow can be a good idea, as they hold a copy of the source code and development documentation, should the outsourced developer(s) become uncontactable.

More on Escrows now...

Escrows 

Escrow is a legal arrangement in which a third party temporarily holds an asset or money or until a particular condition has been met. This can be very useful in the process of, for example, buying a house, where money is held in escrow to protect the buyer’s deposit and ensure that the money goes to the correct party according to the conditions of the sale.

Let’s look at an example, where Escrow can come in handy. If source code has been written or provided by a third-party developer, the organisation is totally dependent on that supplier for support, updates, patching and security fixes.   

In extreme cases, where a supplier has gone out of business or has been acquired by a competitor, the commissioning organisation can be forced to pay extra to fix problems that should have been resolved under the standard maintenance agreement. So, what can you do? 

Well, it’s important to be proactive when working with third-party developers, so implementing an Escrow up front is a great way to protect an organisation from this problem. Both the organisation and the external supplier agree on the Escrow – a neutral third party, often a law firm – to hold a copy of the source code. If the contract is breached, the source code is released to the commissioning organisation.  

In some cases, risk can also be mitigated by an amount of money from the contract value being held in escrow and being released to the third-party supplier after a pre-defined period, perhaps three years. This means that, if the supplier ceases to trade or doesn’t complete the development, the money is returned to the commissioning organisation to help fund the redevelopment or replacement programme.    

What’s next?  

Now you’re armed with the necessary information to prepare you for the security risks when working with a third-party developer, you can move on to the next Course, ‘Testing, audit, and review’.