Building Internally Versus Getting Help

Deciding whether you should build a team internally to develop your software or work with an external company to build the software on your behalf is complex and involves consideration of much more than just security—including cost, market, complexity, and time requirements. For the purposes of this chapter, we will focus on the security elements, including reviewing what we are protecting in this decision, the risks that you will face, and your options in each scenario.

For most organizations, there are two primary security concerns when building software:

• protection of your intellectual property (IP)

• protection of the data stored within your systems once they launch.

Protecting Your IP

Software companies invest in their technology to produce a unique solution to a problem. This solution, including the software, algorithms, or functions involved, represent IP for the company and this is counted as a significant and valuable asset. When valuing an organization, protection of IP is often high on the list of factors considered. If a company is failing to protect its IP, its value often significantly suffers and the company may lose defensibility.

There is a lot of jargon going in there, so to unpack it and put it in more plain language: if you don’t protect the software that makes your product special, you may lose the ability to compete and your company will become less valuable.

Choosing how your software is built (and, specifically, where) is a significant part of protecting this IP and your competitive advantage. When we outsource our software development, we are placing our trust in this external organization to protect our IP. This can be challenging and requires planning and process to get right.

If developing software internally, you can protect your IP by ensuring the integrity of your team and setting up controls to protect the systems they work on. If using an outsourced development team, you don’t have that kind of control.

Let’s first look at steps you can take to secure an internal development team.

Key Steps for Securing Internal Software Development

The following security measures should be considered when building an internal software development team:

• Hire the right people. Perform background checks and reference checks during recruitment processes to ensure that team members meet the expected standards of behavior and have no prior history of criminal or high-risk behaviors.

• Principle of least privilege. Use the principle of least privilege to ensure that access to code bases, designs, or other sources of intellectual property are restricted to only those roles with need and only for the period that need exists.

• Monitor your environment. Review access logs for sensitive locations frequently to ensure that access patterns are as expected and any anomalies can be identified and responded to quickly.

• Store your IP appropriately. Use appropriate tools for the storage of sensitive information, such as implementing version control for code bases. Use file stores for non-code items, including designs, plans, recipes, and formulas.

• Protect the devices you use. Control and protect end-user computing devices, such as laptops, to ensure they are free from malicious software, unauthorized access, or other mechanisms for harvesting and exfiltrating data.

• Control the usage of production data. Your production data (the data of real customers using your system) is very valuable and often contains commercially sensitive data or personally identifiable information. While it can be tempting to use copies of this data in your development and test environments, this poses a high risk of data loss and should be avoided. Where real data must be used, it should be anonymized or sanitized such that customers are protected.

• Lock down your accounts. Build strong foundation practices, such as enforcing good-quality passwords and multi-factor authentication.

• Weave security throughout your software development life cycle. Use guidance such as that produced by OWASP and NIST to find steps to weave security throughout your software development process.

Now let’s look at steps you should take if you’re using an outsourced development team.

Key Steps for Securing Outsourced or External Software Development

The following security measures should be considered when using an external software development team or agency to build software on your behalf:

• Retain control of your source code. A scarily high number of organizations that use outsourced software providers never store a copy of the software they have commissioned, entrusting the development, deployment, and maintenance of this code entirely with the software vendor. This creates a number of risks including but not limited to:

  • What happens if your software vendor shuts down?

  • What happens if the vendor is acquired or merges with another organization?

  • What if you choose to change software development companies?

  • What if your software vendor suffers a breach or incident that compromises or destroys their systems?

• Do your research and check references. Good marketing doesn’t mean good security. Remember that just like any significant investment your company makes, you need to ensure that your software development partner shares your expectations around security and that you can validate this behavior with current or former customers. Choosing vendors with internationally recognized security accreditation such as SOC2 can make this easier.

• Verify your vendor’s environments. In security, we often say “trust, but verify.” When choosing a vendor, listen to their promises and ask them about their practices—but retain the right to audit them in your contract. Use that right to conduct security reviews if you feel it’s justified. Often you would employ a specialist security assurance company to conduct this review or similar assurance activities like penetration testing. Alternatively, if you choose to review this yourself, you may wish to use something like Google’s Vendor Application Security questionnaires (VASQ), which provide a range of open-source questionnaires to assess the security of your vendor, their security program, and any associated applications.

• Provide suitable environments. If you cannot assess your software partner’s development environment, provide the environment yourself. This choice often removes risks from development teams sharing their development spaces between multiple partners or customers. However, it can also increase the chance of IP reuse or leakage across customers without your knowledge. That risk is just lower than using an environment you aren’t able to vet.

• Explicitly manage IP in all contracts. Your contracts and agreements with software development companies and vendors should explicitly outline the ownership, storage, sharing, and controls around intellectual property. IP already built by your software partner may need specific exemptions to ensure that the line between what your organization owns and what your provider retains is clear.

• Compare and share policy. Ask to see your software development partner’s security policies, standards, and playbooks. If they don’t have them, consider sharing your policy and asking for that to be enforced.

• Have a plan for incidents. If there is a security incident in your software partner, you will want to know about it and any repercussions for your company. Make an incident response playbook for this scenario and collaborate with your partner to ensure it will work. Conducting a test of this playbook involving both companies is highly recommended. You can read more about this in Part IV.

In these early stages, whether you build your own software or engage others to build it on your behalf, there are some steps you can take to make sure you understand the risks in your software and weave security through the software development process. The key is to consistently take these steps even as you grow.

To make this consistency easier, let’s look at a few final tips we’ve gathered along the years to help keep your software, its users, and your data safe, including how and when you should get help and what to look out for when working with security specialists.