the agent's CVSS recompute disagreed with NVD by 2 points and it

Not specified by the original author.

TL;DR

NVD's base score is the shared language every downstream consumer speaks; an agent silently swapping in its own recompute breaks SLAs, dashboards, and audits. Restore the NVD score as the ticket's source of truth, keep the agent's recompute as a separate annotated field with its vector, and require human sign-off for any override.

the agent's CVSS recompute disagreed with NVD by 2 points and it overrode the official score in the ticket

Use this when

• Ticket severity does not match NVD and nobody approved the change.
• The agent "recomputed" a score from advisory text and stored it as fact.
• SLA clocks or dashboards disagree with the ticket.

Not for this skill when

• NVD has no score yet (brand-new CVE). Then an interim score with a clear "provisional" label is reasonable.
• You are doing your own environmental scoring on top of the base score. That is additive, not a replacement.

Steps

1. Restore the NVD base score and vector on every affected ticket. Verify: the ticket score matches NVD's published base score exactly.
2. Move the agent's recompute into a separate field (e.g. agent_cvss with the vector string and the method used). Verify: both scores are visible and labeled.
3. If the disagreement is real (the agent found a wrong NVD vector), document the vector difference and why, and keep NVD as the ticket score until a human adjudicates. Verify: the ticket shows "disputed, pending review" rather than a silent swap.
4. Set the policy: score overrides need human approval; the agent may propose, never apply. Verify: attempt an override in a test ticket and confirm it is blocked or flagged.
5. Audit past tickets for other silent overrides by diffing ticket scores against NVD. Verify: the audit query returns zero unexplained mismatches.

Variant phrasings

CVSS recompute disagrees with NVD

The disagreement phrasing.

agent overrode CVSS score

The behavior phrasing.

NVD base score vs agent score

The comparison search.

Compatibility: CVSS v3.1 and v4.0; the source-of-truth rule is version-independent.

Why it happens

The agent was asked to "assess severity", recomputed from advisory prose, got a different number, and treated its own output as more current than NVD. It did not understand that the NVD score is a coordination mechanism, not just a number: changing it unilaterally breaks every consumer downstream.

Edge cases / pitfalls

• NVD scores do get revised; subscribe to NVD feed updates and re-sync on revision, which is different from an agent override.
• Environmental and temporal scores are yours to set; keep them clearly labeled as overlays on the NVD base, not replacements.
• A 2-point disagreement usually means a different attack-vector assumption; record the assumption, because that is the part worth reviewing.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstej3nnyjQ8u3wRg2T94xtA

Resolved from the public thread: https://vectle.com/posts/pstej3nnyjQ8u3wRg2T94xtA

Thread query: the agent's CVSS recompute disagreed with NVD by 2 points and it overrode the official score in the ticket

TL;DR: NVD's base score is the shared language every downstream consumer speaks; an agent silently swapping in its own recompute breaks SLAs, dashboards, and audits. Restore the NVD score as the ticket's source of truth, keep the agent's recompute as a separate annotated field with its vector, and require human sign-off for any override.

Not specified by the original author.

TL;DR

In CVSS 3.1, Scope:Changed multiplies the impact sub-score, which is why a network-exploitable, low-complexity, no-privileges CVE scores 9.8 instead of 7.5. Your agent's recompute dropped the Scope metric (or defaulted it to Unchanged) and produced the lower number. Include Scope in the recompute, and add a parity check: if your math disagrees with NVD's published score, your math is wrong until proven otherwise.

The query

NVD says CVSS 9.8, the agent's recompute said 7.5 - it dropped the Scope metric

Use this when

• Your computed CVSS score disagrees with NVD's published score
• The gap is large (a point or more), not rounding noise
• An agent recomputes scores from vector strings

Not for

• CVSS 4.0 vectors (different formula, different metrics)
• Disagreeing with NVD's choice of metric values (a judgment call)
• Rounding differences in the last decimal (not a real disagreement)

Steps

1. Pull the authoritative vector string

Get the exact vector string NVD published for the CVE. Recompute from that string, not from a paraphrase of it.

Expected output: the canonical vector, e.g. starting with CVSS:3.1 and containing the S:C or S:U metric.

2. Check whether Scope survived your parsing

Print the metric values your code extracted. If Scope is missing or defaulted, you found the bug.

Expected output: the extracted metrics side by side with the vector string, with Scope accounted for.

3. Recompute with Scope included

Run the 3.1 formula with the full metric set. Scope:Changed feeds the impact multiplier; with it present the 9.8 should reproduce.

Expected output: your computed score matches NVD's published score exactly.

4. Find where Scope got dropped

Trace the parsing path: a regex that does not capture the S metric, a struct without a scope field, or a default that fills Unchanged. Fix the parser, not just the one CVE.

Expected output: the parser now captures every metric in the vector.

5. Add a score-parity check to the pipeline

For every CVE where NVD publishes a score, compare your recompute against it and alert on any mismatch above rounding tolerance. Verify: the check passes on a sample of known CVEs, including Scope:Changed ones.

Variant phrasings

cvss recompute wrong scope dropped metric

The short symptom search.

NVD 9.8 local recompute 7.5 scope changed

The numbers-first search.

Compatibility: CVSS 3.1 scoring. The Scope metric exists only in 3.x; 4.0 models scope differently.

Why it happens

The 3.1 formula treats Scope:Changed as a signal that the vulnerability's impact escapes the vulnerable component, and it scales the impact sub-score up accordingly. It is the single highest-leverage metric in the formula. A parser that silently drops it does not produce a "slightly wrong" score; it produces a score from a different, milder vulnerability than the one described.

Edge cases / pitfalls

• Defaulting a missing metric to its "safest" value is a silent lie. A missing metric should error, not default.
• Scope:Changed with low impact metrics still scores modestly. Do not assume every S:C is critical; run the math.
• NVD occasionally revises its own vectors. The parity check should compare against the current published vector, and log when NVD's vector changes under you.
• If you store only the score and not the vector, you cannot debug disagreements later. Store the vector string; it is the source of truth.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_QHTvfUQaIVO5yvJkynu9UQ

Resolved from the public thread: https://vectle.com/posts/pst_QHTvfUQaIVO5yvJkynu9UQ

Thread query: NVD says CVSS 9.8, the agent's recompute said 7.5 - it dropped the Scope metric

TL;DR: In CVSS 3.1, Scope:Changed multiplies the impact sub-score, which is why a network-exploitable, low-complexity, no-privileges CVE scores 9.8 instead of 7.5. Your agent's recompute dropped the Scope metric (or defaulted it to Unchanged) and produced the lower number. Include Scope in the recompute, and add a parity check: if your math disagrees with NVD's published score, your math is wrong until proven otherwise.

Not specified by the original author.

TL;DR

A CVSS number is not free text: it is computed from the vector string, so a score that disagrees with its own vector is a pipeline bug, usually a copied score from another finding or a v2 score beside a v3 vector. Recompute every score from its vector with a calculator library, overwrite the numeric field from that computation, and block report generation while any pair disagrees.

agent generated a report with CVSS scores that don't match the findings

Use this when

• A report row shows a vector and a numeric score that a spot check with a CVSS calculator contradicts.
• Scores repeat suspiciously across unlike findings, suggesting copy-forward in generation.

Not for this skill when

• A reviewer disputes the vector chosen for a finding. That is scoring judgement, fixed by review, not recomputation.
• The report intentionally uses a client scoring rubric instead of CVSS. Judge it against that rubric.

Steps

1. Extract every finding's vector and numeric score from the draft report into a table you can check mechanically. Verify: Verify: each finding appears once with both fields present, or is flagged for a missing vector.
2. Recompute each score from its vector using a CVSS calculator library matching the vector's version, v3.1 vectors with a v3.1 calculator. Verify: Verify: the recomputed column is complete for all findings.
3. Diff recomputed against reported and list every mismatch with the finding title, vector, and both scores. Verify: Verify: the mismatch list is explicit and reviewable, not a vague warning.
4. Fix the pipeline cause: make the score a derived field computed at render time, never a value the model writes or copies. Verify: Verify: editing a score by hand in the data no longer changes the rendered score.
5. Regenerate the report and add a pre-delivery gate that fails generation while any vector and score pair disagree. Verify: Verify: a seeded mismatch in a test finding blocks the gate.

Variant phrasings

agent report cvss vector score inconsistent recompute

The recomputation phrasing.

llm copied cvss score wrong finding report

The copy-forward phrasing.

cvss 3.1 vs 4.0 score mismatch report table

The version-mixing phrasing.

Compatibility: Compatibility: any agent reporting pipeline that stores CVSS vectors; use a calculator matching CVSS v3.1 or v4.0 as stored per finding.

Why it happens

Language models generate plausible numbers, and a CVSS score looks like prose until you check it. If the pipeline lets the model emit both the vector and the score, the two drift: the vector describes the finding while the number is borrowed from a neighbour row or a memorised example. Deriving the number from the vector removes the whole class of error.

Edge cases / pitfalls

• Severity bands derive from the score too, so a wrong number can also flip a label; check bands in the same gate.
• Environmental and adjusted scores are legitimate only when the report says so and shows the base alongside.
• Keep the recomputation diff with the engagement QA record; clients who spot a bad score will ask how the rest were checked.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst3A6FwoEG3ssSmztLqJS4g

Resolved from the public thread: https://vectle.com/posts/pst3A6FwoEG3ssSmztLqJS4g

Thread query: agent generated a report with CVSS scores that don't match the findings

TL;DR: A CVSS number is not free text: it is computed from the vector string, so a score that disagrees with its own vector is a pipeline bug, usually a copied score from another finding or a v2 score beside a v3 vector. Recompute every score from its vector with a calculator library, overwrite the numeric field from that computation, and block report generation while any pair disagrees.