Who is accountable for vulnerable dependencies when a team ships code without centralised visibility?

Why This Matters for Security Teams

When teams ship code without centralised visibility into dependencies, accountability becomes fragmented very quickly. Engineering may own the release, AppSec may own policy review, and platform teams may own pipelines, but none of those functions can credibly manage risk if they cannot see the full software bill of materials, approval path, or exception history. That gap affects not only security posture but also licensing, supply chain assurance, and audit evidence.

This is why control frameworks increasingly treat software supply chain governance as an organisational responsibility, not an individual developer problem. NIST SP 800-53 Rev 5 Security and Privacy Controls makes that expectation clear in controls tied to configuration management, system integrity, and risk response. The practical issue is simple: if dependency data lives in scattered build logs, local package manifests, and ad hoc tickets, no single team can attest to what was shipped or why a risky library remained in release.

In practice, many security teams only discover dependency risk after a vulnerable package has already been promoted into production or after an audit request exposes missing ownership.

How It Works in Practice

Accountability for vulnerable dependencies works best when the organisation assigns one accountable owner for policy, one for enforcement, and one for remediation execution. That does not mean centralising every decision in a security team. It means defining who can approve dependency use, who can block releases, and who must remediate when a known vulnerability or license issue appears. The strongest programmes connect dependency data from build systems, artifact repositories, and vulnerability scanners into a shared inventory so teams can answer three questions quickly: what is included, where is it deployed, and who accepted the risk.

Operationally, this usually requires a mix of preventive and detective controls. The preventive side includes approved package sources, version pinning, dependency review gates, and policy checks in CI/CD. The detective side includes continuous scanning, exception tracking, and escalation paths for high-severity findings. For software supply chain integrity, guidance from NIST Secure Software Development Framework and OWASP Software Supply Chain Security Top 10 is especially relevant because both emphasise traceability, provenance, and secure release practices.

• Define a single accountable owner for dependency policy, even if multiple teams implement controls.
• Maintain a software bill of materials so the organisation can identify affected components quickly.
• Gate releases on policy checks for critical vulnerabilities, prohibited licenses, and unapproved sources.
• Record exception approvals with expiry dates, business justification, and remediation commitments.
• Feed findings into ticketing and risk registers so unresolved dependency issues remain visible.

Where this becomes more complex is in fast-moving environments with ephemeral builds, multiple repositories, or autonomous build agents, because dependency provenance can change between scan and release faster than manual review can keep up.

Common Variations and Edge Cases

Tighter dependency governance often increases build friction and review overhead, requiring organisations to balance release speed against assurance. That tradeoff is real, especially for product teams that depend on rapid iteration or open source ecosystems with frequent updates. Best practice is evolving, but current guidance suggests that the answer is not to remove gates; it is to make them risk-based so low-risk updates move quickly while high-risk changes receive deeper scrutiny.

There are also edge cases where accountability is shared rather than singular. In monorepos, one platform team may own the scanning pipeline while feature teams own library choices. In outsourced development, the supplier may do the implementation, but the buying organisation still retains accountability for governance and acceptance of shipped risk. For regulated environments, CISA guidance on SBOMs and ISO/IEC 27001 style governance expectations are useful reference points, even where local controls differ.

The main gotcha is that “centralised visibility” does not automatically mean “centralised control.” Teams still need named owners, decision rights, and documented exceptions. Without that, dependency accountability often becomes a retrospective blame exercise rather than a repeatable control process.

Related resources from NHI Mgmt Group

• Who is accountable when a company ships vulnerable first-party code that attackers exploit before disclosure?
• Who is accountable when a vulnerable embedded component ships in production?
• How can organisations reduce risk from vulnerable dependencies without slowing delivery?
• What breaks when organisations try to patch vulnerable dependencies without version-specific remediation?