In part two of the “Two Factors that Affect Software Security” blog series, we’ll dive deeper into open-source software (OSS). OSS has become very popular these days. However, as with most things, there is a “trade-off curve”. While the use of OSS can drive down product creation costs and improve time to market, software security and product integrity risks increase substantially with its use. This is because of one fundamental error in thinking – that the OSS components will have been properly and rigorously reviewed by “others.” Often, this is probably not the case for the same reason that this engineering team wants to use OSS in the first place – they don’t have time to create and rigorously test code; and are hoping others have done it for them. This is why the dependence on OSS is creating real concerns about national security and data privacy. 

A Dark Reading article from 2022 showed that the idea of rigorous testing isn’t true. Researchers at Johns Hopkins University conducted a study on a popular library of code called Node.js. They discovered 180 zero-day vulnerabilities across the Node.js libraries they examined. There were several security vulnerabilities including injection flaws and cross-site scripting. Seventy of the flaws were assigned their own common vulnerabilities and exposures (CVE) identifier.   

Another example is the Log4Shell vulnerability that was found in the Log4j library in 2021. The Apache Log4j is a popular Java library for logging error messages in applications. The vulnerability, originally published as CVE-2021-44228, ended up having three more related vulnerabilities. Again, just because a piece of software was reviewed by a group, doesn’t mean it’s safe.

A Synopsis 2024 Open Source Security and Risk Analysis Report found even more bad news. Here are some highlights: 

• 84% of codebases assessed for risk contained vulnerabilities 

• 74% of codebases assessed for risk contained high-risk vulnerabilities 

• 91% of codebases contain components that have had no new development in over two years 

• 91% of the codebases assessed for risk contained components that were 10 versions or more behind the most current version of the component 

• 89% of codebases contain OSS that is more than 4 years out of date 

• The average number of open-source components in a given application this year was 526 

• 54% increase in codebases containing high-risk vulnerabilities over the past year was found 

• 14% of the codebases assessed for risk contained vulnerabilities older than 10 years 

A key point exposed by the Synopsis report is the update process for OSS code. What happens to the code after a year, two years, and more. Does anyone go back and update it to eliminate (or at least reduce) software vulnerabilities? While there are some examples of this, the Synopsis report found that 91% of codebases contain components that did not have any new development updates in over two years. The report did show that the number improved by 2 points (dropping to 89%) for code that was 4 years or so out of date.

So, based upon the Synopsis results, there is clear concern with the use of OSS. Especially since the National Bureau of Economic Research estimates that over 90% of Fortune 500 companies are actively using OSS. This potentially puts a lot of American enterprises, and the US government buying those solutions, at a heavy risk for hidden security and operational flaws. In fact, OWASP is so concerned that we still lack a holistic approach to OSS risk management that encompasses security, legal, and operational aspects that they created a top 10 list of security and operational issues associated with the use of OSS. 

These facts and figures should make any purchasing team nervous. While the vendor may sign off on their software, if they are using OSS, there’s a chance your network could be compromised in the future. One of the best ways to avoid the situation is to buy software solutions that do not heavily rely on OSS. While a usage of 0% OSS is technically possible, you will be hard pressed to find a manufacturer that does not use any OSS. 

A reduced OSS dependency plan gives you two clear benefits. First, you have a substantial possibility of reducing your security risk by not using potentially compromised software. Second, bad actors are generally less inclined to spend time trying to attack proprietary code. There is little in it for them. It takes a lot of time to analyze the code for defects; and even harder for them to get their hands on proprietary code in the first place. It’s so much easier to analyze OSS for flaws, then find products using that OSS, and then attack multiple company products that use that same code. Once they have found an OSS defect, they can literally attack 5, 10, or more products by exploiting the one or two defects that they find in the OSS code. 

Axellio uses United States citizen workers and does not overly rely on the use of open-source code. Axellio carefully manages its use of open-source components and rigorously tests and evaluates the code used to reduce exposure to vulnerabilities. If you want additional information, check out this sales brief.