Software Dependency

What software dependencies are and why they matter

A software dependency is more than a convenience for developers. It is an external component that becomes part of the application’s trusted execution path, so weaknesses in that package, its maintainers, or its update channel can become weaknesses in the application itself. That is why dependency inventory, provenance and review are core to release governance.

Dependencies can be first-party or third-party, direct or transitive, but the security problem is the same: you inherit code you did not write and often do not fully control. The practical question is not only whether the dependency works, but whether it is known, current, necessary and safe to keep in the build.

How dependencies become a security concern

Dependencies widen the attack surface because they can bring in vulnerable functions, risky defaults, abandoned code or malicious updates. A single package may also pull in many transitive libraries, which makes hidden exposure harder to spot unless the organisation maintains an accurate software bill of materials and tracks change over time.

Dependency risk is not limited to code defects. Licensing conflicts can create legal and procurement problems, while maintenance risk appears when a package is no longer supported, has poor release hygiene, or changes behavior in ways that break security assumptions. In practice, release governance should treat dependency approval as a control point, not an afterthought.

How teams assess exposure and control change

To understand exposure, teams usually start with asset and dependency inventory: what is used, where it is deployed, and whether it is internet-facing, embedded in a high-value service, or bundled into multiple products. Vendor advisories, package registries and internal build records are then used to confirm whether a dependency is still trusted and whether a replacement or update is required.

For widely used open source packages, ecosystem guidance matters because the primary risk often sits in the supply chain around the package rather than in one application alone. Resources such as OpenSSF help teams understand supply-chain security practices, while build-provenance work such as SLSA helps validate how the artifact reached production.

Governance, remediation and verification

Good dependency governance balances speed and control. Organisations should know which dependencies are approved, which are pinned or versioned, which are transitive, and which are allowed only under exception. When a dependency is replaced, removed or updated, the change needs to flow through testing, release review and rollback planning so that security fixes do not create new outages.

When remediation is not immediately possible, compensating controls may include isolating the affected component, limiting where it runs, reducing its privileges, or placing stronger review around the code path that consumes it. Security engineering guidance such as NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it ties configuration management, system integrity and monitoring to the release process.

Risk and Threat Considerations

Software dependencies are a common entry point for supply-chain compromise because attackers can target the package itself, the maintainer account, the distribution channel or the update mechanism. The result can be credential theft, code execution, tampering or a quietly introduced backdoor that looks like a normal update.

Failure mechanism: A dependency becomes trusted inside the build or runtime path, then an adversary abuses that trust through a malicious release, compromised maintainer, or vulnerable transitive component.

Impact: The application may inherit the compromise at scale, affecting many downstream systems at once and forcing emergency rotation, rollback, rebuild or incident response across multiple teams.

Practitioner Guidance

Why practitioners should care: Treat dependency management as part of security architecture, not just developer convenience. The most damaging failures usually come from dependencies that are invisible, unowned or updated without clear provenance.

Common misunderstanding: A dependency is not automatically safe because it is popular, open source, or already present in production. What matters is whether it is still maintained, how it is consumed, and whether your pipeline can prove what was built from it.

Practitioner takeaway: Keep dependency inventory, provenance checks and exception handling tied to release approval so that security decisions happen before the package is promoted, not after an incident.

Related resources from NHI Mgmt Group

• Why do deep dependency trees make software supply chain triage harder?
• Why does dependency depth matter in software supply chain governance?
• Why do software dependency attacks still succeed when teams scan for CVEs?
• How should security teams implement dependency graphing to manage indirect software supply chain risk?