The Question at Hand
Your dependency scanner flagged 47 suspicious packages last month. By the time it caught them, developers had already run npm install, pulled in transitive dependencies, and possibly executed post-install scripts. The malicious code had already touched your build environment.
This raises a fundamental question about where security controls should sit: Do you scan packages after developers download them, or do you block potentially malicious packages before they ever reach developer workstations?
The debate isn't academic. Sonatype identified 174 campaign families using repeatable tactics across package ecosystems, and only 9% relied on traditional typosquatting. The other 91% used naming variations that exploit how developers search for and select packages. Your post-download scanner might catch the obvious fakes, but it's running after the package has already entered your environment.
The Case for Post-Download Scanning
Post-download scanning fits how most teams work. Developers pull packages as needed, your CI/CD pipeline runs security checks, and you catch problems before code ships to production. This approach respects development speed while maintaining a security checkpoint.
The practical advantages are real. You don't block legitimate packages that happen to match suspicious patterns. Your team can evaluate findings in context, looking at how the package is actually used in your codebase. You can implement exceptions for internal tools or packages from trusted publishers without maintaining complex allowlists.
Post-download scanning also integrates cleanly with existing workflows. Your developers don't need to change how they search for packages or wait for approval before trying a new library. The security team reviews findings during code review or in the build pipeline, where you already have gates in place.
From a compliance perspective, this model aligns with how most frameworks think about controls. PCI DSS v4.0.1 Requirement 6.3.2 requires security testing before release, not before every package download. SOC 2 Type II controls focus on what reaches production, not what touches a developer laptop during exploration.
The Case for Pre-Download Blocking
But here's what post-download scanning doesn't prevent: malicious code executing in your build environment. Package managers run install scripts automatically. Those scripts have access to environment variables, filesystem permissions, and network connectivity. By the time your scanner flags the package, the damage may already be done.
Pre-download blocking (automated quarantine of suspicious packages before they reach developer environments) shifts the control point earlier. You evaluate packages against known attack patterns before they enter your environment. This matters because modern attacks don't wait for you to build and deploy. They target your CI/CD credentials, your internal package repositories, and your developer workstations.
The 91% of malicious packages that don't use traditional typosquatting are harder to catch post-download. They use names that look legitimate: variations on popular packages, names that match common search terms, or identifiers that exploit naming conventions in specific ecosystems. A developer searching for a solution doesn't always verify the exact package name against a canonical list.
Pre-download blocking also addresses the transitive dependency problem. When you install one package, you pull in dozens of dependencies. Your post-download scanner might catch the top-level package, but by then, you've already downloaded and potentially executed code from 30 other packages you didn't explicitly choose.
From a defense-in-depth perspective, pre-download controls add a layer that post-download scanning can't provide. You're not replacing your build-time security checks, you're preventing known-bad packages from ever reaching the point where they could execute.
Where Practitioners Actually Land
Most organizations run both controls, but they struggle with the boundary between them. You need pre-download blocking for known malicious packages and obvious attack patterns. You need post-download scanning for context-aware analysis and catching subtle issues.
The implementation challenge is configuration overhead. Pre-download blocking requires maintaining policies about which packages to quarantine, which sources to trust, and how to handle edge cases. Your developers will hit false positives, and you'll need a process for reviewing and approving packages that get blocked incorrectly.
Teams that do this well use pre-download blocking for high-confidence detections: packages matching known malicious patterns, packages from publishers with established attack histories, or packages that violate basic naming conventions. They use post-download scanning for everything else: license compliance, known vulnerabilities, and behavioral analysis.
The key is automation. Manual review of every blocked package doesn't scale. You need rules that automatically allow packages from verified publishers, automatically block packages matching attack signatures, and flag everything else for quick review.
Our Take
Pre-download blocking should be your default for known threats. If Sonatype has identified 174 campaign families with repeatable tactics, you can write rules to catch those patterns before they reach your developers. The question isn't whether to block known-bad packages, it's how quickly you can update your blocklist.
But pre-download blocking alone won't catch novel attacks or context-specific risks. You still need post-download scanning to analyze how packages behave in your specific environment, evaluate transitive dependencies, and catch vulnerabilities that aren't malicious but still matter for compliance.
The tradeoff is operational overhead versus attack surface reduction. Pre-download blocking adds friction to your development workflow. Developers will encounter blocks, you'll need a review process, and you'll occasionally block legitimate packages. But that friction is cheaper than investigating how a malicious package accessed your AWS credentials during a build.
Start with blocking packages that match known attack patterns. Expand to blocking packages from untrusted publishers. Keep your post-download scanning for everything else. The goal isn't to choose one approach, it's to layer them so that known threats never reach your environment, and unknown threats get caught before they reach production.
