There are three common ways to stop bad packages: an allowlist of approved packages, a denylist of known bad ones, and scanning new packages when they arrive. Allowlists are strongest and cost the most effort. Denylists are cheap but miss new threats. Most teams combine a denylist and scanning, with an allowlist for sensitive builds.
The three approaches
| Approach | How it works | Strength | Weakness | Effort |
|---|---|---|---|---|
| Allowlist | Only reviewed packages can be installed | Unknown packages never arrive | Developers wait for approvals | High |
| Denylist | Known malicious packages are blocked | Easy, fast | Misses anything not yet reported | Low |
| Scan on install | Each new package is checked when requested | Catches new packages | Detection is imperfect | Medium |
When each fits
Allowlist suits release builds, regulated products and any pipeline that holds production secrets. The list can start from your current lockfiles, so day one is not a disruption. The ongoing cost is the review queue, so give it an owner and a target turnaround.
Denylist suits the broad developer population as a floor. It stops packages that registries or advisory databases have already flagged. The OpenSSF malicious packages repository is one public source of such reports, in the OSV format.
Scan on install suits the gap between them: a package that is new, not yet reported and not yet approved. Combine it with a delay on brand new versions. See dependency cooldown periods.
Where to enforce
Enforcement point matters as much as the method:
- Registry proxy. All installs pass through one place. See blocking malicious installs with a dependency firewall.
- Pull request gate. Dependency changes are checked before they merge.
- CI. Fail the build if the lockfile contains a blocked package.
Local developer checks are a convenience. A proxy and a gate are the controls, since developers can bypass local settings.
A practical rollout
- Generate an inventory of everything installed today.
- Turn on a denylist and a gate in report only mode for two weeks. Count what would be blocked.
- Fix the noisy cases, then switch to blocking.
- Introduce an allowlist for the pipelines that matter most.
- Review exceptions monthly, and expire them.
Click through it at your own pace, or open it full screen. Look at how a rule decides between blocking and allowing.
Quick check
Is an allowlist realistic for a large monorepo?
Often yes, if you seed it from existing lockfiles and automate the review of low risk additions. The cost is a queue, so measure its turnaround.
Can a denylist alone protect me?
It stops what is already known. A brand new malicious package will not be on it, so pair it with scanning and a delay on new versions.
Safeguard policies, gates and guardrails can enforce rules on dependency changes, and the platform does SBOM and dependency scanning. Try a free scan.
Sources
Last reviewed: 19 October 2026.
