Reconcile security naming with security metadata

What the check reads

The verify-stage warning scans active KnownIssue id, title, risk and defect_class fields for a bounded set of security terms, including ssrf, exfil, credential, auth-override, idor, cross-tenant and secret. It requires a parsable CVSS vector and a cve_surface other than blank or none, unless security_relevance_justification contains reviewer and rationale. Free-form description text is excluded to avoid penalizing a careful non-security analysis.

An illustrative case

Illustrative case: a record is titled cross-tenant secret exposure but has cve_surface: none and no vector. Investigate whether the title accurately describes a reachable boundary violation. If it does, record the supported security assessment. If the wording is misleading, correct the claim or explain the deliberately non-security classification with a reviewed rationale.

Resolve the finding

1. Read the exact naming field and matched term reported by the check.
2. Assess reachability and impact before setting the vector and cve_surface. Preserve unknowns rather than inventing a confirmed exploit.
3. Reconcile the name and metadata, or record the justified exception, then rerun this check and the related severity checks.

proof audit --check security_relevance_consistent

Keep the conclusion bounded

Token matching cannot determine exploitability. A vector that parses may still contain unsupported metrics, and a non-none surface includes assessments weaker than a confirmed vulnerability. This check keeps claims consistent enough to review; reproducer evidence and security judgment establish the substance.

Continue with one real issue

Known issue security remediation present · Cvss severity consistent

Bring one finding, its requirement and the current evidence to scope a walkthrough of what your reviewer can establish and what still needs work.