Understanding the hidden risks in modern software dependencies.
There is a quiet assumption in many organisations that software risk is primarily a function of what their own developers produce. Secure coding practices, internal testing, and application architecture are treated as the centre of gravity for cyber security.
That assumption no longer holds.
Modern software is not built from scratch. It is assembled. Applications today are composed of layers of third party components, libraries and dependencies, often sourced automatically through package managers. This model has enabled extraordinary speed and innovation. It has also introduced a structural shift in risk that many organisations have yet to fully internalise.
When you deploy software today, you are not just deploying your own code. You are deploying a supply chain.
In many cases, the majority of the code running within an application originates from external sources. A developer may import a single package to deliver a specific function, yet that package can bring with it dozens, sometimes hundreds, of additional dependencies. Each of those dependencies becomes part of the trusted codebase, regardless of whether it is actively used at runtime.
For senior leaders, this creates a fundamental challenge. You are accountable for systems whose behaviour is shaped by code you did not design, do not control, and may not even be fully aware of.
This is not a technical detail. It is a governance issue.
.
The illusion of simplicity
From a development perspective, package managers offer a compelling proposition. They provide rapid access to reusable functionality, reduce duplication of effort, and support consistent builds across environments. They are, in many ways, the foundation of modern software engineering.
Yet this simplicity is deceptive.
Behind a single line of code that imports a library lies a complex dependency graph. That graph expands the attack surface of the application in ways that are not always visible. Even components that are not directly executed may still exist within the environment, creating potential pathways for exploitation under certain conditions.
For boards and senior executives, the key insight is that ease of use at the developer level often translates into opacity at the organisational level. The organisation inherits risk at a scale and complexity that is rarely reflected in reporting.
.
Risk does not enter at the perimeter. It enters through trust
Traditional cyber security models are built around defending boundaries. Networks are segmented. Access is controlled. Threats are monitored at entry points.
Supply chain risk challenges this model.
When a third party package is integrated into an application, it is not treated as untrusted input. It becomes part of the system itself. It operates with the same privileges as internally developed code. This means that if a dependency is compromised, the attack does not need to breach the perimeter. It is already inside.
This shift has significant implications for how risk should be understood at board level.
Security is no longer just about preventing unauthorised access. It is about governing what is authorised in the first place.
.
The scale of exposure is often underestimated
One of the most striking characteristics of modern software ecosystems is their interconnectedness. A single widely used package can be embedded across thousands or even millions of applications. A vulnerability or compromise in that package can propagate rapidly across organisations, sectors and geographies.
This is not hypothetical. It is a recurring pattern.
The same mechanisms that enable collaboration and reuse also enable rapid propagation of risk. A single compromised dependency can cascade through transitive relationships, affecting systems far removed from the original source.
For senior leaders, this creates a challenge of visibility and proportionality.
It is not enough to know whether your own systems are secure. You must understand how dependent they are on external components, how those components are governed, and how quickly risk can spread through the ecosystem.
.
Not all risk is equal, and not all vulnerabilities matter
A common reaction to dependency risk is to focus on volume. How many vulnerabilities exist across our software estate. How many dependencies are in use.
While these metrics can be useful, they can also be misleading.
The presence of a vulnerability in a dependency does not automatically mean that the application is exploitable. In many cases, the vulnerable component may not be reachable in practice. It may exist within the codebase but never be invoked during execution.
This distinction between what is present and what is actually used is critical.
For senior leaders, this reinforces the need for risk based decision making. Resources should be directed towards vulnerabilities that are both exploitable and relevant to the organisation’s operational context. Treating all vulnerabilities as equal can lead to inefficiency, fatigue, and misplaced priorities.
.
Governance must extend across the lifecycle
Managing dependency risk is not a one time activity. It is a continuous process that spans the lifecycle of software.
It begins with selection. Decisions about which components to use should be informed by trust, maintenance history, and transparency. Not every widely used package is well governed. Popularity does not guarantee security.
It continues through integration. The way dependencies are introduced into development environments matters. Controls around source verification, version management, and build integrity play a critical role in preventing unintended or malicious components from entering the system.
It extends into monitoring. Dependencies evolve over time. New vulnerabilities are discovered. Maintainers change. Packages may be abandoned. Without ongoing visibility, organisations can quickly find themselves relying on components that no longer meet acceptable security standards.
And it culminates in response. When issues are identified, organisations must be able to assess their relevance, prioritise effectively, and act in a timely manner.
From a board perspective, this is not about understanding individual tools or processes. It is about ensuring that the organisation has a coherent approach to managing dependency risk across its lifecycle.
.
The human factor remains central
Despite the technical nature of the challenge, human judgement remains at the core.
Developers make decisions about which packages to include. Architects define how systems are structured. Procurement teams influence which suppliers are trusted. Leaders set the tone for how risk is prioritised.
Emerging practices such as AI assisted development introduce additional complexity. When code and dependencies are suggested or generated automatically, the visibility of decision making can decrease. This can lead to the introduction of unnecessary, outdated or insecure components without deliberate scrutiny.
For senior leaders, this reinforces a familiar principle. Technology changes, but accountability does not.
.
From technical detail to strategic question
The risk associated with third party dependencies is often discussed in technical forums. It is framed in terms of vulnerabilities, exploits, and development practices.
At board level, the question is simpler, and more difficult.
Do we understand what we are relying on?
Do we have confidence in how those dependencies are selected, integrated and monitored?
Are we able to respond effectively when something goes wrong?
These are not questions that can be answered solely by technical teams. They require organisational clarity, governance structures, and informed oversight.
.
Trust is the real asset at stake
Ultimately, the issue is not just about code. It is about trust.
Customers trust that your systems will protect their data. Partners trust that your services will behave reliably. Regulators trust that you are managing risk responsibly.
When a supply chain issue leads to a breach or disruption, that trust is tested.
Organisations that treat dependency management as a technical detail risk being caught off guard. Those that recognise it as a strategic concern are better positioned to anticipate, absorb and respond to disruption.
The reality is straightforward. Your software is only as trustworthy as the components it depends on.
For senior leaders, the challenge is to ensure that this dependency is understood, governed and aligned with the organisation’s risk appetite.
Because in modern software, what you did not write may matter just as much as what you did.
