The benefits of open-source software are many. IT professionals can use already developed code while hopefully contributing their work to others, saving time and money through collaboration. It is also widely known that open-source software is often more secure than proprietary software.
However, open-source software creates security risks that organizations must address. According to a new study from Endor Labs, 80% of code used in modern applications is code generated through open-source packages.
For its study, Endor Labs, which provides a dependency lifecycle management platform, has outlined the top 10 problematic properties of open-source software.
A component version may contain vulnerable code accidentally introduced by its developers. Vulnerability details are publicly disclosed, e.g., through a CVE. Exploits and patches may or may not be available.
Attackers may compromise resources that are part of an existing, legitimate project or of the distribution infrastructure to inject malicious code into a component, e.g., by hijacking the accounts of legitimate project maintainers or exploiting vulnerabilities in package repositories.
Attackers may create components whose names resemble names of legitimate open-source or system components (typo-squatting), suggest trustworthy authors (brand-jacking), or play with common naming patterns in different languages or ecosystems (combo-squatting).
A component or component version may not be actively developed anymore. Thus, patches for functional and non-functional bugs may not be provided promptly (or at all) by the original open-source project.
A project may use an old, outdated version of the component (though newer versions exist).
Project developers may not be aware of a dependency on a component at all, e.g., because it is not part of an upstream component's SOM, because SCA tools are not run or do not detect it, or because the dependency is not established using a package manager.
A component or project may not have a license, one incompatible with the intended use by a downstream consumer, or one whose requirements are not or cannot be met by a downstream user.
An open source project may not apply development best practices, e.g., not use a standard versioning scheme, have no regression test suite, review guidelines, or documentation. As a result, a component may not work reliably or securely.
A component may change without developers being able to notice, review or approve such changes, e.g., because the download link points to an unversioned resource because a versioned resource has been modified or tampered with or due to an insecure data transfer.
A component may provide very little functionality (e.g., pm micro packages) or a lot of functionality (of which only a fraction may be used).
“Open source risk management has fallen behind open source usage,” said Endor Labs CEO and co-founder Varun Badhwar. “At their core, most open source security programs focus on license compliance and known vulnerabilities, which do not capture the biggest risks to modern software supply chains.”
Organizations must evaluate and manage their open-source software dependencies to identify and mitigate risks properly.
Direct software dependency is explicitly defined and included in a developer’s code base, offering users more transparency around how components interact. The software often relies on transitive dependencies, which are not always expressly included in a developer’s code. For example, a library or module might depend on the software that depends on separate unlisted software. Identifying all dependencies and analyzing the relationships between dependencies is a crucial step for risk mitigation.
The No. 1 risk, however, is using components with known vulnerabilities – e.g., Log4Shell. The financial and reputational damage can be significant, as demonstrated by incidents like the 2017 Equifax data breach, where overall costs exceeded $1 billion.
IT pros will most likely overlook OSS-Risk-10, under/oversized dependency, said Endor Lab’s lead security researcher, Henrik Plate. “That’s because developers commonly have little insight into the size of a dependency, especially if it is indirect, and whether they use a small or significant share of its code,” Plate noted.
Endor Labs does not expect the open-source software risks outlined in its list to change significantly anytime soon. However, the threat landscape evolves quickly as attackers devise new techniques to subvert the security of software supply chains. IT pros should expect new countermeasures as risks emerge and advancements in the regulatory environment for software and service providers.
Follow us on LinkedIn
Kamal Rastogi is a serial IT entrepreneur with 25 yrs plus experience. Currently his focus area is Data Science business, ERP Consulting, IT Staffing and Experttal.com (Fastest growing US based platform to hire verified / Risk Compliant Expert IT resources from talent rich countries like India, Romania, Philippines etc...directly). His firms service clients like KPMG, Deloitte, EnY, Samsung, Wipro, NCR Corporation etc in India and USA.