Your CI pipeline just turned red: Dependabot flags a "critical" CVE in a transitive library. The team panics, someone proposes a hotfix before close of business — then you discover the accused module is never loaded in production, lives in a build tool, and the actually installed version is not the one in the bulletin. Result: an all-nighter for theoretical risk, while an exposed XSS on the public API still waits its turn.
The problem is not missing alerts. It is missing triage: treating every CVE as urgent means prioritising none.
What an alert does not tell you
A dependency scanner compares package versions against a known-vulnerability database. It does not know your architecture, your firewalls, or whether the vulnerable code is reachable from the Internet.
Three filters separate noise from real risk:
| Signal | What it indicates | Limit |
|---|---|---|
| CVSS score | Theoretical severity | Ignores local exposure |
| Reachability (Snyk, Grype…) | Call path in your code | Depends on static analysis |
| Network surface | Open port, auth, WAF | You must map this yourself |
A "9.8" CVE in a devDependency does not have the same urgency as a "6.5" on your public authentication endpoint.
Map exposure before you patch
Before opening a pull request, answer four questions in this order.
1. Where does the component run? Production, staging, CI, dev laptop — each environment has its own SLA. A flaw in a test Docker image does not justify a Friday-night emergency deploy.
2. Is it reachable from outside? A server behind a VPN, with no public port and no exposed reverse proxy, sharply reduces opportunistic exploitation odds.
3. What privileges would an attacker gain? RCE as root on an isolated pod with no sensitive data access ≠ RCE on the main PostgreSQL instance.
4. Is there active exploitation (KEV, CERT bulletins)? Catalogued actively exploited vulnerabilities jump the queue, even with a middling CVSS score.
Operational prioritisation grid
A pragmatic grid for a web team on VPS or cloud hosting:
| Level | Criteria | Target timeline |
|---|---|---|
| P0 | Active exploitation + public surface | Fix or workaround < 24 h |
| P1 | RCE/LFI on exposed service, no known exploit | < 7 days |
| P2 | Prod dependency, not directly exposed | Next release cycle |
| P3 | Dev/test, internal tooling | Monthly backlog |
Compensating controls count: block an endpoint, restrict an IP range, enable a WAF rule, or temporarily remove a low-traffic feature while you ship a clean patch.
SBOM, lockfiles and continuity
Without a reliable inventory, you do not know what actually runs. Lockfiles (package-lock.json, composer.lock, poetry.lock) and pinned Docker images are your source of truth — not declarative package.json alone.
Generate an SBOM (Software Bill of Materials) on every build, store it with the deployed artefact, and rescan images already in production when new CVEs appear. That is the only honest way to answer "are we affected?" without a manual audit.
The climax: patch rate does not measure security
Here is what "100% of CVEs fixed in 48 h" dashboards hide.
Teams that triage by exposure close fewer tickets — and take less risk.
Decide and move forward without blind spots
- Set a P0–P3 grid and share it with product and hosting.
- Hook scanning into CI with blocking only on reachable prod alerts.
- Review workarounds weekly: a temporary WAF rule must not become permanent.
- Test recovery after a major dependency patch — especially on PHP, Node or Python where breaking changes are common.
To pick a host that supports your patch cycles (snapshots, mirror staging, rollback), browse our directory or compare tool.
Frequently asked questions
Should every Dependabot or Snyk alert be fixed immediately?
No. Fix what is network-exposed or runs with elevated privileges first. A critical CVE in a test dependency can wait for a planned cycle.
How do I know if a vulnerability is actually exploitable in my setup?
Cross-check the call path, exact installed version, network config and evidence of active exploitation. CVSS alone is not enough.
What if the update breaks compatibility?
Document a temporary workaround with an expiry date. An unpatched flaw without compensating controls is accepted debt.
SBOM and automated scanning — where to start?
Inventory production dependencies, hook a scanner into CI, then classify alerts by exposure before setting SLAs.
The next red alert does not ask "patch everything" — it asks where is the real exposure?