4 Risks to consider when implementing third-party code

Managing a complex ecosystem of software and partnerships is a fundamental need for today’s businesses. Most enterprises run hundreds of mission-critical apps, many of which are either out-of-the-box or customized third-party solutions. The benefit of third-party software is clear: It saves time, resources, and allows you to implement new capabilities quickly, efficiently, and at scale.

Unfortunately, with great reward comes some risk. Many of last year’s most significant breaches – like CSC, Best Buy, and Delta – were due to missed vulnerabilities in the company's third-party applications. For example, Best Buy suffered a breach via their online chat service, [24]7.ai, which had stored BestBuy customer payment data on its servers.

Bringing on new, third-party software can be an exciting step forward for your workload and projects, allowing you to add new capabilities, build on the open source community, and leverage some of the best code out there. However, each new partnership creates an opportunity for hackers to access your systems and data. Even if your vendors claim to be secure, their code might not necessarily live up to the security standards and compliance requirements of your business. Developers can’t leave all risk management up to their security counterparts; developers need to share that responsibility just as they share responsibility for writing their own secure code.

Risks developers should know about third-party code

1. As Bogdan Rancea writes, open source code fragments are downloaded hundreds or thousands of times a day – and not everyone is contributing secure code or maintaining a secure code sharing system. The more complex the code, the easier it is for a few lines of malicious code to go undetected.
2. Rigorous testing is often overlooked for third-party code. If third-party code touches your data, it should be tested – but many businesses either don’t test or complete the bare minimum required by their compliance teams.
3. Standard third-party script tracking is documented, but there may be additional tracking that isn’t disclosed. These scripts may be collecting data across your website and apps, storing personally identifiable information from your customers as they engage with your business.
4. When a breach occurs, your brand will be held responsible. When your customers’ data is at stake, it doesn’t matter if the breach happens on third-party soil; if it’s your data, it’s your problem.

Protect your company and customers by planning ahead

While a breach may be inevitable, the disastrous aftermath isn’t. Proactive security measures in third-party relationships can save your company a lot of heartache in the long run, and developers are well suited to lead the charge. Here are a few best practices to follow:

1. Take inventory of all of your current third-party relationships

Begin with where you are now: Create a list of every third-party program used across your company. Make sure you know what code is being used, who the contact person is both internally and at the vendor (if applicable), and understand what data is being accessed or stored by the third party. You may choose to pursue security conversations and testing with certain vendors based on the classification of the data they work with, making an inventory of third-party relationships a valuable tool to prioritize. Once your inventory is complete, it may be useful to consider a third-party or open source code audit to thoroughly investigate your code ecosystem.

2. Work with security to create formal requirements for all new third parties

Establishing standards will allow your team to vet potential collaborators and ensure that any new software or code isn’t posing an unnecessary risk to your business. It will also help to serve as a requirements guide during the procurement process and can mitigate internal conflict when trying to get new tools approved. If you’re unsure where to start, begin by looking at the requirements of all the legal regulations that apply to your business, such as GDPR. You could also look at how the third-party code or tools will interact with your data, systems, and software and create requirements based on what will help you best protect the business.

3. Take on a security mindset: It’s everyone’s responsibility

When hackers are trying to find any possible way in, it’s important that your entire organization – not just the security department – feels responsible for and capable of contributing to your company’s security posture. Widespread security awareness will hopefully make security a priority whenever a team is evaluating a new tool or code fragment.

4. Data encryption: Start your security practices with the data

Set policies to protect data based on certain trigger actions – like the creation of data or external sharing – or based on the level of data sensitivity. By making encryption a standard practice across all systems, you’re adding a layer of security that requires identity-based authentication, which can give insight to who is accessing your data and when. Moreover, any stolen data will only be useful to hackers if it can be decrypted.

Cover image by Kelly Sikkema on Unsplash