Are you surprised to know that more than 50 percent of the Global 500 use vulnerable open source components? There is no doubt that open source is powerful, yet it brings a lot of concerns around security. It’s interesting that Aspect Security wrote a paper 2 years ago about application security's greatly ignored problem, and yet the use of open source has more than doubled since then (from 6 billion to 13 billion component downloads per year).
Security Breaches are only growing
Mind us to remind you that according to Identity Theft Resource Center (ITRC) research, the total number of data breaches through September 30, 2021 has already exceeded the total number of events in 2020 by 17%, with 1,291 data breaches in 2021 compared to 1,108 breaches in 2020. Hackers are focusing on the software supply chain, including third party components. One recent example of a vulnerable third-party is Log4j.
Impact of Apache Log4j vulnerability
The log4j security vulnerability allows attackers to execute malicious code remotely on a target computer. Bad hackers can easily steal data, install malware, or simply take control of a system via the Internet. Apache Log4j vulnerability has impacted over 44% of corporate networks worldwide.
"As per Cybersecurity firm Check Point, over 800,000 exploitation attempts were detected in the first 72 hours when the Log4j issue became public and experts predict that the Log4j security vulnerability could impact the entire internet taking years to be fixed, simply because 95% of Java programs use Log4j." (https://www.onmanorama.com/news/business/2021/12/21/open-source-software-log4j-vulnerability.html)
So how to fix the problem?
OWASP foundation has a top 10 list for addressing developers and web application security.One of the first step towards more secure code and changing the software development culture is Using the OWASP Top 10 "Vulnerable and Outdated Components".
We, at Mibex use OWASP dependency checker. Many other open source as well as commercial platforms have come with coherent solutions.
How we manage our vulnerable dependencies
We have a nightly build that scans our projects with OWASP dependency checker and fails the build if a certain CVSS score has been reached.
Additionally, we also analyze each new pull request for vulnerable dependencies by using our own Code Review Assistant that can also be configured to show each vulnerability that OWASP finds right in the pull request.
This allows us to discuss vulnerabilities in pull requests early and decide on if we have to react immediately. Additionally, it helps us to keep our main line of development vulnerability-free.
Is that the solution?
We think, no it isn’t. It is a part of it. It is great to have tools at hand that help to identify vulnerabilities. But we also try to be very strict when it comes to the decision of using an external library, because it always could come with undiscovered vulnerabilities, too.