Supply Chain Security

Top 10 Security, Operational Risks From Open Source Code

Endor Labs has introduced an OWASP-style listing of the most important or impactful risks inherent in the use of open source software (OSS).

Kevin Townsend

Published

March 1, 2023

Supply chain attack

Endor Labs has introduced an OWASP-style listing of the most important or impactful risks inherent in the use of open source software (OSS).

Use of OSS is effectively free and readily available – it satisfies the commercial need for speed at low cost in software development. It is not uncommon for more than 80% of modern application code to come from OSS, and it is therefore here to stay (at least until some new technology can provide faster yet still inexpensive software development).

The problem here is that we know very little about the source of the open source we use. It comes without warranties or SLAs; we are usually unaware of the developers of this development tool; and it can introduce major security risks (just think Log4J) without our awareness.

Endor Labs, a startup headquartered in Palo Alto, CA, and founded in 2021 by Dimitri Stiliadis (CTO) and Varun Badhwar (CEO), is a firm focused on the complexities and threats contained in the growing use of OSS in commercial application development.

Its Station 9 research team has now developed and published a report (PDF) on the Top Ten Open Source Software Risks. The hope is to emulate for OSS what the OWASP Top Ten provides for web application security. It lists the ten most important risks (security and/or ops) in order of severity, providing a description, examples, remediation and further reference sources. Like the OWASP list, it will be maintained as the individual risks change or are replaced in severity by new risks.

Unsurprisingly, the current #1 risk is ‘known vulnerabilities’. The Endor description states, “A component version may contain vulnerable code, accidentally introduced by its developers. Vulnerability details are publicly disclosed, for example, through a CVE. Exploits and patches may or may not be available.” Here it is worth noting Rapid7’s research pointing out that 56% of CVE vulnerabilities are exploited within seven days of the public disclosure.

The remaining nine risks are:

The compromise of a legitimate package, where attackers may for example inject malicious code to take advantage of a supply chain attack against users of that code
A name confusion attack, which is like typo-squatting in web-based attacks
Unmaintained software, where the component may unknowingly no longer be maintained or supported
Outdated software, where an old version is in use even though a newer version may be available,
Untracked dependencies, perhaps because it is not part of an upstream SBOM
License and regulatory risk, where – for example – the license may be incompatible with the intended use by a downstream consumer
Immature software, where the OSS project development may not conform to development best practices
Unapproved changes, where a component may change without the developers being aware
Under- or over-sized dependency, where, in the latter case, a component may provide a lot of functionality of which only a fraction may be used

There are, of course, many more than ten OSS risks. “We’ll probably refresh this list at least every year if things change. Some years, nothing will change; some years it will,” Badhwar told SecurityWeek.

You may think that the SBOM was introduced to solve these questions for application developers, but the SBOM is almost unique in being a regulation that is ahead of industry practices rather than behind them. “Industry isn’t ready for the SBOM,” Badwahr said. Automatic generation is usually inaccurate and incomplete. “We need to solve these problems if we are going to pivot toward using the SBOM as the indisputable source of truth for our risk analysis. That’s not the case today.”

It is also worth considering the fragility of the OSS ecosphere despite its importance to much of the commercial applications in use. Badwahr pointed to Core-JS. “Core-JS is a foundational bedrock of the internet. Pick any internet application and you can be certain it uses Core-JS.”

Advertisement. Scroll to continue reading.

But Core-JS is maintained by Denis Pushkarev in Russia. He has made a relatively meagre living from it – until now. Financial contributions from the West into Russia have been hit by western monetary sanctions. According to a report in The Stack, he is being forced to consider alternatives, including making it closed source and commercial.

The reality is that the sustainability of the OSS ecosphere depends upon the sustainability of its contributors, and this is as unpredictable as the future of geopolitics. It is Endor’s hope that the enumeration of the top OSS risks can help focus the minds of application developers on the risks involved in employing open source software – including suddenly unmaintained software (risk #4).