Should organisations prioritise dependency approval controls over more package scanning?

Yes, when the problem is already visibility rather than discovery. Scanning tells you what exists, but approval controls, install-policy restrictions, and manifest-level remediation determine whether untrusted or vulnerable code can actually enter and persist in the build path.

Why approval controls outperform scanning when visibility is already good

Package scanning is useful for finding known issues, but it does not by itself stop a risky dependency from entering the build. Approval controls change the decision boundary: they determine whether a package can be introduced, from which source, and under what policy. When organisations already have sufficient inventory and alerting, tightening the admission path usually removes more risk than adding another scan.

That distinction matters because many build pipelines already know what is present. The bigger failure is often that teams can see the dependency, yet still allow it through because policy is weak, exceptions are informal, or the manifest is never remediated. In practice, approval controls are a governance and enforcement mechanism, while scanning is primarily a discovery and triage mechanism.

For supply chain security context, the LiteLLM PyPI package breach shows why admission control matters when a package itself becomes the attack vector. If the build path does not constrain what can be installed, the organisation is relying on detection after exposure rather than prevention before execution.

What approval controls actually change in the delivery pipeline

Approval controls operate at the point where software is selected, pinned, merged, built, or promoted. That gives them leverage over provenance, version choice, and policy exceptions, which is where many dependency risks are introduced. Scanning can tell you a package is outdated, but approval can prevent that package from being introduced in the first place, or require a documented exception before it is used.

This is why manifest-level remediation is so important. If the dependency declaration is not corrected, the same vulnerable package keeps returning on every rebuild. A strong control set therefore combines allowlists or review gates with enforced dependency updates, source restrictions, and expiry on exceptions. That makes the control durable instead of purely advisory.

The most useful way to think about it is through lifecycle governance. NHI lifecycle management guidance is relevant here because the same governance pattern applies to software dependencies, keep visibility, enforce ownership, and make the approval or retirement decision explicit rather than implicit.

How to decide where to invest first

When visibility is already strong, prioritise approval controls if the main gap is uncontrolled introduction, weak exception handling, or repeated reappearance of the same vulnerable package. Prioritise more scanning when you still lack reliable discovery, your inventory is incomplete, or you cannot tell where dependencies are used. In other words, scanning answers “what exists?”, while approval controls answer “what is allowed to enter and remain?”

That is why supply chain programmes should not treat package scanning and approval policy as substitutes. Scanning is still needed for continuous assurance, but it becomes much more valuable when paired with a rule that turns findings into enforceable build-time decisions. Without that second step, teams often end up with more findings and the same exposure.

For broader supply chain practice, OpenSSF is a useful reference point because its ecosystem work reinforces the need for secure dependency selection, provenance awareness, and repeatable controls around open source consumption.

Risk and Threat Considerations

Weak dependency admission creates a direct pathway for malicious or vulnerable code to persist in the software build path, even when scanners have already identified the package. The risk is not just detection failure, but control failure: if approvals are informal or exceptions never expire, untrusted code can keep re-entering the pipeline through the same manifest.

Failure mechanism: The organisation treats scanning output as the control, rather than as input to an enforcement decision. That leaves the build path open to dependency substitution, repeated reintroduction of the same package, and avoidable exposure from versions that should have been blocked or remediated.

Impact: Attackers and supply chain failures gain a durable route into builds and releases, while defenders inherit recurring remediation work, inconsistent policy enforcement, and a larger blast radius when a dependency is compromised.

Practitioner Guidance

What to prioritise: If your scanners already provide good coverage, focus first on the controls that decide whether a dependency may enter the build, because that is where admission risk is reduced.

What to verify: Check that approval rules, source restrictions, and exception expiry are enforced automatically, not just documented. If a risky dependency can still be merged through a manual path, the control is only partial.

What good looks like: A team can show that every accepted dependency has an owner, an approval basis, and a remediation path, and that vulnerable packages are blocked or replaced before they become a repeated build input.

Practitioner takeaway: Use scanning to inform the decision, but use approval controls to enforce it, because visibility without admission control usually leaves the same dependency risk in place.

Related resources from NHI Mgmt Group

• When should organisations prioritise transitive dependency review over top-level package updates?
• Should organisations prioritise package control over post-install scanning?
• When should organisations prioritise runtime script governance over dependency scanning?
• Should organisations prioritise reducing secret reuse over faster scanning?