Open-source software is becoming more popular, which is beneficial for many reasons, but with this comes an inevitable rise in the number of open-source vulnerabilities and misconceptions. In this blog, we will explore why you shouldn’t ignore Log4j or leave high-severity vulnerabilities in application codes.
Vulnerability analysis
A recent statistic claimed that “96% of Log4j in use… was not vulnerable to the Log4Shell zero-day”. Although this seems like a great result that means you only have to worry about fixing 4% of your applications, it is important to consider how vulnerability analyses are performed.
Vulnerability analysis is sometimes known as “exploitability analysis”, “reachability analysis”, or “attackability analysis”, but it simply means analysing whether the conditions for triggering a vulnerability are present in the application. It usually relies on static analysis to work out an approximation of what the program will do. The fact that it is approximate (i.e. not entirely accurate) is why it carries risk. While vulnerability analysis is helpful for some things, it should not be used to ignore high-severity vulnerabilities.
Static analysis questions are approximate because they are undecidable, meaning there is no guaranteed way to always give a correct yes-or-no answer. This means that the analysis could report a “false positive”, that an application is vulnerable but it is actually not, or a “false negative” where it says everything is safe but there is actually a vulnerability. False negatives are the biggest problem as they give reassurance when there could be a significant risk. In many cases, vulnerability analysis is unlikely to be completely accurate, especially in commercial static analysis, where false negatives are promoted to keep false positives down and produce clear and actionable results.
What does this mean?
While low false negative rates may be acceptable for low-to-medium-severity security issues, high-severity security issues should never be ignored. For demonstrative purposes, imagine the false-negative rate is 1% (this is actually much lower than the industry average) and use the study we mentioned above that 96% of repositories that use insecure versions of Log4j are “not vulnerable”. In an organisation with 100 repositories, the probability that at least one of these has a vulnerability is a staggering 62% – even though it was reported as secure. Log4Shell is still being actively exploited and gives the attacker full control, making this an unacceptable risk.
Plus, even if an application had a 0% false negative rate, it could become exploitable over time as attackers discover new ways to exploit vulnerabilities. Software is constantly changing, and a small update could make a vulnerability apparent.
What can you do?
All of these factors mean that you should shift to patched versions of Log4j and stay ahead of vulnerabilities by upgrading applications. This work can be tracked and kept manageable with the development team’s capacity – the same can’t be said for unplanned work from security attacks. Pair vulnerability analysis with other risk assessment tools and address highest-severity vulnerabilities first, such as applications that are open to public internet or handle untrusted data.
Knowing what’s in your software is the first step to securing it.
We provide a simple three step process to help you manage your Open Source Software supply chain. Learn more about our Open Source Review.