Vulnerability Blocking at Install
Block packages with known CVEs at install time. CVSS and EPSS thresholds apply per team, and new advisories take effect immediately without any manual update.
CVEs reach developer machines before anyone reviews them
A new advisory is published. The affected package is already installed by the time a security team sees it. Blocking after the fact means chasing an install that already happened.
No gate between advisories and package installs
Package managers resolve the latest matching version without checking vulnerability status.
Different teams applying different thresholds manually
Without a central policy layer, blocking decisions vary across projects and pipelines.
Exception handling scattered across tickets and chat
Approved exceptions are not linked to the builds where they were used.
What your team gets
CVE blocking at the registry
Packages with known CVEs matching your CVSS or EPSS threshold are blocked before npm install or pip install completes.
Per-team severity thresholds
Create separate firewalls per team or environment. Stricter rules for production builds, different thresholds for development.
New advisories take effect immediately
When a CVE is published, the firewall starts blocking matching versions without any manual rule update.
Time-limited exceptions with audit records
Developers request exceptions inline. Each has a scope, owner, and expiration in the audit log.
How Dependency Firewall handles this
Dependency Firewall blocks packages with known CVEs at the registry, covering every install across all teams and pipelines.
- CVE blocking with CVSS and EPSS filters
- Per-team firewall configurations
- Time-limited exceptions logged for audit
Built for the teams involved
- Security teams
Set CVSS and EPSS thresholds once. Every install across all teams and pipelines enforces the same rules.
- Developers and DevOps
Package managers route through the firewall transparently. Blocked packages fail with a clear message.
What changes in practice
Fewer vulnerable packages reaching developer environments
Blocking happens at install, before a vulnerable version lands in a build or gets committed to a lockfile.
Consistent policy across teams without manual coordination
Rules live in the firewall. Every team's installs enforce the same thresholds.
Questions about this use case
Can we set different thresholds per team?
Yes. Create separate firewalls per project or team, each with its own rules.
What happens when a new CVE is published for a package we already use?
The firewall starts blocking that version immediately. Packages already installed are unaffected until the next install attempt.
Does this work with our existing repository?
Yes. Dependency Firewall proxies any registry, including JFrog Artifactory, Sonatype Nexus, GitLab, Azure Artifacts, and GitHub Packages.
Talk to us about vulnerability blocking at install.
We can walk through the product fit for your environment and where each Observer product fits.