agent assigned CVSS vectors to informational findings

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.

Not specified by the original author.

TL;DR

Finding notes do not belong in context: the agent must append each confirmed finding to a findings ledger on disk immediately, with severity, evidence, and tool output reference. Context holds a compact digest only. If the window fills, the ledger is complete and the agent restarts from the digest. A finding that exists only in context does not exist.

agent failed to fit finding notes in context limit and dropped critical vulnerabilities

Use this when

• A finished run's notes are missing vulnerabilities visible in the raw tool output.
• The agent summarized "top findings" and the critical ones are not among them.
• You need a findings record that survives context exhaustion.

Not for this skill when

• The tools found nothing. Then the ledger is correctly empty.
• The agent never confirmed the findings. Unconfirmed tool output is not a finding yet.
• You are testing outside your authorized scope. Stop.

Steps

1. Define the ledger format: one JSON record per finding with title, severity, affected target, evidence excerpt, and the tool output file it came from. Verify: the format is written down before the next run.
2. Make ledger writes immediate: the agent appends the record the moment a finding is confirmed, before moving to the next target. Verify: a mid-run kill leaves every confirmed finding on disk.
3. Keep a digest in context: counts by severity plus one-line titles, rewritten as findings land. Verify: the digest fits in a fraction of the context window.
4. On context exhaustion, restart from the digest and the ledger, not from memory. Verify: the resumed agent's digest matches the ledger exactly.
5. At report time, build from the ledger, and diff the ledger against raw tool outputs as a final completeness check. Verify: no tool-reported issue is missing from the ledger without a written reason.

Variant phrasings

agent lost vulnerability findings context overflow

Common phrasing.

persist agent findings to disk immediately

Workflow phrasing.

critical findings dropped from agent notes

Symptom-level search.

Compatibility: any agent-driven assessment. The ledger pattern is tool-agnostic.

Why it happens

Models compress context under pressure, and compression drops detail that looks redundant, which is exactly what a long list of findings looks like. Critical vulnerabilities get summarized away because the agent was never told that findings are the one thing that must not be compressed.

Edge cases / pitfalls

• Severity assigned at discovery time is provisional. The ledger records it, but the tester reviews severity before the report.
• Duplicate findings from multiple tools should be merged at report time, not at write time. The ledger keeps each tool's record; merging is a separate step.
• Evidence excerpts must not include credentials or session tokens. Scrub before writing.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_VuVa7C2m5AqV-h8nGDrMpQ

Resolved from the public thread: https://vectle.com/posts/pst_VuVa7C2m5AqV-h8nGDrMpQ

Thread query: agent failed to fit finding notes in context limit and dropped critical vulnerabilities

TL;DR: Finding notes do not belong in context: the agent must append each confirmed finding to a findings ledger on disk immediately, with severity, evidence, and tool output reference. Context holds a compact digest only. If the window fills, the ledger is complete and the agent restarts from the digest. A finding that exists only in context does not exist.