Code Dependency

What code dependency means in security terms

A code dependency is more than a convenience layer. It is a trust relationship with external code that can introduce bugs, hidden behaviour, licence obligations, and the possibility that a maintainer, package registry, or upstream release is compromised. The security question is not just “does it work?”, but “what else does it bring into the application?”

That matters because dependency risk is often indirect. A package may be safe in isolation while one of its transitive dependencies is vulnerable, abandoned, or altered unexpectedly. In practice, dependency management is part software engineering and part trust management, especially where build pipelines automatically fetch packages during development or deployment.

Direct and transitive dependencies

Direct dependencies are the packages a project imports explicitly. Transitive dependencies are the packages those packages rely on, often forming a deep and changing tree. The transitive layer is where many teams lose visibility, because application owners may only review the top-level manifest while the real exposure sits several layers down.

This is why dependency inventories should distinguish what the team intentionally selected from what arrived indirectly. If a transitive package introduces a vulnerable parser, logging routine, or network client, the application inherits that risk even if the top-level code never references it directly. Visibility at both levels is essential for an accurate security posture.

Why dependency chains increase attack surface

Dependencies increase delivery speed, but every added package expands the set of code paths that can fail or be abused. They create more update channels, more maintainers, more release artefacts, and more opportunities for malicious or accidental breakage. The trust boundary moves outward from your own codebase to the broader open-source ecosystem.

That expanded surface is why supply-chain compromise is such an enduring concern. A widely used package can be abused through typosquatting, maintainer account compromise, malicious updates, or hidden functionality that only becomes visible after installation. Open source ecosystems can be resilient, but they are only as safe as the weakest trusted dependency and the controls around it. Organisations that want a stronger supply-chain baseline often turn to OpenSSF guidance and tooling.

How teams manage dependency risk

Good dependency hygiene starts with knowing what is actually in use. Teams need software bill of materials practices, dependency scanning, and review of direct plus transitive packages so that hidden exposure is not discovered only after an incident. For high-value applications, the question is not just whether a package is popular, but whether it is maintained, signed, pinned, and sourced from a controlled build process.

Dependency governance also includes deciding when to accept upstream risk versus replacing or removing a package. Some organisations tolerate well-known libraries with active maintenance and strong provenance; others restrict dependency classes that are difficult to audit or that pull in large transitive trees. This is where dependency choice becomes a security decision, not merely a developer preference.

Risk and Threat Considerations

Dependencies are a common route for supply-chain compromise because they sit inside trusted build and runtime paths. A malicious or hijacked package can run code during installation, alter application behaviour, steal tokens or secrets, or establish a foothold that survives ordinary code review if the compromise arrives through an upstream release.

Failure mechanism: Attackers abuse the trust placed in package registries, maintainers, or transitive updates, then exploit automatic retrieval and broad runtime permissions to inject or activate harmful code.

Impact: The result can be malware execution, credential theft, application compromise, silent data exposure, or widespread downstream exposure across every system that consumes the package.

Practitioner Guidance

What to watch for: Treat dependency changes as security events when they introduce new maintainers, new transitive trees, unusual download behaviour, or unreviewed version jumps. Hidden risk often appears first as a dependency graph change, not as an application alert.

Practitioner takeaway: Manage dependencies as a controlled trust boundary, not as passive code reuse, because the security of the application now depends on code you do not directly own.

Related resources from NHI Mgmt Group

• How should security teams respond when a build may have run malicious dependency code?
• What breaks when a dependency can run code during build time?
• Who is accountable when a build dependency steals source code?
• What breaks when Rust package maintainers add a single malicious dependency to otherwise clean source code?