Just saw the announcement land in my inbox. Mend is now "supporting" CVSS 4.0. My immediate reaction: great, another vector metric to potentially misconfigure or misinterpret in our already noisy dashboards. Don't get me wrong, the framework itself is a necessary evolution. But let's be honest, the gap between a vendor checking a box for "support" and it being meaningfully actionable in a pipeline is where the real incident fire drills happen.
I'm thinking about the transition period. Most of our tooling and internal policies are still built around CVSS 3.1. Now we'll have a period where some vulnerabilities get a 4.0 score, some get 3.1, and the prioritization engine has to somehow reconcile them without creating nonsense. Remember when the base score adjustments in 3.1 broke our auto-remediation thresholds and started auto-creating JIRA tickets for thousands of low-severity libs? I do.
```yaml
# Example of the kind of policy chaos I'm anticipating
policy_before:
fail_criteria:
- severity: CRITICAL # CVSS 3.1 >= 9.0
- severity: HIGH # CVSS 3.1 >= 7.0
# What does this map to in CVSS 4.0? 'Critical' and 'High' still exist but the thresholds are different.
# Do we now run two parallel scoring systems?
```
The announcement is predictably light on how this actually integrates into existing workflows. Does the Mend API now return *both* scores during the transition? How do their "unified" priority scores (the ones that actually drive our pipelines) handle the blend? Without clear guidance, we're all just beta testers for their scoring logic. I'm waiting for the first Sev-1 call because a 4.0 "Critical" got suppressed where a 3.1 "High" would have fired.
Has anyone already toyed with this in a pre-release or seen concrete docs on the implementation? I'm less interested in the marketing bullet points and more in the actual data model changes and how they expect us to migrate policies without introducing blind spots.
Totally feel you on the transition pain. I'm still pretty new to this side of things, but even I can see the headache of having two scoring systems active at once. Your JIRA ticket story is a great (and scary) example.
Our team relies heavily on priority tiers from our dashboards. If the scores aren't comparable, it's going to cause a lot of manual re-checking. How are you planning to handle the overlap? Just run both systems side-by-side for a while and ignore the 4.0 scores until everything catches up? 😬
Ask me in a year
You've hit on the core operational risk right there. The mapping problem between 3.1 and 4.0 thresholds isn't just academic; it will directly drive flawed automation if not handled meticulously.
Your YAML snippet is the perfect example. Blindly translating `CRITICAL >= 9.0` from 3.1 to 4.0's `>= 9.0` would be incorrect, as the underlying scoring granularity and qualitative severity ratings have shifted. The immediate practical step is to treat them as separate, non-comparable data points for now. Our policy is to run them in parallel, but our automation only acts on the 3.1 score during a defined transition period. All 4.0 scores are logged and reviewed, but they don't trigger gates or tickets yet.
This forces a manual review phase, which is painful but necessary to rebuild trust in the new metric. We're using this time to correlate a sample set of vulnerabilities that have both scores, building an internal mapping table that reflects how *our specific environment and threat model* aligns with the new framework. The vendor's "support" checkbox is just the starting line.
Your plan to run them side-by-side is the right first step, but don't just "ignore" the 4.0 scores. You need to actively compare them.
Log both scores for the same CVE and analyze the deltas. That's the only way to build a reliable mapping for your specific environment. Your dashboard priority tiers will break if you just wait for universal vendor mapping.
We found that a 3.1 CRITICAL could be a 4.0 HIGH due to the new Supplemental metrics for things like Automatic Update. That change alone will wreck your auto-ticketing if you don't account for it.
Five nines? Prove it.
Running them side-by-side is definitely the pragmatic move, but I wouldn't ignore the 4.0 scores entirely. That comparison data is gold for building your own internal mapping.
We're taking a similar approach, but we're flagging any CVE where the 4.0 score would place it in a different severity band than the 3.1 score. That gets a quick manual review to understand why. It's extra work upfront, but it helps calibrate our team's intuition for the new framework.
The key is to treat 4.0 as a separate, non-comparable data stream until you have enough of those reviewed deltas to trust it.
Ask me about my RFP template
Flagging deltas for manual review is a smart way to build that internal mapping. We did something similar when a major API changed its webhook payload structure.
We created a simple Zapier zap to catch events, log both the old and new format side-by-side in a sheet, and flag any mismatches in key fields. It forced us to understand the *why* behind each change, not just that there was a change. That context is what made the eventual switch reliable.
Have you looked at automating that comparison step? It could save some of that manual review time.
Webhooks or bust.
That's a great point about actively comparing them, not just logging. The example about Automatic Update really makes it click.
But how do you log them side-by-side in practice if the data comes from different sources or API versions? Like, would you store the 3.1 and 4.0 scores as separate columns on the same record, or is it messier than that? I'm worried about the data modeling for that delta analysis, not just the analysis itself.
rookie
You've got it exactly right. The gap between a vendor announcement and actual pipeline stability is where the real work happens. Your YAML example points to the heart of it: those policy definitions are the first thing that needs a formal review, not just a blind mapping.
I remember that 3.1 transition too, and the flood of tickets. It taught us to build a mandatory "scoring quarantine" into our change process for any new metric. New scores get logged and compared, but they don't drive automation until we've manually validated a significant sample. It's the only way to avoid the nonsense.
— isabel