Who is accountable when dependency updates stay unreviewed and a supply chain incident lands?

Why This Matters for Security Teams

Unreviewed dependency updates are not just an engineering backlog item. They are a governance failure that leaves software release paths exposed to malicious packages, compromised maintainer accounts, and trusted build pipeline abuse. When update review stalls, ownership becomes blurry: engineering assumes security is watching, security assumes release management is enforcing discipline, and neither side can prove which versions are actually approved. That gap is exactly where supply chain incident land.

NHIMG research on real-world dependency compromise shows how quickly trust can be inverted. The Mastra npm Supply Chain Attack — Sapphire Sleet and the Reviewdog GitHub Action supply chain attack both illustrate how quickly a trusted update path can become an attacker’s delivery mechanism. Guidance from the OWASP Non-Human Identity Top 10 also reinforces that machine-driven release and build activity needs explicit control ownership, not informal trust. In practice, many security teams encounter exposed versions only after the malicious package has already been pulled into the build, rather than through intentional review.

How It Works in Practice

Accountability should be assigned to the function that owns release governance, with security and engineering sharing enforcement duties. That means someone is responsible for deciding whether a dependency update is low risk, whether it needs deeper review, and whether it can proceed automatically. Current best practice is moving toward policy-as-code for this decision point, so update approval is evaluated at runtime instead of waiting on ad hoc human triage. NIST control thinking around change oversight and access governance supports this approach, especially when software supply chains are treated as high-impact operational assets.

In practical terms, teams should separate three layers:

• Detection, so outdated or risky packages are identified quickly.
• Review, so meaningful changes are checked against approved policy.
• Acceptance, so the business owner explicitly signs off when a dependency carries known risk.

That ownership model matters because supply chain incidents often spread through CI/CD, package registries, and automation accounts, not through a single developer workstation. NHIMG’s The State of Secrets Sprawl 2026 shows how often compromise happens in trusted automation paths, and the same pattern applies to dependency updates. Where release gates are weak, attackers exploit the gap between “available update” and “approved update.” The right response is a change-control workflow with explicit approvers, time-bound exception handling, and revocation of stale package trust. The NIST SP 800-53 Rev 5 Security and Privacy Controls provide a useful reference point for formalising review, approval, and monitoring expectations. These controls tend to break down when package updates are auto-merged into production without a named risk owner because no one is accountable for the resulting exposure window.

Common Variations and Edge Cases

Tighter dependency control often increases release friction, requiring organisations to balance speed against assurance. That tradeoff is real, especially in high-velocity environments where patch latency can itself become a risk. There is no universal standard for how much review every dependency needs, so current guidance suggests a tiered model: low-risk routine updates can be pre-authorised, while major version jumps, new maintainers, or packages touching build-time code should trigger manual review.

Exceptions also matter. In regulated environments, a stalled review queue may force formal risk acceptance rather than silent delay. In small teams, the same person may own both release engineering and security sign-off, but the accountability still needs to be explicit and auditable. For broader threat context, the 52 NHI Breaches Analysis shows how often trust failures become identity and access failures once an attacker reaches automation. The LiteLLM PyPI package breach is another reminder that dependency incidents often become credential incidents. The practical rule is simple: if an update can affect build trust, signing keys, or secrets exposure, it should not wait in an unnamed queue. In real incidents, unreviewed updates usually become a leadership problem only after the blast radius is visible across multiple teams.

Related resources from NHI Mgmt Group

• Who is accountable for CRA compliance across the product supply chain?
• Who should stay accountable when AI drafts incident summaries and escalation messages?
• Who is accountable when a release ships with incomplete software supply chain evidence?
• Who is accountable when a tampered Git remote causes a software supply chain incident?