What do organisations get wrong about dependency scanning and lockfiles?

Why This Matters for Security Teams

Dependency scanning and lockfiles are useful guardrails, but they are often mistaken for malware prevention and release verification. Scanners tell teams what is already present, while lockfiles preserve a chosen dependency graph; neither one proves that a newly published package is trustworthy at first use. That gap matters most when a maintainer account is hijacked, a legitimate package is replaced with a malicious update, or a transitive dependency pulls in risky code before review.

For practitioners, the real issue is release trust. Controls need to answer whether the pipeline can hold back, inspect, and isolate first-seen versions before they execute, not just whether a file is pinned. This is why supply chain guidance increasingly pairs dependency hygiene with provenance checks, policy enforcement, and staged promotion, as reflected in the NIST Cybersecurity Framework 2.0 and NHIMG research on the LiteLLM PyPI package breach.

NHI Mgmt Group data also shows why this is operationally messy: Ultimate Guide to NHIs reports that 96% of organisations store secrets outside of secrets managers in vulnerable locations, which turns dependency compromise into a wider identity and secrets exposure problem. In practice, many security teams encounter malicious package execution only after the CI pipeline has already trusted the release and leaked credentials downstream.

How It Works in Practice

The practical objective is to separate version control from trust decisions. Dependency scanning checks for known vulnerabilities, while lockfiles pin exact versions to improve reproducibility. Those are necessary, but they do not stop a safe-looking package from becoming unsafe after a maintainer compromise. Teams need an additional control plane that evaluates what is being introduced at runtime and whether it should be allowed into build, test, or production environments.

A stronger pattern usually includes:

• Policy gates that require approval for first-seen packages, new maintainers, or unexpected transitive changes.
• Provenance verification using signed artifacts, attestations, and repository trust rules before installation.
• Ephemeral build environments that prevent secrets from persisting if a package behaves maliciously.
• Network and file-system isolation during install steps so suspicious code cannot reach tokens or internal services.
• Continuous re-evaluation of dependencies after lockfile generation, because a pinned graph is only as safe as the package sources behind it.

This is consistent with the broader direction of the NIST Cybersecurity Framework 2.0, which emphasizes governed, repeatable security outcomes rather than single-point technical checks. It also aligns with NHIMG’s observation in the Ultimate Guide to NHIs that most organisations still expose secrets in places where compromised build-time dependencies can reach them.

The best operational model is to treat dependency intake as a trust workflow, not a simple allow or block list. Teams that only scan and pin often miss the moment where a package is technically approved by version, but operationally untrusted because its provenance, maintainer state, or release timing changed. These controls tend to break down in CI pipelines that auto-install dependencies with broad token access because the install step becomes the easiest path to credential theft.

Common Variations and Edge Cases

Tighter dependency controls often increase build friction, requiring organisations to balance release speed against the risk of introducing unvetted code. That tradeoff becomes sharper in polyglot repositories, monorepos, and internal package mirrors, where a single lockfile may not capture every path by which code enters a system.

There is no universal standard for this yet, but current guidance suggests a layered approach. For public packages, that means trust-on-first-use should be delayed, not automatic. For internal packages, that means signed publishing, maintainer separation, and promotion between repositories should be treated as control points. For highly sensitive pipelines, isolation matters as much as scanning because malicious install scripts can still access the environment even when the dependency version is pinned.

Edge cases also include vendored code, generated dependencies, and packages pulled in by build tools rather than application manifests. Those paths are commonly missed because they sit outside the main lockfile workflow. Security teams should also watch for emergency hotfixes and typosquatting, where a seemingly minor package change bypasses normal review because it looks like routine maintenance.

The practical takeaway is that lockfiles preserve intent, but they do not validate trust. Organisations that assume otherwise usually discover the weakness after a compromised maintainer, poisoned release, or credential-stealing install script has already run.

Related resources from NHI Mgmt Group

• What do organisations get wrong about incident automation in IT service desks?
• What do organisations get wrong about user access management audits?
• What do organisations get wrong about ticketless access requests?
• What do organisations get wrong about PAM governance?