Open source worldwide: Critical maintenance gaps exposed

Lineaje recently released a report identifying the US and Russia as the leading generators of open-source projects, with both countries also having the highest numbers of anonymous open-source contributions.

In this Help Net Security video, Nick Mistry, SVP and CISO of Lineaje, discusses where the deepest layers of open-source software component dependencies originate from and their critical vulnerabilities.

The report revealed that regardless of geographic origin, the average mid-size application has several disturbing trends leading to critical vulnerabilities, including:

Open-source is driving security weaknesses: Open-source contributes 2 to 9 times the code your developers write, and over 95% of security weaknesses originate within open-source package dependencies. Over half (51%) of these vulnerabilities, across all CVE severity levels, have no known fixes. Additionally, 70% of open-source components are no longer maintained or poorly maintained.

Unmaintained open source is less vulnerable: Surprisingly, unmaintained open-source is less vulnerable than well-maintained open source, which is 1.8 times more vulnerable. The high rate of change in well-maintained components enhances risks.

Fixing vulnerabilities is challenging: Individual open-source projects embed up to 60 layers of components from dozens of open-source organizations. They are often assembled in a complex Lego structure in a single dependency that developers include in their organizations’ applications, leading to poor risk assessment and even poorer remediation approaches. Knowing which vulnerabilities developers can fix quickly and which they should not eliminates at least 50% of the vulnerability fix effort and improves security posture by 20-70%.

Version sprawl is causing complications: Over 15% of open-source components have multiple versions in a single application, making remediation efforts more difficult.

Coding language diversity is introducing security risks: A mid-sized application can pull in 1.4 million lines of code across 139 languages and often drags in more risky memory-unsafe languages. Secure-by-design organizations may use memory-safe languages in private code, but their dependencies exacerbate security risks unless the language is a selection criterion for open-source dependencies.

Team size impacts quality and security: Open-source projects staffed by small teams (<10) and large teams (>50) deliver more risky packages than mid-sized teams. Small teams deliver 330% more risky projects than mid-sized teams, while larger teams deliver packages with 40% more risk than mid-sized teams.