New: The startup CTO's field guide to running security
Read the guide
A CVE just landed in a library your app depends on. Here's the decision framework for knowing when to patch immediately, schedule it, or accept the risk.
A Dependabot alert lands in your inbox. Severity: critical. The CVE is in a library your application depends on, four package levels down from anything your team wrote. CVSS score: 9.8.
What do you do?
Most teams reach for one of two default reactions: patch everything immediately, or add it to the backlog and get to it when someone has time. Here's the thing: the CVSS score tells you how severe the vulnerability is in theory, but it doesn't know your environment, your exposure, or whether the vulnerable code path is ever called in your application.
Knowing what to do when a CVE hits a dependency requires answering three questions before you touch anything.
Every CVE published to the National Vulnerability Database gets a CVSS base score, which rates severity based on worst-case assumptions: maximum exposure, maximum privileges available, no mitigations in place. A score of 9.8 means this vulnerability would be critical if someone handed an attacker ideal conditions.
The base score doesn't know your conditions: whether the package is in production or only in your test suite, whether the vulnerable function is ever called, or whether a working exploit has been published. Those factors matter more than the headline number when you're deciding what to respond to and when.
Before you open a PR, check these three things.
Is the vulnerable code path reachable in your application? A library can contain a vulnerable function you never call. If nothing in your codebase invokes it and there's no way for external input to reach it, your practical exposure is low, regardless of the CVSS score.
Is this package exposed to untrusted input or the internet? A vulnerability in an internally-facing admin tool carries different risk than one in a package handling inbound HTTP requests from the public internet. Where the code runs and what it touches matters.
Is there a working exploit in the wild? The CISA Known Exploited Vulnerabilities catalog is the clearest signal available. If a CVE appears there, it has been actively exploited, and that overrides whatever else you found in your assessment.
With those three questions answered, the decision usually becomes obvious. In most cases, the investigation takes longer than the fix, once you've found the actual hole, it's usually a small one.
Patch now when any of the following are true: the CVE is on the CISA KEV list, the package handles untrusted input or is internet-facing, or a working proof-of-concept exploit is publicly available. This isn't a sprint-planning conversation. Fix it.
Schedule it when the severity is high but none of the above apply: not actively exploited, internal-only or low-exposure service, patch is available and the upgrade is low-risk. Put it in the current or next sprint, and don't let it drift.
Accept the risk when the vulnerability is in a dev dependency that never reaches production, the vulnerable function is never called, there's no viable exploit path, or the vendor has issued a workaround that mitigates the exposure. This is a legitimate call, but it needs to be documented.
A few things to check that take less time than an emergency patch:
Check whether the package is in production. Look at your dependency tree and confirm whether the affected package is a direct dependency or transitive, and whether it's in your production build or only in dev or test. Your package manager can surface this, and a vulnerability in a package that never runs in production is a different priority.
Check your exact version. The CVE detail page on the NVD and the GitHub Security Advisory for the package will list affected version ranges and the first patched version. If your pinned version falls outside the affected range, you may not be exposed at all.
Check the CISA KEV catalog. It's a straightforward lookup; if the CVE is listed, treat it as urgent.
Check for reachability. If your scanner doesn't surface call graph information, a grep for the affected function name is a reasonable starting point. You're trying to confirm whether any code that runs in production actually invokes the vulnerable path.
Whether you patch, schedule, or accept risk, the decision needs to be recorded: what the CVE was, what you found in your investigation, what you decided, and why.
For SOC 2 and similar frameworks, auditors aren't verifying that you patched every critical CVE within 24 hours; they're checking that you have a repeatable, documented vulnerability management process. A ticket in your issue tracker with the CVE ID, your severity assessment, your decision, and the resolution is typically sufficient evidence that you didn't just ignore it.
"We reviewed CVE-XXXX-XXXXX, confirmed the affected package is a dev dependency not present in our production build, and accepted the risk" is a defensible documented decision. "We got an alert and didn't open it" is not.
Check the vendor's security advisory for workarounds or mitigations. If the project is open source, the GitHub advisory and any linked issues often surface interim guidance from the maintainers before a patch ships.
If no mitigation exists, assess whether you can reduce exposure in the meantime: limiting access to the affected service, disabling the affected feature, or adding input validation upstream of the vulnerable path. Document what you found, what interim step you took, and set a reminder to check back when a patch ships. This is where issues fall through the cracks if they aren't tracked somewhere.
The framework above works fine for a single alert, but it breaks down at volume. Container images, for example, are a common offender: if you're running a base image that hasn't been upgraded in a while, you can inherit dozens of CVEs at once, all of them flagged at high severity by your cloud provider's scanner. Add in findings from your code scanner, your SCA tool, and whatever else you're running, and you're suddenly looking at the same vulnerability flagged four different ways with no clear signal about what to prioritize first.
At that point, the problem is the process, not the individual CVE. Pulling findings from six different scanners, reconciling duplicates, and manually building the evidence trail is what consumes the time that should go toward fixing things. Fencer consolidates security across code, cloud, network, and dependencies into one place, with findings prioritized, so your time goes to making actual security improvements, not managing the tools that are supposed to help you do it. See how Fencer works →
Check the CVE detail page on the NIST NVD or the GitHub Security Advisory for the package. Both list the affected version ranges and the first patched version. If your pinned version falls within the affected range, you're exposed. If you're already on a version beyond the patched release, you may not be, but confirm before closing it out.
CVSS (Common Vulnerability Scoring System) rates a vulnerability's severity based on worst-case assumptions: maximum exposure, no mitigations, maximum impact. The base score doesn't know your environment, so a 9.8 in a dev-only dependency with no exploit in the wild is a different problem from a 9.8 in a package handling public-facing requests. The score is a starting point, not a to-do list.
The CISA KEV catalog is a list of CVEs confirmed as actively exploited in the wild, maintained by the U.S. Cybersecurity and Infrastructure Security Agency. It's free, public, and searchable. If a CVE in your dependency is listed there, treat it as an immediate priority regardless of your other assessment. Active exploitation is the signal that overrides everything else.
Not necessarily. A vulnerability in a dev-only dependency (test runners, build tools, linters) poses minimal risk if it never runs in production and doesn't affect your build artifacts or CI pipeline output. Assess the actual exposure, then schedule the update rather than treating it as critical. The same framework applies: reachability, exposure, and active exploitation status.
Check the vendor's security advisory for interim mitigations. If none are available, assess whether you can reduce exposure by limiting access to the affected service, disabling the affected feature, or adding input validation upstream. Document the gap and your interim approach for audit purposes, and set a reminder to revisit when a patch ships. Untracked gaps are where things fall through.
Auditors are checking for a functioning, repeatable vulnerability management process, not that you patched every critical CVE the same day it was published. A ticket in your issue tracker with the CVE ID, your severity assessment, your decision, and the outcome is typically sufficient. Consistency is what matters: the same process applied to every finding, with a record that shows you reviewed it.
