Why do software dependency attacks still succeed when teams scan for CVEs?

CVE scanning only finds publicly disclosed weaknesses, but many supply chain attacks use malicious packages, typosquatting, or compromised updates that do not have a CVE. Teams need behavioural detection, provenance checks, and pipeline controls to catch threats that never appear in vulnerability feeds.

Why This Matters for Security Teams

Dependency attacks succeed because the control teams rely on is often aimed at known weaknesses, while attackers increasingly target the software supply chain itself. A package can be malicious from first publish, a maintainer account can be compromised, or an update can be tampered with without ever mapping to a CVE. That means traditional scan results can look clean even when the build pipeline is unsafe.

For security leaders, the real issue is coverage. CVE-centric programs answer only one question: whether a component is publicly known to be vulnerable. They do not answer whether the component is trustworthy, whether the maintainer is still controlled by the rightful owner, or whether the dependency graph contains a poisoned transitive package. Current guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls and threat intelligence mapped through the MITRE ATT&CK Enterprise Matrix both point toward broader control coverage than vulnerability scanning alone.

In practice, many security teams encounter dependency compromise only after a build artifact has already been trusted, signed, or deployed, rather than through intentional detection at ingestion.

How It Works in Practice

Effective dependency security starts by treating package intake as a trust decision, not just a version check. Teams need controls that inspect provenance, publisher identity, package naming patterns, update behaviour, and the integrity of the build pipeline. CVE scanning still matters, but it should sit alongside software bill of materials review, signature verification, allowlisting, and anomaly detection on dependency changes.

A practical program usually combines several layers:

• Provenance checks to confirm where a package came from and whether the release was produced by an approved maintainer or build system.
• Integrity controls to verify hashes, signatures, and repository metadata before the package reaches CI/CD.
• Behavioural review of dependency install scripts, post-install actions, and unexpected network calls during build or runtime.
• Pipeline guardrails that block unapproved sources, freeze critical dependencies, and require review for high-risk changes.

This is where a broader threat model matters. Supply chain attackers often borrow techniques seen in other intrusion sets, including credential abuse, persistence, and lateral movement after initial access, which is why operational teams should correlate package events with the MITRE ATT&CK Enterprise Matrix and current CISA cyber threat advisories. In emerging cases involving automated abuse, the intersection with agentic tooling is becoming more relevant, and the threat picture is expanding beyond classic package tampering. These controls tend to break down when teams allow direct internet access from build jobs and trust unsigned dependencies because the pipeline cannot distinguish a legitimate update from a malicious one.

Common Variations and Edge Cases

Tighter dependency controls often increase build friction and release latency, requiring organisations to balance delivery speed against supply chain assurance. That tradeoff is real, especially for fast-moving product teams that depend on many third-party libraries.

Best practice is evolving for several edge cases. Internal packages are not automatically safe, because a compromised developer account or CI secret can turn a private registry into a delivery vector. Open-source packages are not automatically risky either, because trust depends on maintainer hygiene, release provenance, and whether the package is actually used in a sensitive execution path. In some environments, especially language ecosystems with weak signing adoption, there is no universal standard for full provenance enforcement yet, so teams may need to layer compensating controls rather than wait for perfect ecosystem support.

For AI-enabled development pipelines, the risk profile is broader still. An AI coding assistant or build agent can introduce vulnerable or untrusted dependencies at machine speed, which makes policy enforcement and output validation more important than ever. That concern aligns with the direction of MITRE ATLAS adversarial AI threat matrix and the operational lessons highlighted in Anthropic – first AI-orchestrated cyber espionage campaign report, where automation and trust failures can amplify supply chain abuse.

Related resources from NHI Mgmt Group

• Why do social engineering attacks still succeed against identity support teams?
• Why do man-in-the-middle attacks still succeed when HTTPS is enabled?
• Why do AI-driven phishing attacks still succeed when organisations use modern authentication?
• Why do phishing attacks still succeed even when people know the warning signs?