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

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.

Not specified by the original author.

TL;DR

Informational results are observations without a demonstrated security impact, and scoring them inflates the report's numbers and confuses every downstream metric. Set the pipeline rule: info findings carry no vector and no score, only a description and evidence; anything the agent believes is scorable must be promoted to a real severity with a justification, not quietly scored at info level.

agent assigned CVSS vectors to informational findings

Use this when

• The findings table shows info severity rows that nevertheless carry CVSS vectors and numeric scores.
• Report statistics, such as average score or counts by band, are distorted by scored info rows.

Not for this skill when

• A finding is rated low with a small vector. That is coherent scoring, not this defect.
• The client contract asks for scored observations under a named internal scheme. Then the scheme, not CVSS, should be shown and labelled.

Steps

1. Audit the report data URIs list every finding whose severity is informational and check which carry a vector or a score. Verify: Verify: the affected rows are itemised.
2. For each, decide with the evidence: true observation with no impact, or an under-rated real issue; promote the real issues to a scored severity with a one-line justification. Verify: Verify: every formerly scored info row is either unscored or promoted with its justification recorded.
3. Strip vector and score from the remaining info findings in the data, leaving their description, evidence, and recommendation intact. Verify: Verify: info rows render with no score fields anywhere in the report, including appendices.
4. Encode the rule in the report builder: the renderer refuses a vector or score on an informational finding, and the import path clears those fields for info results from scanners. Verify: Verify: a test info finding with a score attached fails the render check.
5. Recompute the report's summary statistics after the fix and note the correction if a draft was shared, since averages and counts will shift. Verify: Verify: statistics are computed only over scored findings and match the table.

Variant phrasings

informational findings should not have cvss scores

The rule phrasing.

agent scored info findings inflate report metrics

The metrics phrasing.

promote or unscored informational pentest finding

The triage phrasing.

Compatibility: Compatibility: any agent reporting pipeline using CVSS; scanner imports from nuclei and Burp commonly include info-level templates and issues.

Why it happens

Scanners emit informational results constantly, and a pipeline that scores everything uniformly will dutifully attach vectors to banner disclosures and missing-header observations. Models may also invent a vector to fill a required-looking field. The result is worse than noise: scored infos pollute severity statistics, imply a measured risk nobody assessed, and make genuinely scored lows indistinguishable from observations.

Edge cases / pitfalls

• Some infos are one step from a real issue, for example a version disclosure for a component with known flaws; the honest treatment is an observation that names the concern, still unscored.
• If the client wants every observation tracked numerically, use an internal tracking id, not a risk score.
• Check charts and dashboards fed by the report, not just the document; scored infos often live on in exported data.

Provenance

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

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

Thread query: agent assigned CVSS vectors to informational findings

TL;DR: Informational results are observations without a demonstrated security impact, and scoring them inflates the report's numbers and confuses every downstream metric. Set the pipeline rule: info findings carry no vector and no score, only a description and evidence; anything the agent believes is scorable must be promoted to a real severity with a justification, not quietly scored at info level.

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.