As the SolarWinds and Log4j hacks show, vulnerabilities in open source software used in application development can open doors for attackers with vast consequences. A new study looks at the open source community’s efforts to “credit-rate” the risk.

It was almost exactly one year ago that experts found the infamous Log4Shell error message vulnerability in the open source Java library Apache Log4j 2. The weakness was just one recent example of a backdoor in open source software for attackers to sneak malicious code onto developer and end-user systems. Since then, there have been tens of millions of attempts to compromise the Log4jShell flaw.

SEE: Iranian state-aligned threat actor targets new victims in cyberespionage and kinetic campaigns (TechRepublic)

If experts identify the software supply as a key security challenge for 2023, the Log4j phenomenon — not to mention the much-better known Sunburst malware incursion (popularly referred to as the SolarWinds attack) in December, 2020 — shed light on how protecting the process could be difficult: A vast amount of commercial software is not written in-house. It is derived from the wild west of free and open source software packages like Log4j on GitHub and elsewhere.

Open source software dependencies have dependencies

Like a gardener trying to grab just one ivy plant, an application developer who imports code from the FOSS ecosystem often gets more than the code they bargained for because those extramural packages from repositories like GitHub often bring along transitive dependencies. These are the secondary and tertiary relationships that a FOSS package has with other open source code, constituting a “hidden” root-like system of software of unknown provenance, invisible to developers, intrinsically untrusted and potentially dangerous.

SEE: Improper use of password managers leaves people vulnerable to identity theft (TechRepublic)

A new study titled “The State of Dependency Management” by Endor Lab’s Station 9 revealed that 95% of all vulnerabilities are found in these open source code packages that are not selected by developers but indirectly pulled into projects.

“By some measures, for every one dependency a developer brings into a software project, there are, on average, 77 to 78 transitive dependencies,” said Varun Badhwar, co-founder and CEO of Endor Labs. “Additionally, 95% of vulnerabilities found are in those transitive dependencies, the things that came with the things you brought. We need to track all of this in our environment and understand which apps these packages are being used in.”

Henrik Plate, security researcher at Endor Labs, noted that writing software is now like putting together a BMW.

“You are taking diverse components from somewhere else and assembling them,” Plate said.

Badhwar said 80% to 90% of code in a typical modern application is “code we don’t write, it’s code we borrow, and we really don’t know who we are borrowing it from. Attackers have figured this out; open source software is going to be foundational for the software supply chain security, so we need to better educate the market on the issues.”

He pointed out that the Software Bill of Materials framework, though designed to provide accurate dependency information, rarely does. It especially does not do so for transitive dependencies, given their so-so accuracy at one dependency level.

SEE: How Microsoft will publish info to comply with executive order on software bill of materials (TechRepublic)

Acknowledging the urgency of the FOSS security issue, Congress introduced the Securing Open Source Software Act in September 2022. The bill urged CISA to “publicly publish a framework, incorporating government, industry, and open source software community frameworks and best practices, for assessing the risk of open source software components.” No progress has been made on the bill since its introduction.

Which open source software is critical?

The Log4j investigators attempted to get a handle on whether there is consensus on the most critical FOSS packages for enterprise software. These are the packages that are the most-used by the most developers and downstream users, have the broadest functionality and the greatest potential exposure through dependencies.

To do this, they explored criticality scores from the two most popular community initiatives to identify critical projects: the Linux Foundation-supported “Census II of Free and Open Source Software — Application Libraries” and the Open Source Security Foundation’s Criticality Score project.

“We wanted to know whether those approaches converge; thus, whether they agree on what is critical and what is not,” Plate said.

There wasn’t much overlap in the Census II and OpenSSF Criticality Scores project sets. The study noted that a number of Census II packages came from the same project and that 264 Java-based packages in Census II’s group come from only 169 distinct projects (Figure A).

Figure A

This wasn’t surprising to Professor Justin Cappos at NYU Tandon’s School of Engineering, a security expert who has been working in the software supply chain security space for more than a decade.

“We actually did our own analysis of which open source projects are critical and decided not to release the data, because we couldn’t come up with a solid enough metric to measure criticality,” Cappos said. “It’s a hard problem.”

The Endor team also found that:

• Half of the most commonly used open source packages were not updated this year, and 30% had their last release before 2018.

• There is a 32% chance the latest version of an open source software package has vulnerabilities.
• When upgrading to the latest version of a package, there’s still a 32% chance it will have known vulnerabilities.
• 75% of the packages in Census II have a Criticality Score of less than 0.64 — that’s on a scale from zero to one, with zero being least critical.
• Using security metrics alone when making prioritizations only reduces the likelihood of a vulnerability by 20%.

Open source: Caveat emptor

Badhwar noted that ultimately it will be up to organizations to take ownership of the FOSS vetting process, because it’s their responsibility to weed out the faulty software once it has suffused itself into their infrastructure.

“It took something in the neighborhood of 33,000 hours for the DHS to figure out where Log4j had gone and then remediate it,” he said. “Every organization and software vendor should track every component and dependence in their environment, and that starts with tracking to generate a software-level inventory of what developers are bringing from the internet.”

Plate said criticality varies and that determination can’t be outsourced.

“Every user has their own security requirements,” he said. “Ultimately, the development organizations remain accountable for the commercial software services and products they sell, so those are other reasons this cannot just be outsourced to the open source community.”