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.
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. 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.
There are several reasons why keeping 3rd-party code secure is a challenge:
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:
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.
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.
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.