The double-edged sword of open-source software

The lack of visibility into the software supply chain creates an unsustainable cycle of discovering vulnerabilities and weaknesses in software and IT systems, overwhelming organizations, according to Lineaje.

open source dependencies

Diversity and complexity of the open-source community

Lineaje Data Labs analyzed 41,989 open-source components embedded in the top 44 popular projects of the Apache Software Foundation across its last three versions. The analysis revealed that 68% of dependencies are on non-Apache Software Foundation open-source projects.

These dependencies make even Apache Software Foundation’s integrity and inherent risk only as strong as the weakest component it embeds. With direct dependencies accounting for only 10%, the remaining 90% are transitive dependencies, which are not easily visible to developers selecting these packages. This creates an opaque and deep software supply chain invisible to developers.

“It’s fascinating to note that although Apache is a large contributor to open-source software, a good portion of the software it relies on is non-Apache Software Foundation. This highlights the incredible diversity and complexity of the open-source community,” said Manish Gaur, Head of Product Security at VMware after reviewing the research report.

Choosing dependencies based on their popularity

Extremely high inherent risk – 82% of components are inherently risky due to vulnerabilities, security issues, code quality or maintainability concerns.

Popularity of software does not indicate quality – Thus, choosing dependencies based on their popularity is not a reliable risk mitigation approach. Apache Software Foundation’s eCharts is its most popular package and is also one of the riskiest, for example.

The mirage of patching vulnerabilities – While organizations drown in a sea of patches they must apply, the research uncovers that 64.2% of all vulnerabilities have no fixes available yet — so they cannot be patched.

At the same time, due to the deep transitive nature of dependencies, another 25.8% of all vulnerabilities are not patchable by the organization deploying or including open-source software. Effectively, complete patching — if achieved — addresses only about 10% of the vulnerability exposure of an organization.

Detecting tampering vital to maintaining software integrity

It is crucial to note that the most significant risk lies not in the vulnerabilities that are not patched, but in those for which no fixes exist. These vulnerabilities continue to exist and pose a persistent threat, regardless of other patches applied.

The ability to detect tampering of the software supply chain is directly linked to software integrity. Of the tens of thousands of open-source projects decomposed by Lineaje Data Labs, results showed:

  • Unknown components – While the majority of software assessed had high integrity attestable components, our research reveals that about 3% of all components had no known origin. These are deeply embedded in Apache Software Foundation software, and their origin and update mechanisms are opaque.
  • Dubious origin components – 5.3% of components failed a basic integrity check that the package published by developers matched the source code it claimed to be associated with. This kind of integrity check would have flagged both the recent 3CX compromise as well as the SolarWinds compromise.

“It’s imperative that organizations today understand that open-source software has risks and is tamper-able, even if it is very popular or provided by an established brand,” said Lineaje CEO Javed Hasan.

“With more software being assembled than built, it’s become more important than ever to have formal tools to discover software DNA. Developers do not have X-ray vision to see inside a software component they include nor are most open-source selectors security experts. We must use software supply chain management tools like SBOM360 to continuously assess the dynamic, inherent risk and integrity of these software components that are built left of shift-left,” concluded Hasan.

Don't miss