Stop Patching Everything: Why Your CVSS Score Means Nothing Without Context

I spent three hours last Tuesday patching a "critical" vulnerability on a development database that nobody uses. It was a 9.2 severity score, so obviously it had to be done immediately. Our security team flagged it, the alert system screamed, and I went into emergency mode. By the time I realized the server wasn't exposed to the internet and had zero sensitive data, I'd already burned the afternoon and delayed actual work on our production API that had a much lower-scored but genuinely exploitable issue.

That's when I realized I'd been doing vulnerability management completely wrong. I was treating CVSS scores like absolute truth instead of what they actually are: one data point in a much more complex risk equation. The number itself means nothing without understanding where the vulnerability lives and why someone would actually want to exploit it.

The Problem With Treating Every High Score the Same

Here's what most teams do wrong: they see a 7.5 or 9.0 and immediately panic. Security tools throw these scores at you relentlessly, and if you're like me, you assume higher number equals higher priority. But that's backwards thinking.

A CVSS score is calculated from specific technical characteristics—attack complexity, required privileges, user interaction, scope. These measurements tell you about the vulnerability itself, not about its actual impact on your business. A critical vulnerability on an internal tool used by five people is objectively less risky than a medium-severity issue on your customer-facing API.

The original article calls this "the golden rule," and it stuck with me: context beats score every single time.

Breaking Down the Three Layers of Real Risk

When I started thinking about vulnerability management properly, I realized I needed to ask three different questions:

Base metrics answer "Is this technically exploitable?" This is the standard CVSS score you usually see. It's important, but it's just the foundation.

Temporal metrics ask "Is this being actively exploited right now?" If there's public exploit code and hackers are using it today, that changes everything. A 6.0 vulnerability with active exploits is more dangerous than a 9.0 theoretical one with no available tools.

Environmental metrics are what I had been ignoring entirely: "Does this matter in my environment?" Your internal staging server, your legacy admin panel nobody really uses, your containerized service that's firewalled behind three layers—these all change the actual risk profile.

I started tracking this information in our vulnerability management process, and it immediately shifted our priorities.

Shifting Left Means Building Risk Into Your Pipeline

The other insight that resonated was about integrating this earlier in the development process. We weren't scanning dependencies until after deployment, which meant we'd discover vulnerabilities in production and scramble to update.

Now we're using SCA tools in our CI/CD pipeline to catch risky third-party libraries before they merge into main. If someone pulls in a package with a known dangerous CVE, the build fails and the developer sees it immediately. This friction is good friction—it costs a few minutes now instead of hours in emergency patches later.

Here's what a simple dependency check looks like in our CI configuration:

- name: Check Dependencies for Known CVEs
  run: |
    npm audit --production --audit-level=moderate
    if [ $? -ne 0 ]; then
      echo "Critical vulnerabilities detected in dependencies"
      exit 1
    fi

It's not sophisticated, but it catches the obvious stuff before it becomes anyone's problem.

What I'm Still Figuring Out

I agree with the article's framework, but I have questions about implementation at scale. How do you actually maintain this environmental metadata as your infrastructure grows? We've got 40+ services across multiple environments, and manually tracking "which vulnerabilities matter where" sounds like it becomes a nightmare.

Also, threat intelligence alignment is harder than it sounds. CISA's active exploitation catalog is valuable, but correlating it with your specific tech stack and environment requires tooling and expertise most teams don't have.

The Real Takeaway

Stop treating vulnerability scores as pass/fail metrics. Start treating them as inputs to a decision that needs to incorporate where that vulnerability lives, who could exploit it, and what would actually break if someone did. This means more work upfront in understanding your infrastructure, but it saves you from the panic-driven, meaningless patching that wastes everyone's time.

The question I'd ask you: When was the last time you actually declined to patch something because it didn't matter in your context? Most of us haven't. We should start.

Source: This post was inspired by "CVE & CVSS Scores: Strategic Integration in Vulnerability Management" by Dev.to. Read the original article