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

Who owns the review gap before a supply chain event?

Accountability for unreviewed dependency updates is usually shared, but it is not diffuse. The teams that own release governance, dependency hygiene, and formal risk acceptance are accountable for ensuring updates are reviewed before they are promoted. If that review step is missing or routinely deferred, the organisation is not just slower to patch; it is operating with an unmanaged trust decision about what code is allowed into production.

That matters because supply chain incident often exploit the exact seam between fast delivery and weak change control. A missed review can leave vulnerable versions, malicious package versions, or stale transitive dependencies in place long enough for exposure to become operational. Security and engineering leaders need a single, auditable decision path for dependency changes, not an informal expectation that someone will “look at it later.” For a control perspective, OWASP’s Non-Human Identity guidance is relevant where package managers, automation, and build systems act with delegated access and update authority. In practice, many organisations discover the accountability gap only after an exposed dependency has already been pulled through an otherwise trusted pipeline.

How the accountability chain works when dependency updates stall

Dependency review is not just a developer task. In a mature delivery model, ownership spans the people who approve release policy, the teams that maintain package inventories, and the function that decides when exceptions are acceptable. When that chain breaks, the failure is usually procedural rather than technical: update queues grow, review criteria become inconsistent, and stale versions remain in use because nobody can prove which changes were examined and which were merely assumed safe.

The practical risk is that dependency updates are often treated as low-friction maintenance, even though each update can change both functionality and trust. That is especially true for transitive dependencies, where the organisation may not directly choose the package that introduces the compromise. The review process therefore needs to answer three questions:

• What changed in the dependency tree, including transitive additions and removals?
• Who approved the update, and under what policy or exception?
• What evidence shows the package was checked for provenance, version drift, and known exposure?

Where automation exists, it should shorten the cycle, not remove accountability. Automated dependency tooling can surface available updates, but it cannot decide whether an update is safe enough to accept without governance. That distinction is critical when the same pipeline also handles secrets, build tokens, or service credentials, because a compromised dependency process can become a path into broader software and identity trust. NIST SP 800-53 Rev. 5 is useful here because it distinguishes configuration/change discipline from access and supply-chain assurance, which are often treated as one problem even though they fail differently. The point is not to slow delivery for its own sake, but to make sure the organisation can show where review stopped and why.

Where teams fail is usually at the handoff between engineering convenience and formal approval, and that is where supply chain incidents gain time to spread.

When review delays become a governance problem, not just a backlog

Tighter dependency review often increases delivery overhead, so organisations have to balance release speed against assurance. That tradeoff becomes material when update queues are long enough that exposed versions remain in use after fix availability is already known. At that point, the issue is no longer “some updates are pending”; it is that risk acceptance has become implicit instead of explicit.

There is also an important distinction between a one-off delayed review and a pattern of deferred reviews. A single missed change may be an operational exception. Repeated delay suggests the control is not owned, not measured, or not enforced. In that situation, the organisation may be relying on developer attention as if it were a control, which is fragile when teams are under release pressure. Security and engineering leadership should treat chronic review delay as a governance signal, because it shows the system cannot reliably identify which dependencies are approved, which are stale, and which are waiting on a decision.

In supply chain cases, the accountability question often widens beyond the immediate application team. If package approval, artifact promotion, or release exceptions are centrally governed, then those owners share responsibility for the breakdown. If those decisions are delegated to product teams without common criteria, the organisation can end up with uneven review standards across repositories. For readers assessing their own process, the key judgment is whether dependency review is a documented control with traceable ownership, or just a best-effort practice that disappears under load. The latter breaks first when a malicious package or compromised maintainer account reaches the pipeline.

Practitioner Guidance

What to prioritise: Treat dependency review as a governed change-control decision, not a courtesy check. The first question is whether every repository has a named owner for update approval, exception handling, and overdue review escalation.

What to verify: Confirm that the organisation can produce evidence for three states: update detected, review completed, and exception accepted. If any of those cannot be shown quickly, accountability is already too vague to support incident response or audit.

What practitioners underestimate: The hardest failure is usually not the compromise itself but the ambiguity after it. If teams cannot tell who accepted the risk, they spend response time reconstructing ownership instead of containing exposure.

Practitioner takeaway: The accountable party is the one who can approve, defer, or accept the dependency change, but the control only works when that authority is explicit, traceable, and enforced before the update reaches production.

Related resources from NHI Mgmt Group

• Who is accountable when a tampered Git remote causes a software supply chain incident?
• Who should be accountable for confirming exposure when a supply chain incident is detected?
• How do attackers turn a supply-chain incident into wider NHI compromise?
• When should organisations rotate credentials after a supply chain incident?