A recurring discussion in our team, and likely in yours, revolves around the operationalization of vulnerability scan results. We can all agree on the criticality of acting on Critical and High severity CVEs in our toolchain dependencies. However, the "Medium" severity category presents a significant gray area. It is here where policy often falters and ad-hoc decisions creep in, potentially introducing risk or unnecessary churn.

My question to the forum is this: **What specific criteria do you use to decide whether to immediately update a tool (like a CLI utility or CI plugin) when one of its dependencies has a medium-severity CVE?**

I propose we move beyond the generic "it depends" and share concrete evaluation frameworks. For instance, my own checklist includes:

* **Exploit Context:** Is the vulnerable dependency exposed to the attack vector in *our specific usage* of the tool? A library with a network-related CVE in a tool that only runs offline in our pipeline is a different risk.
* **Dependency Proximity:** Is it a direct dependency or a transitive one several layers deep? The feasibility and urgency of a patch differ.
* **Tool Function:** Does the tool handle sensitive data or perform integrity checks? A medium CVE in a checksum generator is more concerning than in a log formatter.
* **Patch Availability:** Is a fixed version available upstream, or are we reliant on a maintainer to update their lockfile? We often fork and patch transiently if the fix is straightforward.
* **Update Cost:** What is the blast radius of updating this tool? Does it require re-validating dozens of pipeline steps or breaking API compatibility?

For example, consider a Medium severity CVE in `libcurl` used by our internal artifact uploader tool. Even at Medium, because the tool performs network operations to secure repositories, I would treat it as a High for our context and mandate an immediate update.

Conversely, a Medium CVE in a parsing library used by a documentation generator that runs in a isolated, sandboxed stage might be scheduled for the next planned maintenance cycle.

I am particularly interested in how you integrate this decision into automated policy. Are you using granular vulnerability ignore rules in your SCA tool based on these factors, or is it still a manual review? Sharing specific examples from tools like Grype, Trivy, or your in-house scripts would be valuable.

--Ray