Endor Labs, a software company that facilitates the security and maintenance of open source software, has published a report that identifies the top 10 security and operational risks in open source software in 2023.
Produced by Endor Labs’ Station 9 team, the report featured contributions from more than 20 industry information security officers from notable companies such as Adobe, HashiCorp, Discord, and Palo Alto Networks.
According to Endor Labs, over-reliance on open source software has captured some known vulnerabilities, which were captured as Common Vulnerabilities and Exposures. These vulnerabilities are often overlooked and could be exploited by attackers if left unpatched.
“Open source software represents a gold mine for application developers, but it needs equally effective security features,” said Henrik Plate, chief security researcher at Endor Labs. “In an environment where more than 80% of the code in new apps can come from existing repositories, it’s clear that there are serious risks.”
Top open source risks for 2023
Highlights from Endor Labs’ report on the top 10 open source risks for 2023 are highlighted below.
1. Known vulnerabilities
The report revealed that an open source component version may contain vulnerable code that was accidentally introduced by its developers. The vulnerability can be exploited in downstream software, potentially compromising the confidentiality, integrity, or availability of the system and its data.
2. Legitimate Package Compromise
According to Endor’s report, attackers can target legitimate resources from an existing project or distribution infrastructure to inject malicious code into a component. For example, they can compromise the accounts of legitimate project maintainers or exploit vulnerabilities in package repositories. This type of attack can be dangerous, as malicious code can be distributed as part of a legitimate package and can be difficult to detect.
3. Name confusion attacks
Attackers can create components with names that resemble those of legitimate open source or system components. The Endor Labs report revealed that this could be done through:
- Typographic occupations: The attacker creates a name that is a misspelling of the original element’s name.
- Name: The attacker suggests a trusted author.
- Combo-squatting: The attacker plays with common naming patterns in different languages or ecosystems.
These attacks can be used to trick users into downloading and using malicious components they believe to be legitimate.
4. Unmaintained Software
Unmaintained software is a functional issue, according to Endor Labs’ report. A component or a version of a component may no longer be in active development, which means that patches for functional and non-functional bugs may not be provided immediately or at all by the original open source project. This can leave the software vulnerable to exploitation by attackers targeting known vulnerabilities.
5. Outdated software
For convenience, some developers use an old version of a code base when updated versions are available. This can result in the project missing important bug fixes and security patches, leaving it vulnerable to exploitation.
6. Untracked Dependencies
Project developers may not be aware of a component’s dependency for several reasons:
- It is not part of the software material pricing of an upstream component.
- Software composition analysis tools do not run or detect it.
- The dependency is not built using a package manager, which can lead to security issues as vulnerabilities in the unmonitored dependency can go unnoticed.
7. License and Regulatory Risk
A component or work may not have a license or may have a license that is incompatible with its intended use or whose requirements are not met or cannot be satisfied.
Using components in accordance with the license terms is vital. Failure to do so, such as using an item without a license or not complying with its terms, may result in copyright or license violations. In such cases, the copyright holder has the right to take legal action.
In addition, violation of legal and regulatory requirements may limit or impede the ability to address certain industries or markets.
8. Immature Software
An open source project may not follow development best practices, such as using a standard release scheme, having a regression test suite, or having control instructions or documentation. This can result in an open source component that does not work reliably or securely, making it vulnerable to exploitation.
Relying on an immature component or project can create significant operational risks. For example, software that depends on it may not work as intended, leading to runtime reliability issues.
9. Unauthorized changes (variables)
When you use data that is not guaranteed to be identical when downloaded at different times, there is a significant security risk. This is demonstrated by attacks like the Codecov Bash Uploader, where download scripts are piped directly into bash without first verifying their integrity. The use of mutable components also poses a threat to the stability and reproducibility of software releases.
10. Under/oversize dependency
The Endor report pointed out that excessive/over-reliance on components can be an operational risk. For example, small components, such as those containing only a few lines of code, are vulnerable to the same risks as larger components. These risks include account takeovers, malicious pull requests, and continuous integration and continuous development vulnerabilities.
On the other hand, huge components may have packed a lot of features that aren’t necessary for typical use cases. These features increase the component’s attack surface and can create unused, resulting bloated dependencies.
Steps to take to mitigate these open source risks
Here are tips from Endor Labs on how software developers and IT administrators can mitigate these open source risks.
Scan the code regularly to find broken packages
Preventing compromised packets is a complex issue because there is no one-size-fits-all solution. To address this, organizations can look to emerging standards and frameworks such as the OpenSSF Secure Supply Chain Consumption Framework (S2C2F).
They can select and prioritize the safeguards that best suit their requirements, based on their specific security needs and risk tolerance.
Check if a project follows development best practices
To assess the quality and currency of a project, review its documentation and notes for completeness and timeliness. Look for signals indicating test coverage or the presence of CI/CD leads that can detect pullbacks.
In addition, you can evaluate a project by checking the number of active maintainers and contributors, the frequency of new releases, and the number of issues and pull requests opened and closed. It’s also important to look for information about a project’s maintenance or support strategy — for example, the presence and dates of long-term support releases.
Keep dependencies up to date and check code features before using them
To ensure code security, it is important to audit both code and project features. Examples of code features to check include pre- and post-installation hooks and coded payloads. For project characteristics, consider the source code repository, maintainer accounts, release frequency, and number of downstream users.
One way to keep dependencies up to date is to use tools that generate merge or pull requests with update suggestions. It’s also important to prioritize dependency updates and recurring backlogs.
Rate and compare software composition analysis tools
Security teams should ensure that SCA tools are able to produce accurate bills of materials, both at a coarse-grained level, such as for dependencies declared using package management tools such as Maven or npm, and at a fine-grained level, such as for artifacts such as individual files that are included “out-of-band” without using package managers.
Use components according to the terms of the open source license
IT leaders should ensure that their software developers avoid using open source components without permission, as this could create legal risks. To ensure compliance and avoid potential legal issues, it is important to identify acceptable licenses for components used in software development.
Factors to consider include how the component is connected, the deployment model, and the intended distribution scheme. Once you have identified acceptable licenses, please comply with the requirements stated in those open source licenses.
Read next: Top Cyber Security Threats for 2023 (TechRepublic)