Blog Insights 4 Risks to consider when implementing third-party code
July 16, 2019
4 min read

4 Risks to consider when implementing third-party code

Third-party code is a great resource for businesses, but comes with a number of risks. Explore four ways developers can keep their code secure.

third-party-code-risks.jpg

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

We want to hear from you

Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum. Share your feedback

Ready to get started?

See what your team could do with a unified DevSecOps Platform.

Get free trial

New to GitLab and not sure where to start?

Get started guide

Learn about what GitLab can do for your team

Talk to an expert