The Security Liabilities of 3rd Party Libraries

The dangers of 3rd party libraries

In the security space, we spend a tremendous amount of time working on securing our systems, processes and people. However, as the expression goes, “you’re only as good as your weakest link,” and in many cases, this can be something outside of your organization. A 3rd party is a blanket term that refers to all entities outside of your organization that you do business with such as suppliers, partners, contractors, etc.

3rd parties have their security risks, and those risks can cause damage to any of the companies that they work with. In today's digital world, organizations have to become more reliant on 3rd party libraries to complete their application and internal resources. In the SolarWinds incident, a hacker group was able to compromise SolarWinds and use them to infect thousands of their clients with malware. This is a common strategy by hackers and needs to be accounted for in your security strategy. Also, even if hackers aren’t able to use a 3rd party to hack into another company, simply having a 3rd party hold your company’s data can be a potential risk because if the 3rd party is hacked, your company’s data can be leaked. This article will discuss the liabilities of using 3rd-party code libraries in particular.

Assuming liability for code you didn’t write

3rd-party code libraries are great for saving time and adding certain functionality, but every time you use them, you adopt any of the security risks found in that code (it also functions as one of the ways to accept risks by delegating the risk to a vendor). When you write code yourself, it will be subject to your company’s internal security standards, which should make it more secure. However, whenever you use 3rd-party code libraries, you accept liability for code that isn’t yours and is a risk.

Why is it so hard to keep 3rd party libraries secure?

There are several reasons why keeping 3rd-party code secure is a challenge:

1. The code may be written insecurely, to begin with. Depending on who created the code and the process it was subject to, it may have multiple security bugs that need to be fixed. There is no clear standard, requirements or guideline that oversees how code is written and design. If you ask 10 developers to write code to perform the same task, each of them may write that code in a different way. As a result, depending on the experience level of the developer, there attention to security and other factors some code may be written that doesn’t have the correct security checks and balances.
2. Even if the code is secure at creation, code repositories constantly change to add new features. Think of languages like javascript, new libraries and frameworks are constantly being created to allow for better animations and effects for websites. This means that even a repo that was safe six months ago may have unknowingly added new security bugs since then. Hence, you need to evaluate the code to ensure it is constantly secure.
3. If you are paying for a 3rd party component that is closed-source, you can not assess its security posture very easily because you won't be able to do things like source code reviews. Some companies have a strict policy where they will design an application for your business but they won’t give you the ability to see or own the source code, this restricts your ability to assess it for security vulnerabilities. You’re restricted to performing outside security assessments to identify potential issues and this is not sufficient to find all potential flaws.

How to vet 3rd party libraries

So far, we’ve discussed the potential security issues of 3rd party code. Still, in this section, we will discuss some methods for identifying if a 3rd party code repository is secure.

Be Aware of Legal Regulations: If you are working with a vendor overseas to develop 3rd party code, you need to be mindful of regulations like HIPAA, GDPR etc. This will affect how you can share data with that company. You also need to let the company know the regulations your software will be adhering to and ensure that it functions in a way that complies with that.

Ask specific security questions: If you are working with a vendor, it’s a good idea to ask specific questions related to their security process. This includes their review process, how they secure client data, whether their staff is trained in security and what standards/processes they use for creating secure code. Here are some questions you should consider asking:

1. Does your code have input validation?
2. Do you include controls for the OWASP top 10 in your code
3. Do you use any security coding frameworks
4. Do you allow your clients to view and scan the source code
5. What’s your turnaround for fixing security bugs in your code

Address Security in the Contract: Your vendor contracts should include agreed-upon IT security processes and expectations. This should include common language, covering things like security audits, ongoing support for security vulnerabilities that are found, compliance requirements and any other requirements that you should have for your software.

Test the final product: As a security-conscious company, whether you pay a 3rd party to create your applications, use open-source code or build your software completely from scratch, you must test your final product with a penetration test. Even if you believe you followed all the correct guidelines and standards, hiring a professional will help you find security issues before your product hits the market. Here is a video that explains in detail the importance of evaluating your code for potential security flaws.

How to mitigate 3rd party library security issues

In this section we’re going to discuss three main ways that you can mitigate security risks commonly found in 3rd party code libraries. It’s important to note that this is not all of the methods you can use but it is a good starting point for ensuring you have secure code.

Manual Source Code Review: If the company allows you to read the source code, you can do a manual code review for potential security vulnerabilities. This is one of the best ways to understand how code is set up/designed, but unfortunately, not all companies are willing to share their source code with their clients.

Use Static Analysis Tools: If your vendor allows you to view the code or you’re using an open-source code repository, you can use static analysis tools to evaluate source code for potential security bugs. These tools can scan thousands of lines of code and identify common security issues. Some examples of static analysis tools that you can use include: Checkmarx SAST, Veracode and Snyk Code.

Use peer review tools: Companies like Veracode offer 3rd-party code scanning to identify possible vulnerabilities. By using services like this, you can get an idea of any vulnerabilities in the libraries that you’re using. Additionally, simply doing some research around the library will give you information on if other people have had issues with it.

Conclusion

3rd party libraries can be a big security risk for your software products. Whether you’re using an open-source library or hiring a 3rd party to write code, you will need to evaluate the code for any signs of security bugs. This can be done in many ways, but the best ways to evaluate a library consist of doing manual code reviews, using automated analysis tools or hiring professionals to evaluate the code. These services allow you to identify security flaws in your software before it goes to market.