What makes the use of third-party libraries safe in Metapack?
Using external libraries as part of software development is a completely natural process in any company or project. However, they need to be given special care and control. Find out how we do it at Metapack.
Author:
Piotr,
Software Development Team Leader
Using external libraries as part of software development is a completely natural process in any company or project. You know – no one wants to reinvent the wheel, and the use of third-party libraries also allows you to save time and energy to build new solutions in areas in which we are experts. In every project, no matter what technology it is implemented in, we could write down a long list of nuggets, packages, npm, gems that implement certain generic functionalities (parsers, loggers, graphic components, entire programming frameworks… the list doesn’t end.
However, the external libraries used should be given special care and control. I will not mention the appropriate packaging of them with an additional layer of abstraction, but it’s worth discussing another important topic (if not more important), the safety of their use. What kind of security are we talking about? What threats may be lurking for an application developer, no matter if it’s a student project, a small commercial application, or a large enterprise website?
Regardless of what external libraries we use – we must always ask ourselves two basic questions: who is its author and on what terms I can use it (whether it is free or paid, has open or closed code).
By developing these two issues, we can clarify these questions: do the library’s creators care about its security and whether the library has vulnerabilities to known classes of security vulnerabilities and under what license the library is made available.
This is less important if we are implementing a student project (although it’s worth cultivating good practices from the very beginning), but using a library that has known vulnerabilities or does not come from a reliable source in large commercial projects is a bit like a minefield walk. In the era of all data security restrictions (GDPR), ransomware, or ubiquitous phishing of users – such conduct may expose the company to huge costs related to penalties, infrastructure restoration or reputation rebuilding. The issue of licenses under which a given external library is made available is also important. A million dollars for whoever, awakened in the middle of the night, is able to tell on what terms we can use a given open-source library (after all, there are different types of licenses) and whether careless use has certain consequences, e.g. the library is free home use, but already paid for commercial use, or requires you to share the source of the application that uses it.
As you can imagine, in a large company a big challenge is to maintain control over the issues described in the previous paragraphs. It is best to use a certain… (of course!) external resource that will do it partly for us, but most importantly – it is specialized in this field and will provide the functionality we expect at the highest level. Some of the problems are solved by the Software Composition Analysis class tools (a subclass of Application Security Testing tools).
Source: https://resources.whitesourcesoftware.com/security/ast-application-security-testing access from 03/02/2021
They will not provide us with a 100% guarantee and are not the solution for all problems related to security and library licenses, but they certainly allow us to feel more comfortable when it comes to this aspect of software development. How do we use them in Metapack?
WhiteSource – because this is the service we use at Metapack – helps us deal with the problems related to the risk of using open-source libraries in our projects.
Since we use a completely new approach to creating the architecture of our applications (monolith breakdown, microservices architecture), we can integrate this tool quite easily. Currently, the company is implementing the DevSecOps idea, which, among others, shifts responsibility for security “to the left” (that is, as close as possible to the beginning of the development stage of a given project or a single functionality). The “security” is the responsibility of the development team that implements the component, not the “mythical” team of security experts, the entire company, or… no one.
The WhiteSource scanner is connected to the Continuous Integration / Continuous Deployment process and analyzes the individual code connections to the repository already at the stage of pushing it to the master and (depending on the team and found problems) alerts in an appropriate way that something is wrong (blocking further processing of pipelines CI / CD or by reporting an alert to the incident management platform – PagerDuty). This is a big difference compared to security audits done once in a blue moon, right?
When performing a source code scan, WhiteSource detects the use of external open-source components (both used directly and through dependencies in other libraries).
For this purpose, it has a specially prepared and constantly updated library database. Then it analyzes the licenses of a given component, its usage limitations and confronts them with the license policy for a given organization.
WhiteSource dashboard collecting information on vulnerabilities and used licenses for a given project
(source: https://www.helpnetsecurity.com/2018/08/22/secure-open-source-components/ access from 03/02/2021)
At the same time, it analyzes known security vulnerabilities and reports them, as well as displays recommendations whether and in what version they have been corrected. Regardless, WhiteSource simply informs us about the next new version of the library being used. Recently, in Metapack we also integrated the scanning of docker containers and the analysis of base layers in order to search for known vulnerabilities in them.
Dashboard WhiteSource’a zbierający informacje o podatnościach i wykorzystanych licencjach dla danego projektu
(źródło: https://www.helpnetsecurity.com/2018/08/22/secure-open-source-components/ dostęp z 03/02/2021)
Integrating an SCA-class tool like WhiteSource for CI / CD pipelines in Metapack is certainly not the way to solve all the security problems of your software. Only the implementation of the entire tool chain and their combination can significantly reduce the risk.
In my experience, maintaining an external source of information about libraries that the application has and the algorithm of risk detection and analysis itself is a great help for a developer who may get lost in the maze of licenses, vulnerabilities, and security policies.
Connecting the entire mechanism to the CI / CD process additionally “seals” the entire integration against plugging a potentially dangerous library into the production code of the application – through special mechanisms, certain changes will simply never be in an environment where they could cause significant damage – bring a huge risk of limiting high availability of services for customers worldwide.
If you want to learn more about the Software Composition Analysis mechanisms, please see the linked materials. Or maybe we’ll talk about it at our next recruitment interview?
Resources:
