Top 10 open-source security and operational risks of 2023

Endor Labs, a software firm that facilitates the security and maintenance of open-source software, has released a report identifying the top 10 security and operational risks in open-source software in 2023.

Carried out by the Endor Labs’ Station 9 team, the report featured contributions from more than 20 industry chief information security officers from notable companies including Adobe, HashiCorp, Discord and Palo Alto Networks.

According to Endor Labs, the over-reliance on open-source software has recorded some known vulnerabilities, captured as Common Vulnerabilities and Exposures; these vulnerabilities are often overlooked and could be exploited by attackers if not fixed.

“Open-source software represents a goldmine for application developers, but it needs security capabilities that are equally effective,” said Henrik Plate, lead security researcher at Endor Labs. “In an environment where more than 80% of the code in new applications can come from existing repositories, it is clear there are serious risks Involved.”

Top open-source risks of 2023

Highlighted below are the key takeaways of Endor Labs’ report about the top 10 open-source risks of 2023.

1. Known vulnerabilities

The report revealed that an open-source component version may contain vulnerable code accidentally introduced by its developers. The vulnerability can be exploited within the downstream software, potentially compromising the confidentiality, integrity or availability of the system and its data.

2. Compromise of legitimate package

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 hijack the accounts of legitimate project maintainers or exploit vulnerabilities in package repositories. This type of attack can be dangerous since the 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:

• Typo-squatting: The attacker creates a name that is a misspelling of the original component’s name.
• Brand-jacking: The attacker suggests a trustworthy 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 are legitimate.

4. Unmaintained software

Unmaintained software is an operational issue, according to the Endor Labs report. A component or version of a component may no longer be actively developed, which means patches for functional and non-functional bugs may not be provided promptly or not at all by the original open-source project. This can leave the software vulnerable to exploitation by attackers who target known vulnerabilities.

5. Outdated software

For convenience, some developers use an outdated version of a code base when there are updated versions. This can result in the project missing out on important bug fixes and security patches, leaving it vulnerable to exploitation.

6. Untracked dependencies

Project developers may not be aware of a dependency on a component for several reasons:

• It is not part of an upstream component’s software bill of materials.
• Software composition analysis tools are not run or do not detect it.
• The dependency is not established using a package manager, which can lead to security issues, as vulnerabilities in the untracked dependency may go unnoticed.

7. License and regulatory risk

A component or project may not have a license or may have one that is incompatible with the intended use or whose requirements are not or cannot be met.

Using components in accordance with their license terms is crucial. Failing to do so, such as using a component without a license or not complying with its terms, can result in copyright or license infringements. In such cases, the copyright holder has the right to take legal action.

Additionally, violating legal and regulatory requirements can 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 versioning scheme, having a regression test suite, or having review guidelines 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 pose significant operational risks. For instance, the software that depends on it may not function as intended, leading to runtime reliability issues.

9. Unapproved changes (mutable)

When using components that are not guaranteed to be identical when downloaded at different times, there is a significant security risk. This is demonstrated by attacks such as the Codecov Bash Uploader, where downloaded scripts are piped directly to bash without verifying their integrity beforehand. The use of mutable components also poses a threat to the stability and reproducibility of software builds.

10. Under/over-sized dependency

The Endor report pointed out that over/under-dependency on components can be an operational risk. For instance, small components, such as those that contain 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 pipeline vulnerabilities.

On the other hand, huge components may have accumulated many features that are not necessary for standard use cases. These features increase the component’s attack surface and may introduce unused dependencies, resulting in bloated ones.

Steps to take to mitigate these open-source risks

Here are tips from Endor Labs on how software developers and IT managers can mitigate these open-source risks.

Regularly scan code to spot compromised packages

Preventing compromised packages is a complex issue because there is no one-size-fits-all solution. To address this, organizations can refer 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 whether a project follows development best practices

To assess a project’s quality and currency, check its documentation and release notes for completeness and timeliness. Look for badges that indicate test coverage or the presence of CI/CD pipelines that can detect regressions.

In addition, you can evaluate a project by checking the number of active maintainers and contributors, how frequently new releases are made, and the number of issues and pull requests that are opened and closed. It is also crucial to look up information on a project’s maintenance or support strategy — for example, the presence and dates of long-term support versions.

Keep dependencies up to date and check code characteristics before using them

To ensure code security, checking both code and project characteristics is important. Examples of code characteristics to check include pre- and post-installation hooks and encoded payloads. For project characteristics, consider the source code repository, maintainer accounts, release frequency and the 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 make dependency updates and recurring backlog items a priority.

Evaluate and compare software composition analysis tools

Security teams should ensure SCA tools are capable of producing accurate bills of materials, both at the coarse-granular level, such as for dependencies declared with the help of package management tools like Maven or npm, and fine-granular level, such as for artifacts like single files included “out of band” without using package managers.

Use components in compliance with open-source license terms

IT leaders should ensure their software developers avoid using open-source components without a license, as this could create legal risks. To ensure compliance and avoid potential legal issues, it’s important to identify acceptable licenses for components used in software development.

Factors to consider include how the component is linked, the deployment model and the intended distribution scheme. Once you’ve identified acceptable licenses, comply with the requirements stated in those open-source licenses.

Read next: Top cybersecurity threats for 2023 (TechRepublic)