Eliminate vulnerabilities through updating dependencies
The recent vulnerability in Log4j (aka Log4Shell) has required an update of a huge number of applications. Of course, a good developer strives to make his libraries safe under default settings. However, it is impossible to completely eliminate the risk of vulnerabilities. Not just this risk remains one of the most common. Vulnerabilities are identified over time and fixed in later versions. Developers who use third party libraries in their programms, in turn, monitor updates and update the dependencies that are used. If you do not do this, the software becomes obsolete and dangerous to operate. This phenomenon is known as the accumulation of technical debt. Fortunately, modern development tools help identify software weaknesses and make it easier for the developer to keep it up to date. One such tool is the OWASP Dependency-Check Project. It defines dependencies and displays a list of known vulnerabilities for each. Vulnerabilities can be resolved in various ways, including without modification of the software. However, updating a dependency that has a vulnerability to a later version is one of the easiest ways. In this study, we will trace how the release of new versions of libraries is associated with the elimination of vulnerabilities. To do this, we’ll take the most popular Open-source libraries. It should be noted that the OWASP Dependency-Check Project can give both false positive and false negative signals about vulnerabilities. Therefore, it is necessary to consider these signals as suspicion, assumptions about vulnerability. To the extent that these assumptions are correct in each case, it is left to decide separately. Using dependency-check-maven, create a custom maven goal, which for each dependency will display a list of versions and a number of known vulnerabilities in each version. The source code for the created maven goal is available on github.
A small digression about version numbering. As a rule, the version number has forma major.minor.incremental. Updating within the minor version does not affect the API, and it fixes functional errors, optimizations, and resolution of vulnerabilities. Updating within the minor version is the safest and most likely to receive functional errors.
Let’s analyze some of the most important dependencies in the Java world, without which it is difficult to build a complete application.
General remarks.
From here, the most important groups are taken and the most popular libraries are selected from each group. All other things being equal, the preference was given to libraries for which active development is continuing.
| Library/framework name | Current status | Historical overview | Recommendations for upgrading to address vulnerabilities |
|---|---|---|---|
| Web frameworks | Spring Framework | At the moment, the most “clean” framework of the considered ones. No known vulnerabilities were found in recent versions | Vulnerabilities are successfully fixed in versions published in 2016 and later | Upgrade is desirable |
| Apache Struts 2 | MEDIUM vulnerabilities in the latest version | Vulnerabilities are successfully closed in versions published in 2011 and later | Upgrade is desirable |
| Apache Tapestry | MEDIUM vulnerabilities in the latest version | Vulnerabilities are successfully fixed in versions published in 2016 and later | Upgrade is desirable |
| Apache Wicket | Multiple MEDIUM vulnerabilities in the latest version | Vulnerabilities are closed with Minor versions | Updating does not always fix vulnerabilities and may lead to functional defects |
| Vaadin | 2 CRITICAL vulnerabilities in the latest version. Perhaps the worst of the frameworks considered | Version releases have little to do with fixing vulnerabilities | Updating is undesirable |
| Jooby | There are no known vulnerabilities in the latest version | Vulnerabilities are successfully closed in versions published in 2019 and later | Upgrade is desirable |
| Play | There are no known vulnerabilities in recent versions | The vulnerability is successfully closed for versions published in 2016 and later | Upgrade is desirable |
| Lift webkit | 1 HIGH level vulnerability | Release version does not have much to do with vulnerability | Upgrade optional |
| Scalatra | There are no known vulnerabilities in the latest version | There are few vulnerabilities in all published versions | Upgrade are optional |
| Microservices | |||
| Quarkus | One CRITICAL and many HIGH vulnerabilities in the latest version | There are many vulnerabilities in all versions. Most secure versions are 2.2-2.5 | Updates are optional |
| Micronaut | There are no known vulnerabilities in the latest version | Vulnerabilities are successfully fixed in versions published in 2020 and later | Updates are optional |
| JSON processing | |||
| Jackson databind | No known vulnerabilities were found in the latest version | Vulnerabilities are successfully fixed in versions published in 2016 and later | Updates within the invermental versions are optional. It is highly desirable to upgrade to version 2.10 and above |
| XML processing | |||
| Jackson databind | No known vulnerabilities were found in the latest version | Vulnerabilities are successfully fixed in versions published in 2016 and later | Updates within the invermental versions are optional. It is highly desirable to upgrade to version 2.10 and above |
| XStream | There are no known vulnerabilities in the latest version | Up to 2021, versions contain many vulnerabilities | It is highly desirable to upgrade to version 1.4.16 or higher |
| Spring OXM | No known vulnerabilities were found in recent versions | Vulnerabilities are successfully fixed in versions published in 2016 and later | Upgrade is desirable |
| Java/Jakarta EE | |||
| Hibernate JPA | No known vulnerabilities in the latest version | Vulnerabilities are successfully fixed in versions published in 2018 and later | Upgrade is desirable |
| Eclipselink | There are no published vulnerabilities in any of the versions | Upgrade optional | |
| OpenJPA | Versions published in 2018 and later have no known vulnerabilities | Upgrade optional | |
| Mojarra | There are no known vulnerabilities in the latest published version | The vulnerabilities are fixed in versions published in 2013 and later | Upgrade is desirable |
| Apache MyFaces | There are no known vulnerabilities in the latest published version | Vulnerabilities have been successfully resolved in versions published in 2014 and later | Upgrade is desirable |
| Primefaces | There are no known vulnerabilities in the latest published versions | Vulnerabilities are closed with the release of new versions | Minor versions are not available, incremental versions are available by subscription. Update difficult |
The tables above show only the most interesting findings of the study. The complete list of the libraries that have been included in the study can be downloaded here.
The main conclusions.
1) Although most library developers pay attention to fixing vulnerabilities, not everyone does it equally quickly.
2) For most libraries published in 2016 and later, the issue of fixing vulnerabilities is quite important and vulnerabilities are fixed in incremental updates. Some developers do not fix vulnerabilities in incremental updates, but do it with the release of versions with new functionality and optimizations.