Managing dependency risk and transitive dependencies

Modern software delivery depends on packages, libraries, container images, and build tools that rarely come from a single source. That is efficient, but it also means your application inherits code, maintenance decisions, and vulnerabilities from other teams. For UK SMEs, the practical challenge is not just knowing what you directly import, but understanding the nested packages that arrive with those imports. Those nested packages are transitive dependencies, and they often create the largest part of the hidden exposure.

This matters because dependency risk is not limited to obvious open source libraries. It also includes build plugins, runtime frameworks, package registries, container base images, and tooling used by CI pipelines. A weak control in any of those layers can affect confidentiality, integrity, availability, or release confidence. If you are already thinking about software supply chain assurance, this article builds on the same themes covered in software supply chain assurance controls and how third-party software introduces cyber risk, but focuses specifically on dependency graphs and the control patterns that make them manageable.

What dependency risk means in modern software delivery

Dependency risk is the possibility that third-party code, or the way it is consumed, introduces security, operational, or governance issues into your product. In practice, that risk comes from three places: the code itself, the trust relationship with the source, and the change rate of the ecosystem around it. A package can be safe today and problematic next week if a maintainer account is compromised, a new version introduces a breaking change, or a nested package brings in a vulnerability you did not choose directly.

Direct dependencies versus transitive dependencies

Direct dependencies are the packages your team explicitly adds to a project. Transitive dependencies are the packages those packages bring along. If your application imports a framework, and that framework imports a logging library, and that logging library imports a parsing library, you now depend on all three. The deeper the tree, the less visible the risk becomes to developers who only review the top-level manifest.

That distinction matters for control design. Direct dependencies are usually easier to justify, review, and pin. Transitive dependencies are often accepted implicitly, which means they can bypass normal approval steps. In a small team, that is where surprises tend to appear during build failures, vulnerability alerts, or emergency patching.

Why package depth matters in risk assessments

Package depth is a useful proxy for complexity. The more levels in a dependency tree, the more likely you are to encounter version conflicts, duplicate libraries, abandoned packages, and hidden attack surface. Deep trees also make it harder to answer basic questions such as which component introduced a vulnerable function, whether a package is used at runtime or only during build, and whether an update can be applied safely without breaking the application.

From a risk assessment perspective, depth should influence both likelihood and impact. A shallow tree with well-maintained packages is easier to govern than a deep tree with many unmaintained components. This is one reason software teams increasingly use dependency graphs and software bills of materials, or SBOMs, to improve visibility before they need to respond to a problem.

Where dependency risk sits in the wider software supply chain

Dependency risk is one part of the wider software supply chain picture. It sits alongside source control integrity, build pipeline security, signing, provenance, release governance, and supplier assurance. If you only scan for known vulnerabilities, you will miss other issues such as malicious package publishing, dependency confusion, or a compromised maintainer account. If you only focus on procurement, you may miss the operational reality of how packages are resolved during builds. Good control design needs both views.

Why transitive dependencies create hidden exposure

Transitive dependencies are attractive to attackers and troublesome for defenders because they are often trusted by default. They are pulled in automatically, updated indirectly, and rarely reviewed with the same care as the packages a team selects intentionally. That creates a gap between what engineers think they are using and what the application actually contains.

Version drift and unplanned upgrades

One common issue is version drift. A parent package may allow a range of versions for its nested dependencies, so a routine install can resolve to a different build than last week. This can happen even if your own manifest has not changed. In ecosystems that favour flexible version ranges, the result is a moving target that complicates reproducibility and incident response.

For release engineering, this means a build is not fully deterministic unless you control the resolved dependency set. If you cannot reproduce the same artefacts from the same source inputs, you will struggle to prove what was tested, what was deployed, and what changed between releases.

Unreviewed code paths introduced by nested packages

Nested packages can introduce code paths that your team never reviewed. That may include deserialisation logic, network clients, cryptographic helpers, or telemetry features. Even when the top-level package is reputable, a transitive package can widen the attack surface in ways that are not obvious from the application codebase alone.

This is especially relevant where packages are used at build time rather than runtime. Build tools often have broad filesystem access, network access, and secrets available in the pipeline. A compromised build dependency can therefore have a different and sometimes more privileged impact than a runtime library.

Attack surface created by build and runtime dependencies

It helps to separate build dependencies from runtime dependencies. Build dependencies affect how software is compiled, packaged, tested, or deployed. Runtime dependencies are loaded by the application in production. Both matter, but build dependencies can be overlooked because they are not visible to end users. A malicious package in the build chain can tamper with artefacts before they are signed or deployed, which is why pipeline controls and package trust controls should be treated as part of the same risk domain.

How transitive dependencies show up in common ecosystems

Different ecosystems expose dependency risk in different ways, but the underlying problem is the same: the package manager resolves a graph, not just a list. Security teams need to understand how that graph is formed and where it can be influenced.

npm and JavaScript package trees

JavaScript ecosystems often have large and deep trees because many packages are small and highly composable. npm can resolve multiple versions of the same package in different parts of the tree, which makes it easy to end up with duplicate code and inconsistent patch levels. Lockfiles help, but they only work if they are committed, reviewed, and regenerated deliberately. Without that discipline, a seemingly minor update can pull in a new nested package with a different risk profile.

For teams using npm, it is worth checking whether the project relies on broad semver ranges, whether lockfiles are enforced in CI, and whether package installation is allowed from public registries without any additional trust controls. Those are not just developer convenience choices. They are security decisions.

Maven and Java dependency graphs

Java ecosystems often use Maven or Gradle, where dependency mediation and version resolution can be influenced by parent POMs, BOMs, and transitive exclusions. That gives teams more control, but also more complexity. A dependency can be present because it was inherited from a parent build file rather than declared in the module itself. If you do not inspect the resolved graph, you may miss a package that is only present because of a plugin or framework default.

For technical practitioners, commands such as mvn dependency:tree or Gradle dependency reports are useful starting points. The goal is not just to list packages, but to understand which ones are direct, which are inherited, and which are only needed for tests or build tasks.

Other package managers and container images

Python, Ruby, Go, Rust, .NET, and container ecosystems each have their own patterns, but the same principles apply. Container images are a particularly important case because they bundle operating system packages as well as application-level dependencies. A slim application image can still contain vulnerable system libraries if the base image is not controlled. That is why image scanning and package inventory should cover both application manifests and base layers.

In containerised environments, it is also useful to distinguish between what is in the image and what is actually reachable in the running service. A package may be present but unused. That does not eliminate the risk, but it can help prioritise remediation when resources are limited.

How to assess dependency risk in practice

Good assessment starts with visibility. You cannot manage what you cannot enumerate, and you cannot prioritise what you cannot contextualise. For SMEs, the aim should be a lightweight but reliable view of the dependency estate, not a perfect catalogue that nobody maintains.

Inventorying direct and nested dependencies

Start by generating a dependency inventory for each application, service, and build pipeline. Include direct packages, transitive packages, build tools, and container base images. Capture the package name, version, source repository, licence, and whether the component is used in build, test, or production. Where possible, store this information as part of the release artefact so you can trace it back later.

SBOMs are useful here because they provide a structured inventory that can be compared over time. They are not a complete control on their own, but they make it much easier to answer questions after a vulnerability disclosure or supply chain event. If you already produce SBOMs, make sure they include nested dependencies and are generated from the resolved build output, not just the manifest file.

Identifying critical packages and trust boundaries

Not all dependencies deserve the same level of scrutiny. Focus first on packages that sit close to trust boundaries, such as authentication, parsing, deserialisation, cryptography, file handling, and network communication. Also prioritise packages that are widely used across multiple services, because a single issue there can create a broad blast radius.

It is also sensible to identify packages that are effectively part of your control plane, such as CI runners, deployment tooling, and infrastructure-as-code libraries. These may not be customer-facing, but they often have privileged access to secrets and environments.

Using SBOMs and dependency graphs to improve visibility

Dependency graphs help you see how a package entered the tree, while SBOMs help you track what is present at a point in time. Used together, they support faster triage. If a vulnerability alert appears, you can determine whether the affected package is direct, transitive, or only present in a test path. That distinction can materially change remediation priority.

For teams already working with threat modelling, dependency graphs can be treated as another data source in the model. They show where external code enters the system and where trust is extended beyond the team’s direct control. That is a useful complement to broader supply chain thinking and to the architecture work discussed in applying data-flow diagrams to security threat modelling.

Controls that reduce dependency risk

Once you can see the dependency landscape, the next step is to reduce unnecessary movement and limit where trust is placed. The most effective controls are usually simple, repeatable, and enforced in the pipeline rather than left to individual judgement.

Pinning versions and managing update policy

Version pinning reduces surprise. Where practical, lock direct dependencies to known versions and use lockfiles or equivalent mechanisms to control resolved transitive versions. That does not mean never updating. It means updates happen on your terms, with testing and review, rather than as a side effect of a routine install.

A sensible update policy separates routine patching from major upgrades. Routine updates can be batched and tested on a schedule. Major upgrades should be explicitly reviewed because they may change transitive trees, remove deprecated code, or introduce new package families. For critical services, consider maintaining a small set of approved dependency versions rather than allowing broad ranges.

Allowlisting trusted sources and repositories

Package source control is often overlooked. If your build can fetch dependencies from anywhere on the internet, you have a larger trust problem than you may realise. Restrict package resolution to approved repositories, mirror critical packages where appropriate, and block direct access to untrusted sources from build agents. This reduces exposure to typosquatting, dependency confusion, and transient registry compromise.

For organisations with stronger governance requirements, repository proxying can also improve auditability. It gives you a record of what was downloaded, when, and from where. That evidence can be useful during incident review and supplier assurance discussions.

Reviewing licence, maintenance, and release health signals

Security is only one dimension of dependency risk. Maintenance health matters too. A package that has not been updated in years, has few maintainers, or shows erratic release behaviour may be more fragile than a package with a smaller vulnerability count but stronger stewardship. Review signals such as release cadence, issue response time, maintainer continuity, and whether security advisories are published in a timely way.

Licence review is also relevant because it affects whether a package can be used in the intended product or distribution model. While this article is not legal advice, it is sensible to ensure that licence checks are part of your procurement and release review process.

Detecting vulnerable or malicious transitive dependencies

Visibility and control need to be backed by detection. Software composition analysis, or SCA, tools can scan manifests, lockfiles, and resolved artefacts for known vulnerabilities and policy violations. They are not perfect, but they are a practical baseline for most SMEs.

Using SCA tools in CI pipelines

Run SCA checks in CI so that dependency changes are assessed before release. Scan both the manifest and the resolved dependency tree. If your tooling supports it, fail builds only on agreed severity thresholds or on packages that are explicitly blocked by policy. That avoids turning every low-value alert into a release blocker.

For example, a pipeline might run package installation in a clean environment, generate the lockfile, produce an SBOM, and then scan the SBOM for known issues. The point is to tie the scan to the exact artefact that will be deployed. Scanning source manifests alone is not enough if the build process can resolve different versions.

Alerting on known vulnerabilities and suspicious package changes

Known vulnerabilities are the easiest issue to detect, but they are not the only one. You should also alert on unexpected changes in package ownership, sudden spikes in download behaviour, new maintainers, or unusual version patterns. Those signals can indicate a compromised package or a malicious publishing event.

Where possible, combine package intelligence with your broader monitoring. If a build agent suddenly starts pulling a package from an unusual source, or a release introduces a package that has not been seen before, that should be visible to the security team or platform team.

Prioritising remediation with exploitability and exposure context

Not every vulnerable transitive dependency requires immediate action. Prioritise based on exploitability, reachability, exposure, and whether the package is present in production or only in a build path. A vulnerability in a test-only dependency is still worth tracking, but it may not need the same urgency as a remotely reachable runtime component.

Context also matters for compensating controls. If a vulnerable package is behind a feature flag, isolated from the internet, or only used in a non-production environment, the remediation plan may differ. The aim is to reduce noise without ignoring real risk.

How to handle transitive dependencies without breaking delivery

Teams often delay dependency work because they fear regressions. That is understandable, but unmanaged dependency drift usually creates more disruption later. The answer is to treat dependency changes as controlled change, not as ad hoc maintenance.

When to upgrade the parent package

In most cases, the cleanest fix is to upgrade the parent package that introduced the transitive dependency. That keeps the dependency tree coherent and reduces the chance of conflicts. It is also easier to explain in change records and release notes. If the parent package is actively maintained, this should be the default path.

Before upgrading, check whether the new version changes the resolved tree in a way that affects authentication, serialisation, logging, or network behaviour. Even a minor version bump can have a wider impact than expected if the package author has changed internal dependencies.

When to override or exclude a nested package

Sometimes you cannot wait for the parent package to be fixed. In those cases, dependency overrides or exclusions can be a pragmatic short-term measure. Use them carefully. They can resolve a vulnerability quickly, but they may also create compatibility problems if the parent package expects a specific version.

If you override a nested package, document the reason, the expected expiry date, and the test evidence. Treat it as a temporary risk acceptance, not a permanent architecture choice. This is where clear ownership matters, because someone needs to know when the override should be revisited.

Testing for regression after dependency changes

Dependency changes should trigger targeted regression testing. Focus on authentication flows, error handling, file uploads, API clients, and any code paths that rely on serialisation or parsing. If the package affects build output, test the artefact itself as well as the application behaviour.

For higher-risk services, add security regression tests that verify the specific control you relied on. For example, if a package update changes how input is parsed, confirm that validation and sanitisation still behave as expected. This is a practical extension of the secure coding principles discussed in input validation, encoding, and output sanitisation techniques.

Governance patterns for SMEs and product teams

Technical controls work best when they are backed by simple governance. SMEs do not need a heavy process, but they do need clarity on who owns decisions and what minimum standards apply.

Defining ownership for dependency decisions

Assign ownership for dependency risk at the product or service level. In practice, that usually means the engineering lead owns the technical decision, while security or platform teams define the policy and review exceptions. If nobody owns the dependency tree, then nobody owns the remediation backlog either.

Ownership should include responsibility for reviewing alerts, approving overrides, and ensuring that dependency inventories remain current. It should also include escalation paths for high-risk packages that affect multiple services.

Setting minimum controls for third-party code

At a minimum, establish controls for source trust, version control, vulnerability scanning, and release evidence. For example: only approved registries may be used, lockfiles must be committed, SCA scans must run in CI, and release artefacts must include an SBOM or equivalent inventory. Those requirements are modest, but they create a baseline that is much easier to defend than informal developer judgement.

Where teams are mature enough, align the control set with secure development practices and supplier assurance. That helps connect dependency management to broader governance rather than treating it as a separate engineering concern.

Linking dependency risk to secure development and supplier assurance

Dependency risk is part of secure development, not an isolated hygiene task. It should sit alongside code review, secret management, build integrity, and release approval. It also overlaps with supplier assurance because package maintainers and registry operators are effectively part of your supply chain, even if they are not direct commercial suppliers.

If you are already working through secure development controls, it is worth aligning dependency policy with the same operating model used for other third-party risk. That keeps expectations consistent and reduces the chance of gaps between procurement, engineering, and security.

A practical dependency risk checklist

The following checklist is a useful starting point for UK SMEs that want a manageable control baseline.

Build-time checks

Confirm that package sources are restricted to approved repositories. Enforce lockfiles or equivalent resolution controls. Generate an SBOM from the resolved build output. Scan for known vulnerabilities and policy violations before artefacts are signed or deployed.

Release-time checks

Review any dependency changes that introduce new top-level packages, major version changes, or new sources of trust. Require targeted regression testing for sensitive code paths. Record exceptions with an owner and review date.

Operational monitoring checks

Monitor for new advisories affecting packages in production. Track dependency drift between environments. Review package health signals periodically, including maintenance activity and release patterns. Reassess high-risk packages after significant product or threat changes.

Frequently asked questions about transitive dependencies

How do you eliminate transitive dependencies?

In most real-world applications, you do not eliminate them entirely. You reduce and control them. That means choosing simpler dependency trees, pinning versions, excluding unnecessary packages, and preferring well-maintained libraries with fewer nested layers. In some cases, you can replace a framework-heavy dependency with a smaller component to reduce the tree depth.

What do transitive dependencies mean in risk management?

In risk management terms, transitive dependencies are indirect third-party exposures that can affect your software even though your team did not choose them explicitly. They matter because they expand the trust boundary, increase the number of components that need monitoring, and can introduce vulnerabilities or operational issues outside your immediate control.

For most SMEs, the practical answer is not to avoid dependencies altogether. It is to make them visible, control where they come from, and ensure that the team can respond quickly when something changes. If you want help turning that into a workable policy, speak to a consultant.