Skip to main content

Dependency Risk

Software Dependency Risk

Software Dependency Risk

Software dependency risk refers to the potential negative consequences of relying on external software components that can compromise the security, performance, quality or functionality of an organization's software systems.

Open source software may depend on a small number of volunteers who may lose interest, motivation, or resources over time. Users and contributors need to ensure that the projects they rely on or contribute to have a healthy and active community, or be prepared to step in and provide alternatives if a project is losing momentum.

Quality​

Open source software may vary in quality, reliability, and performance depending on the skills and experience of the contributors. Users and contributors need to evaluate the quality of the code, documentation, testing, and reviews before using or contributing to a project. There are vendor tooling and suggested self administered maturity surveys to develop the scoring methods.

Sustainability​

Open source sustainability refers to the long-term viability and health of open-source software projects. Key issues in sustainability include Key Person Risk (including burn-out from key maintainers) and lack of funding.

Are Open Source Projects More Sustainable Than Internal Ones?​

Open Source projects by definition have a wider pool of users and contributors to draw from than internal projects. Deutsche Bank Open Sourced the Spring-Bot project and donated it to FINOS as this was seen to be more likely to result in the long-term viability of the project than maintaining it in-house.

Vulnerability​

A software vulnerability is a flaw or weakness in a software program's design, implementation, or operation that, if exploited, can compromise the security, functionality, or data integrity of a system. This can result in Data Leakage or Legal Action.

Example: In 2017, credit reporting agency Equifax suffered a massive data breach that exposed the personal information of approximately 143 million Americans. The breach included names, birthdates, social security numbers, and other sensitive information. The breach led to a drop in the company's stock price and widespread public outrage. This was caused by an open source vulnerability:

A key security patch for Apache Struts was released on March 7, 2017 after a security exploit was found and all users of the framework were urged to update immediately. Security experts found an unknown hacking group trying to find websites that had failed to update Struts as early as March 10, 2017 as to find a system to exploit. - 2017 Equifax data breach

Example: In 2014, a critical security vulnerability called the Heartbleed bug was discovered in the widely used OpenSSL encryption library. This bug allowed attackers to access sensitive information, including passwords and encryption keys, from systems that relied on the affected version of OpenSSL. See CVE-2014-0160

Example: In 2016, a popular JavaScript library called "left-pad" was removed from the npm repository, causing widespread disruption for developers and organizations that relied on this library. The incident highlighted the risks of relying on external dependencies, as well as the importance of having contingency plans in place to manage dependency risks.

See Also:

Risk Management Activities​

Software Inventory

Software inventory is a precondition to most of the activities involved in OSMM level 2. The first step to licence compliance or supply chain security is to understand what software is in your estate.

Making The Case For Contribution

Organisational change can be very hard to achieve since organisations are naturally protective of themselves and the status quo. Setting up an OSPO and beginning an open source journey will seem like a risky and dangerous proposition for many parts of an organisation.