Below is a brief explanation and some examples for each hidden vulnerability tag we use, and when each should be used. 

Reasons for hiding

False Positive: Used to indicate that a reported vulnerability or misconfiguration is not valid or reproducible in the tested environment (scanner artifact).
Examples:
• Web app scan shows an “authentication failure,” but the tenant’s logs show the scanner authenticated successfully.
• Scanner flags a vulnerability that occurred due to a temporary network failure or due to scanner sensitivity, but that vulnerability was manually confirmed not to exist on the tenant's asset.
• A test harness or internal staging endpoint produces scanner noise that is not present in production.
 

Mitigated: Used when a fix, configuration change, or compensating control has been implemented and verified in the target environment.
Examples:
• XSS input is now sanitized server-side; verification shows the payload no longer executes and PR #123 is linked.
• Scanner flags a vulnerable .NET version, but the tenant confirms the running instances were already patched.
• WAF rule added that blocks the exploit vector and verification logs show blocked attempts.

Accept Risk: Used when a business or risk owner explicitly accepts the residual risk after evaluating impact and alternatives. This is a formal, documented acceptance on the tenant's side(not a technical fix).
Examples:
• Legacy third-party service cannot be patched due to vendor constraints; Product Owner accepts the risk pending vendor replacement and sets a review date.
• Remediation cost outweighs impact for a low-severity issue; business approves deferral for 12 months with monitoring in place.

Other: Used for any other valid reason not covered above (out-of-scope, duplicate, environment mismatch, known test fixture). Provide a short explanation and or link to supporting evidence.
Examples:
• Finding is a duplicate of Finding #452 and has been merged.
• The flagged endpoint is a test fixture in the customer’s CI environment and is out of scope for production scans.
• Cloud metadata endpoint flagged in a tenant that uses a managed vendor (out-of-scope).

Behavior (how widely the hide applies)

• Ignore vulnerability for this assessment — hide only in the current scan/report (one-off).
• Ignore vulnerability in all assessments — persistently hide this specific finding for the tenant/project until manually unhidden.
• Ignore vulnerability class in all assessments — suppress all future findings of the same class/rule ID for the tenant (use sparingly; prefer scanner tuning).

Scoring note (platform behavior)

Our platform runs automated scans. For all reasons except Accept Risk, users may choose (via checkbox in the hide dialog) whether the hidden vulnerability is excluded from the overall assessment score or remains counted despite being hidden.
Accept Risk requires approver sign-off and by default will remain visible in risk reports and count toward the assessment score unless elevated leadership explicitly approves excluding it.