2023 OSSRA deep dive: jQuery and open source security

According to the 2023 “Open Source Security and Risk Analysis” (OSSRA) report, 96% of commercial code contains open source. In fact, 76% of the code scanned by Black Duck® Audit Services was open source. In other words, no matter what applications your organization builds, uses, or sells, you can be virtually certain that the application contains open source. And you shouldn’t be surprised if you found that the code in those applications—whether designed for the web, in-house, desktop, mobile, embedded, or some other use—was primarily open source.

Commercial code vs. open source: Push vs. pull

With open source so prevalent in commercial applications, the question becomes: “What are you doing to ensure that the open source in your software is secure?”

As we’ve pointed out in every OSSRA report since 2017, the key term in that question is “you.” While open source is not less secure than commercial code, it is different from commercial code, especially when it comes to updates and patches. Most commercial entities “push” their code updates to users, who generally don’t have to do anything more than approve the update’s installation.

Open source uses a “pull” model. Developers and end users have the responsibility to keep their open source components healthy, secure, and up-to-date by locating, downloading, and installing the latest version of those components. Of course, this presupposes a developer/end user 1) is aware that the problematic open source component is in their software, and 2) knows what version of the component they have in use.

Unfortunately, it’s a fragile supposition, as the data from the 2023 OSSRA report demonstrates. As noted in the report, 84% of the codebases examined by Black Duck Audit Services contained at least one known open source vulnerability, 48% contained high-risk vulnerabilities, and nearly all (91%) contained outdated versions of open source components—an update or patch for the component was available but had not been applied.

Looking at jQuery in the 2023 OSSRA report

As an example, let’s look at one of the most popular components identified in the codebase audits that were the basis for OSSRA report data, the open source JavaScript component, jQuery. The 2023 OSSRA report found the library in nearly half—45%—of the audited codebases.

With a motto of “write less, do more,” jQuery provides simple libraries that accomplish otherwise complex JavaScript tasks like handling user/browser events, manipulating webpages in real time, making animations, and coordinating communication between the client and server. Some organizations are starting to move away from jQuery and toward more complicated web components and single-page apps, it is still estimated to be used in over 70 million websites.

But like in Hollywood and high school, problems sometimes accompany popularity. jQuery was also found to be the component most likely to be vulnerable in the OSSRA audits. Nearly half—47%—of the codebases contained a vulnerable jQuery component. The most likely candidate for that vulnerability was CVE-2020-11023 (BDSA-2020-0964), a cross-site scripting (XSS) vulnerability in jQuery versions 1.0.3 to 3.5.0. This vulnerability could allow an attacker to inject malicious code into a website using jQuery.

The persistence of vulnerabilities

Forty-three percent of the audited codebases containing jQuery also contained CVE-2020-11023. Forty-three percent! The kneejerk reaction to those findings might be to consider discarding jQuery altogether when it’s a coin-flip whether a jQuery library may be accompanied by a vulnerability.

Yet the jQuery community had the component patched and updated almost immediately after the vuln was disclosed in May 2020, so the blame shouldn’t be assigned there. Like open source itself, the underlying security issue isn’t jQuery, it’s users not keeping the open source they use up-to-date. Need proof? Of the 1,481 codebases examined by the Black Duck Audit Services team in 2022, 91% contained outdated versions of open source components.

More than a year after its disclosure, Log4Shell is another example of an evergreen vulnerability. Despite the media attention it received and the numerous avenues organizations can take to confirm its presence and remediate it, the 2023 OSSRA report data still found vulnerable versions of Log4J in 5% of the total codebases scanned, and in 11% of Java codebases.

It’s also worth noting that the same jQuery vulnerability—CVE-2020-11023—was also found in 43% of the codebases scanned the previous year for the 2022 OSSRA report. This is more proof that developers and users are either deferring updating vulnerable open source components or unaware that the vulnerabilities are there.

Of course, there can be valid reasons for not keeping software up-to-date. A DevSecOps team might determine that the risk of unintended consequences outweighs whatever benefit would come from applying the newer version. Embedded software may be at minimal risk from vulnerabilities that can only be introduced from an external source. Or it could be a time/resources issue. With many teams already stretched to the limit building and testing new code, updates to existing software can become a low priority except for the most critical issues.

But it’s more likely that the majority of unpatched open source components are due to a DevSecOps team not knowing that there is a newer version of the component available—if they are aware the component is there at all. Dev teams are constantly changing; people take on new projects or leave the organization altogether, and group knowledge regularly gets lost.