3rd Party Libraries: Monitoring Vulnerabilities
At Accenture, “reuse of open-source software (OSS)” is highly emphasized in individual software projects. The reuse of third-party OSS libraries significantly enhances efficiency in software development. In addition to efficiency, security is also an essential aspect for us and our clients. Vulnerabilities in third-party libraries are among the top 10 security risks in web applications (see OWASP Top 10).
This was previously published in German on the CIE blog and co-authored by Jonas Ebel.
A prominent example of such a vulnerability was the “LogShell Vulnerability” in the popular library log4j shortly before Christmas 2021 (e.g., Spiegel, Der Standard, SZ). We leverage automated processes that regularly alert us about this vulnerability and those that didn’t receive as much media attention. This article describes Accenture’s preferred and recommended continuous and automated approach to handling CVEs.
A brief excursion into CVE: Each known vulnerability is assigned a unique ID called CVE (Common Vulnerabilities and Exposures). For the LogShell example, it is CVE-2021–44228. As the example shows, continuous monitoring of all OSS third-party libraries for known vulnerabilities and a defined process for handling identified vulnerabilities are necessary. This is also required in Germany by the BSI Grundschutz in the “Leitfaden zur Entwicklung sicherer Webanwendungen” (component “AUB 6: 3rd Party Software Vulnerability Monitoring”).
We utilize a toolset based on SonarQube and the associated plugins for OWASP Dependency Check for Maven and SonarQube. These tools check the software for CVEs during continuous integration builds and display them on our software quality dashboards.
However, detection is only the first step! Handling CVEs throughout the software lifecycle is crucial.
First, we gather information to understand the CVE in the context of our application. Sources for this include public CVE databases, release notes, or security forums.
Relevant questions include, among others: Which mechanism of the third-party library caused the vulnerability? Which versions are affected? How is the severity rated? What mitigation strategies have already been identified?
Once we have established a basic understanding, we analyse our application’s dependency tree to identify how and where the affected third-party library is integrated. Determining whether it is directly included or included transitively through another library is important. In the latter case, the transitive dependency must also be considered.
Next, we examine five different possible solution strategies:
- Update: Often, the library authors have already released a new version that fixes the issue. In that case, we update the version and perform automated tests to prevent regressions after the change.
- Remove: We also consider whether the use of the library is still necessary or if it has become obsolete. In this case, it can be removed.
- Mitigation: Can the affected functionality be turned off through configuration?
- Allow listing: If the functionality affected by the vulnerability is not used in our application or if it is a known false positive from the OWASP tool, the warning is added to a “whitelist.” This means documenting and justifying why the CVE does not apply to the usage. The entries in this list must be continuously reviewed to ensure their appropriateness.
- Report: If the previous strategies do not lead to a solution, the CVE must be reported to the authors of the third-party library.
This approach enables us to react quickly and effectively to newly identified CVEs and successfully address them. It is an essential component of secure software development that helps us close vulnerabilities promptly after they become known. In a project of moderate size, we have addressed approximately 50 CVEs within a year.
If you have any further questions, please get in touch with me or my colleague.
