The Endor Labs Station 9 research team worked with more than 20 CISOs and CTOs from companies such as Adobe, HashiCorp, Discord, and Palo Alto Networks to identify the top 10 security and operational risks introduced by reliance on open source software.
“Although the software supply chain relies heavily on OSS, the industry lacks a consistent way to understand and measure OSS risk. Risk management in OSS started with license management and evolved into CVE, but we still lack a holistic OSS risk management approach that encompasses security, legal, and application resiliency.“
The top ten OSS risks specifically include:
| risk | describe | category |
| OSS-RISK-1 Known Vulnerabilities | A component version may contain vulnerable code, accidentally introduced by its developer. Vulnerability details are publicly available, for example via CVE. Bugs and patches may or may not be available. | security |
| Compromise of the OSS-RISK-2 legal package | An attacker could compromise a resource that is part of an existing legitimate project or distribution infrastructure in order to inject malicious code into the component, for example, by hijacking the account of a legitimate project maintainer or exploiting a vulnerability in a package repository. | security |
| OSS-RISK-3 name obfuscation attack | Attackers may create components with names similar to legitimate open source or system component names (brand-jacking), imply trustworthy authors (brand-jacking) or use common naming patterns across different languages or ecosystems (combo-squatting). | security |
| OSS-RISK-4 Unmaintained Software | Components or component versions may no longer be actively developed, and as a result, patches for functional and non-functional bugs may not be provided in a timely manner (or at all) by the original open source project | Ops |
| OSS-RISK-5 Outdated Software | A project may use old, outdated versions of components (although newer versions exist). | Ops |
| OSS-RISK-6 Untracked Dependencies | A dependency on a component may not be known to the project developer at all, for example, because it is not part of the upstream component’s SBOM, because the SCA tool is not running or not detecting it, or because the dependency was not established using a package manager. | Security,Ops |
| OSS-RISK-7 License Risk | A component or item may not have a license at all, or may be incompatible with its intended use, or its requirements may not or cannot be met. | Ops |
| OSS-RISK-8 immature software | Open source projects may not apply development best practices, for example, not use standard version control schemes, have no regression test suites, review guidelines, or documentation. As a result, components may not function reliably or safely. | Ops |
| OSS-RISK-9 Unapproved Changes (variable) | Components may change without the developer’s ability to notice, review, or approve such changes, for example, because a download link points to an unversioned resource, because a versioned resource has been modified or tampered with, or because of insecure data transmission. | Security,Ops |
| OSS-RISK-10 is under/overly dependent | A component may provide little functionality (such as npm micro packages) or a lot of functionality (maybe only use a small part of it). | Security,Ops |
Henrik Plate, principal security researcher at Endor Labs Station 9, said the proliferation of high-impact vulnerabilities including Log4Shell, Heartbleed, Shellshock, and malware components is significantly changing how organizations view open source. “It is well known that open source software is generally more performant and more secure than proprietary software. But it is also clear that open source software comes as-is without any kind of warranty and any risk of using it is borne by the downstream user. This is exactly The industry should be aware of the reasons for these risks.”
Plate also states, however, that the report is not intended to be critical of open source projects; the goal is to help professionals identify the most serious security and operational risks to upstream components and deploy the best remediation strategies. The organization says it will regularly update the Top 10 list and provides some measures to mitigate risks:
- Code is scanned periodically to find
- Checks if a project follows development best practices
- Keep dependencies up to date and check code features before use
- Evaluate and compare software composition analysis tools
- Use components that comply with the terms of open source licenses
See the full report for details.
Further reading:
#Top #Open #Source #Software #Security #Risks #News Fast Delivery #Chinese #Open #Source #Technology #Exchange #Community