Dependency Scanning Won't Save You

The Conventional Wisdom

Your security team runs dependency scanners in CI/CD. You've configured Dependabot, Snyk, or another tool. When a pull request comes in, the scanner checks for known vulnerabilities, flags outdated packages, and blocks anything with a CVE. You've told developers: "Don't merge if the scanner complains." Problem solved, right?

This is the dominant approach for supply chain security in 2024. Automated scanning is often seen as the solution to protect against malicious dependencies.

Why This Approach is Incomplete

Dependency scanners are optimized for the wrong threat model. They excel at finding known vulnerabilities in legitimate packages but fail against malicious packages designed to evade detection.

Consider the recent campaign involving packages like rollup-packages-polyfill-core and rollup-runtime-polyfill-core. These packages mimicked the legitimate rollup-plugin-polyfill-node project. They weren't vulnerable versions of real tools—they were purpose-built credential stealers with plausible names and metadata. Four additional packages in the same campaign were also removed from npm, all using similar camouflage techniques.

Your scanner didn't flag them because there was no CVE to match against. The packages were "new." The code executed a Base64-encoded npm install command that concealed the actual payload. By the time JFrog's analysis identified the threat, these packages had already been available for download.

The fundamental issue: dependency scanning operates on a blocklist model. It knows what's bad but doesn't know what's trustworthy. In a registry with millions of packages, that's an impossible gap to close with automation alone.

The Evidence

Consider what your current tooling actually checks:

• Known vulnerabilities: Your scanner queries the National Vulnerability Database and vendor-specific databases. If a package isn't in those databases, it passes.
• License compliance: Some tools flag licenses that conflict with your policies.
• Outdated versions: You get alerts when you're running old code with available patches.

Now consider what these malicious npm packages exploited:

• Name similarity: rollup-packages-polyfill-core looks legitimate if you're scanning a package.json with 200 dependencies. The naming convention matches real polyfill packages.
• Fresh publication: No CVE exists for a package published last week. Your scanner has nothing to match.
• Obfuscated execution: The Base64-encoded install command means static analysis won't reveal the malicious behavior without decoding and executing in a sandbox.

PCI DSS v4.0.1 Requirement 6.3.2 mandates that you maintain an inventory of bespoke and custom software and third-party components. But maintaining an inventory isn't the same as validating trust. ISO 27001 Control A.8.30 addresses software development outsourcing but doesn't specify how to verify the provenance of open-source dependencies.

The compliance frameworks assume you can identify and track your components. They don't address the scenario where the component itself is the threat vector.

What to Do Instead

Build a trust verification process that complements your scanning tools:

Package Provenance Checks: Before approving a new dependency, verify the publisher's identity and history. For npm packages, check the maintainer's profile, publication history, and whether the package has an established user base. A package with 10 downloads and a maintainer account created two weeks ago should trigger manual review, regardless of what your scanner reports.

Behavioral Analysis in Staging: Deploy new dependencies to a monitored staging environment before production. Watch for unexpected network calls, file system access, or environment variable enumeration. The malicious Rollup packages specifically targeted developer secrets—behavior you'd catch if you're monitoring outbound connections from your build environment.

Dependency Approval Workflow: Require security sign-off for new dependencies, not just version updates. When a developer wants to add rollup-packages-polyfill-core, someone should ask: "Why this package instead of the 50,000-download-per-week rollup-plugin-polyfill-node?" That question alone would have caught this campaign.

Developer Training on Supply Chain Threats: Your developers need to recognize that package names are not cryptographically verified. Teach them to verify package names character-by-character when adding dependencies. A typo or slight variation isn't a convenience—it's a potential compromise. Show them real examples like this Rollup campaign where the only difference is packages-polyfill versus plugin-polyfill.

Runtime Monitoring: Implement application security monitoring that detects credential exfiltration attempts. If a build process suddenly starts making HTTPS requests to unfamiliar domains or reading SSH keys, your monitoring should alert before the damage spreads.

For NIST CSF v2.0 compliance, this aligns with the Identify and Detect functions. You're not just inventorying assets (ID.AM-2) but actively monitoring for anomalous behavior (DE.CM-4).

When the Conventional Wisdom Is Right

Dependency scanning has value—just not for the threat it's marketed to solve.

Scanners are excellent at:

• Patch Management: Knowing that you're running Log4j 2.14.1 when 2.17.1 is available is critical. Scanners automate this awareness at scale.
• Compliance Reporting: For SOC 2 Type II or PCI DSS v4.0.1 audits, scanner output demonstrates that you have a systematic process for tracking third-party components.
• Reducing Noise: Automated scanning means your security team isn't manually reviewing every dependency update. You focus on the high-risk changes.

The mistake is treating scanners as sufficient. They're necessary but not sufficient.

If your current process is "scanner passes = safe to merge," you're vulnerable to exactly the kind of attack described here. If your process is "scanner passes + provenance check + behavioral analysis = safe to merge," you're building defense in depth.

The North Korean threat actors behind this campaign understood that developers trust their tools. They exploited that trust with packages that looked legitimate enough to pass casual review. Your dependency scanner didn't catch them because it wasn't designed to. The question isn't whether to use scanners—it's what else you're doing to verify trust before you execute third-party code in your build environment.

CVE Database