How do you evaluate third-party libraries for security?

Evaluating the security of a library is no simple task. Even if the developer or company behind it has a solid reputation, there's no guarantee that the library is free of security flaws. Delving into details like the licensing terms and available documentation. The first step involves embracing the concept of Zero Trust, but in the case of such libraries, it's crucial to confirm compatibility with your project's tech stack and ensure it won't introduce unnecessary conflicts or dependencies. Additionally, look for any community forums or discussion boards associated with the library; these platforms can serve as valuable hubs for asking questions, sharing experiences, and gaining insights from fellow users of the library.

Some of the ways to begin evaluating the third party libraries for security are as below: ? Performing Software Composition Analysis (SCA) ? Having Software Bill of Materials (SBOM) ? Adopting SLSA (Supply Chain Levels Software Artefacts) ? Observing the BitSight Score and Security Scorecard for various security control domain

Few pointers: Look for reviews, testimonials, and any known security vulnerabilities. Most effective way to identify security vulnerabilities is to review the library's source code. Make sure to apply security updates as soon as they are available.

Additional factors to be considered when checking the source are: looking for the past security flaws detected in the library in the available vulnerability databases, the history of the past vulnerability disclosures and if the library creators follow the responsible disclosure rules. One other thing to help assess the security maturity of a library developer would be to check if there is a dedicated channel to report vulnerabilities in the library.

To ensure the development of secure code, it is necessary to use platforms like CheckmarX, which allow you to perform static and dynamic code analysis, intervene in the development pipeline, and allow you to use secure libraries.

We can utilize static code analysis tools to pinpoint security vulnerabilities within the codebase, including those associated with libraries. Additionally, we can conduct formal security audits or code reviews of critical libraries, which can be carried out internally or by third-party company. Moreover, we can enhance our security posture by applying threat modelling exercises to identify potential security threats related to libraries. We have multiple methods for analysis and control, so it's imperative to conclude with a penetration test and the utilization of a Dynamic Application Security Testing (DAST) tool. This step allows us to assess the application's runtime behaviour, uncovering vulnerabilities that may become apparent.

Agreed, I'm using dependency check from last 4 years now. It really gives a detailed report in various format and severity of vulnerabilities.

DAST and SAST are the way to go about it. Also, any previous known vulns that went unpatched and affected customers are something to look forward.

One of the most significant challenges in addressing vulnerabilities in third-party libraries lies in effective prioritization. While static analysis can provide valuable insights into existing vulnerabilities, it may identify issues that are not even utilized in the application. Conversely, dynamic analysis offers more accurate insights but is often introduced relatively late in the development process. Organizations strive to detect and resolve vulnerabilities as early as possible. Hence, a synergistic approach that combines both static and dynamic analyses, coupled with a sophisticated prioritization framework, can yield optimal results.

All the comments I've seen have been about using tools for analysis. Sometimes tools can indeed be handy to save time if there is an obvious (and therefore machine-detectable) flaw. However, at the end of the day, there is no known substitute for *reading the source*. Manual code review allows the reviewer to think in ways the tools just can't replicate and uncover vulnerabilities that the tools miss. It also helps in evaluating things like maintainability of the library's code base (e.g. if it's a mess, chances are it won't get many contributors willing to do maintenance work). As a bonus, having got to know the library's code base, *using* it (if it passes review) will become a much more natural act.

For general code analysis, it's essential to look for any instances where sensitive information like passwords, API keys, or other confidential data is hardcoded directly into the library's source code. Tools for static and dynamic code analysis are necessary but do not guarantee security just by using them. Your company needs to have a solid, secure development process. It's no use taking care of the code and forgetting about versioning, the APIs used, the secure development mat, etc.

My recommendation is that you don't try to reinvent the wheel. Many well-known and famous libraries are safe, so we should use them. In parallel, we can evaluate the features, maintenance effort, compatibility, and performance with more detail and information and define the criteria for selecting a good library.

Libraries must be updated constantly, not only to have the best versions but also to have the versions considered safest in practice. We must have a system to track versions. This is not only important to record what was used but also to be able to test security in different versions. It is essential to always have a plan B in case libraries used that are from third parties may no longer exist. For almost every library used, we have to have a compensatory one. This plan must be shared with everyone, not just with developers, but the entire IT structure, as many libraries will be able to associate with other equipment, systems or hardware.

Keep your dependencies up-to-date with the latest versions to benefit from security patches and bug fixes. Consider using automated tools that can notify you of new updates and even automate the update process (with proper testing and review of course).

Your company needs to have a process for recording and documenting each stage of library writing. Many developers can change something, and history is significant for evolution, as people can leave the company, but the knowledge needs to be recorded. In addition to improvements, any changes need to be recorded, even if they were unsuccessful, ensuring security depends not only on technical factors but also on the organizational part.

Regardless of the choice of library, the most important thing is to have a team that is aware and knows that the evaluation steps must be followed. We must follow steps when talking about code problems. We have to follow suit. Placing libraries within the DevOps process is exciting and can benefit your company!

Creating of SBOM must be encouraged. Which will help us get a visibility on EOL, EOS libraries. Also, if a alternative is found, SBOM should be maintained accordingly. All 3rd party library should be managed centrally so that it is easy to review it for EOL, EOS and vulnerabilities with the help of Automated tools.