What breaks when organisations rely only on vulnerability scanning for open source dependencies?

Vulnerability scanning can miss packages that are harmful by design, even when the dependency tree looks clean. That leaves teams exposed to install-time payloads, credential theft, and transitive compromise that never maps to a CVE. The control gap is especially dangerous in CI/CD, where a malicious package can act before any application code runs.

Why This Matters for Security Teams

Relying on vulnerability scanning alone creates a false sense of coverage. Scanners are good at finding known defects tied to disclosed CVEs, but open source supply chain risk often appears before a CVE exists, or without one at all. That means a package can be intentionally malicious, recently hijacked, or inserted through a compromised maintainer account and still appear “clean” to traditional tooling. Current guidance from sources such as CISA cyber threat advisories emphasizes that threats increasingly target trust in dependencies, not just code bugs.

The practical risk is not limited to application runtime. Build systems, dependency resolvers, and package registries can execute code or fetch assets during install, so a harmful dependency can exfiltrate secrets, alter build outputs, or plant persistence before any security gate that looks for known vulnerabilities has a chance to fire. Teams also underestimate how quickly transitive dependencies expand the blast radius, especially in fast-moving CI/CD pipelines. In practice, many security teams encounter the compromise only after secrets have already been exposed or release artifacts have already been published, rather than through intentional dependency governance.

How It Works in Practice

A mature dependency security program treats vulnerability scanning as one control layer, not the control itself. Scanning still matters for known flaws, but it must be paired with provenance checks, allowlists, integrity validation, and continuous monitoring of package behaviour. This is consistent with the direction of the CIS Controls v8, which emphasise software inventory, secure configuration, and monitoring as linked operational controls rather than isolated tasks.

In practice, teams should distinguish between four questions: is the package known vulnerable, is it trusted, is it expected, and is it behaving as expected. A dependency can answer “yes” to the first question and still be dangerous if it is typosquatted, newly compromised, or designed to run install-time scripts. That is why software bills of materials, signature verification, and source provenance checks are becoming more important alongside scanners. Security teams also need CI/CD rules that detect suspicious install behaviour, network calls, secret access, and unexpected changes to lockfiles or package manifests.

• Use vulnerability scanners to catch disclosed issues, but do not treat a clean result as a trust decision.
• Require provenance and integrity checks for critical dependencies and release artifacts.
• Restrict install-time script execution where possible, especially in automated builds.
• Monitor for secret exposure, unusual network access, and unexpected transitive dependency changes.
• Review dependency updates as a supply chain event, not just a patching task.

Threat reporting from the ENISA Threat Landscape reinforces that supply chain attacks often exploit trust relationships and automation paths, not only vulnerable code. These controls tend to break down when build pipelines are fully automated, package sources are broad and unpinned, and security teams have no telemetry on install-time execution because the environment treats dependency fetches as routine developer activity.

Common Variations and Edge Cases

Tighter dependency controls often increase build friction and review overhead, requiring organisations to balance delivery speed against supply chain assurance. That tradeoff is real, especially in polyglot environments with hundreds of packages, but current guidance suggests the cost of selective control is lower than the cost of blind trust.

There is no universal standard for this yet, so teams should adapt by risk tier. For low-risk internal tools, vulnerability scanning plus basic allowlisting may be enough. For internet-facing applications, production build systems, and anything that can access secrets or deploy code, best practice is evolving toward stronger provenance enforcement, restricted package sources, and behaviour monitoring. This is also where the identity angle becomes relevant: CI/CD identities, build tokens, and package publishing credentials become high-value targets, so dependency governance and non-human identity governance increasingly overlap.

Edge cases matter. Some dependencies are safe in source form but risky once build hooks, optional scripts, or native extensions are enabled. Some ecosystems publish packages faster than scanners can update advisories, which leaves a gap between introduction and detection. Teams that depend on transitive packages from multiple registries face a further challenge because a single compromised upstream can cascade into many applications at once. The right response is not to abandon open source, but to control trust explicitly rather than infer it from the absence of a vulnerability finding.

Related resources from NHI Mgmt Group

• What breaks when organisations rely only on vulnerability scanning in SSCS?
• What breaks when organisations rely on audit trails as their only source of truth?
• What breaks when organisations rely on detection but leave lateral movement paths open?
• What breaks when organisations still rely on severity-only vulnerability management?