High Level Summary
As new applications continue to heavily rely on open source components, organizations face significant risks related to operational and security issues. In response, Endor Labs, led by Henrik Plate, has published a report outlining the top 10 risks associated with the use of open source components.
The report highlights vulnerabilities such as components containing accidentally introduced vulnerable code, compromised legitimate resources that inject malicious code into a component, and name confusion attacks. Other risks include using unmaintained or outdated components, untracked dependencies, licensing concerns, and immature software. The report also notes that unapproved changes to components and under/over-sized dependencies can cause unexpected outcomes.
These risks have already resulted in major security incidents such as the Equifax data breach, the event-stream incident, and the PyPI attack. Endor Labs' report offers an unprecedented and critical analysis of the complexities of open source software reuse, emphasizing the need for organizations to carefully manage the risks associated with open source components in their applications.Here are the 10 descriptions of the OSS-RISK vulnerabilities with examples:
OSS-RISK-1 - Vulnerable Components: Components within a project may contain vulnerable code accidentally introduced by developers. For instance, a vulnerable component in the Apache Struts framework was exploited in the Equifax data breach of 2017, leading to the theft of personal information of over 147 million consumers.
OSS-RISK-2 - Compromised Packages: Attackers may compromise legitimate resources that are part of an existing project or distribution infrastructure to inject malicious code into a component. An example of this is the 2018 event-stream incident, where attackers compromised the popular JavaScript package to steal cryptocurrency wallet keys.
OSS-RISK-3 - Name Confusion Attacks: Attackers may create components with names resembling legitimate open-source or system components, suggesting trustworthy authors or playing with common naming patterns. An example is the 2019 npm security incident where an attacker uploaded malicious packages with names similar to popular packages like cross-env and eslint-scope.
OSS-RISK-4 - Unmaintained Components: A component or version may not be actively developed, and thus, patches for functional and non-functional bugs may not be provided in a timely fashion. An example is the OpenSSL Heartbleed vulnerability, where a critical flaw in the library went unnoticed for over two years.
OSS-RISK-5 - Outdated Components: A project may use an outdated version of the component, although newer versions are available. For example, many organizations still use Windows 7, which reached its end-of-life in January 2020 and is no longer receiving security updates.
OSS-RISK-6 - Untracked Dependencies: Developers may not be aware of a dependency on a component, making it difficult to detect vulnerabilities. An example is the 2018 Typosquatting attack, where malicious actors created fake packages that mimicked the names of popular npm packages, which were then downloaded by developers who were unaware of the fake packages.
OSS-RISK-7 - License Risk: A component may not have a license at all or have one that is incompatible with the intended use. An example is the MongoDB license change in 2018, which caused developers to reconsider the use of the database software due to licensing concerns.
OSS-RISK-8 - Immature Software: An open source project may not apply development best-practices, resulting in components that may not work reliably or securely. For example, the 2019 Podevce malware campaign exploited vulnerabilities in a software library that was not developed following best practices.
OSS-RISK-9 - Unapproved Changes: A component may change without developers being able to notice, review, or approve such changes, leading to unexpected outcomes. An example is the 2017 incident where an attacker modified the Python Package Index (PyPI) to inject malicious code into the widely used Python interpreter.
OSS-RISK-10 - Under/Over-Sized Dependencies: A component may provide very little or too much functionality, leading to bloated code or insufficient functionality. For example, the infamous left-pad incident in 2016, where a developer unpublished a small package used by many other projects, leading to build failures across the ecosystem.
Comments