Skip to content
Made in the UK

Vulnerability Management

How do you handle vulnerability false positives properly?

By , Head of SOC and IR, CybaVerse. Last reviewed

Handle vulnerability false positives by confirming each one with evidence, such as the installed version, a vendor advisory or a backported fix, before suppressing it. Suppress only that finding on that asset, record the reason and an owner, and review every suppression regularly. Never suppress a whole vulnerability or device to shorten a report.

This page is part of our vulnerability management guide.

What causes vulnerability false positives?

Scanners infer vulnerabilities from versions, banners, files and settings. That inference sometimes goes wrong. A Linux distribution may backport a security fix without changing the main version number, or a leftover file may make a scanner think old software is still installed when it is not.

NIST defines a false positive as an alert that incorrectly indicates a vulnerability or malicious activity is present. In vulnerability management, the cost is wasted engineer time and, worse, a habit of ignoring findings that eventually hides a real one.

How should you handle one, step by step?

The steps below work for most MSPs and keep a clear record behind every decision. They matter most for Cyber Essentials Plus clients, where an assessor's own scan will not know about your suppressions and an unresolved finding still counts against the device being tested.

  1. Step 1: Check the evidence

    Look at the installed version, file paths and the vendor advisory.

  2. Step 2: Look for a backported fix

    Check the vendor's security notice for fixes applied without a version change.

  3. Step 3: Fix rather than suppress where possible

    Remove leftover files or old versions that trigger the finding.

  4. Step 4: Suppress narrowly

    Suppress only that finding on that asset, with an expiry date.

  5. Step 5: Record the reason and owner

    Write why it is a false positive and who decided.

  6. Step 6: Review regularly

    Recheck every suppression at least quarterly.

What is the difference between a false positive and an accepted risk?

A false positive means the weakness is not present. An accepted risk means it is present but the client has decided, for now, not to fix it. Mixing the two is a common mistake, and it hides real exposure. Record them separately, with different owners and review dates.

False positiveAccepted risk
Weakness present?NoYes
Who decidesEngineer, with evidenceClient, with advice
ReviewRegular checkRegular check and a planned fix
Counts for Cyber Essentials Plus?Assessor may still flag itYes, if high or critical

What should you avoid?

Avoid any shortcut that makes a report look better without reducing risk. Broad suppressions are the main danger, because they also hide future, real findings on the same assets. We hear from MSPs that the hardest suppressions to unpick are the old ones nobody can explain any more.

  • Suppressing a CVE across every client
  • Suppressing every finding on a noisy device
  • Suppressions with no reason or expiry date
  • Treating accepted risks as false positives

Where does CybaOps fit?

CybaOps ties each vulnerability to the asset it affects, so engineers can check findings in context before deciding they are false positives. Continuous scanning then shows quickly whether a removed file or old version really cleared the finding, across every client tenant.

  • CybaVM gives continuous internal and external vulnerability scanning, prioritised in one place in CybaOps.
  • Vulnerability scanning in CybaOps is powered by Qualys.
  • CybaOps ties vulnerabilities to the assets they affect, so teams fix what matters first.
  • Internal scans run several times a day and external scans run daily.
  • CybaOps has role-based access control.

Vulnerability false positives

How to handle vulnerability false positives

Handle vulnerability false positives by confirming each one with evidence, such as the installed version, a vendor advisory or a backported fix, before suppressing it.

01 Scanning

Multi-tenantPartner / MSP CustomerCustomerCustomer+
CybaOps by CybaVerse

Vulnerability false positives

02 The 6-step path

  • Role-based access
  • UK-based analysts
  • ISO 27001

03 Outcomes

Explore

Hover or tap any part of the diagram to see what it does.

  • Vulnerability management in
  • CybaVM
  • CybaRemediate

What else do MSPs ask about scanner false positives?

These are the follow-up questions we hear most from MSP engineers.

Will the Cyber Essentials Plus assessor accept our suppression?

Not automatically. The assessor runs their own scans. Keep evidence for any finding you believe is a false positive, and ask your certification body how they want it presented before the assessment.

How long should a suppression last?

Set an expiry, usually no more than three to six months, so it is checked again. Software changes, and a finding that was false last quarter may be real after an update or reinstall.

Should clients approve false positive decisions?

Usually not for clear technical false positives, which engineers can decide with evidence. Accepted risks are different: the client should approve those, because they are choosing to live with a real weakness.

What should you do next?

See CybaOps vulnerability management on the CybaOps platform page. MSPs can read about the CybaVerse partner model for MSPs.

Related: How do you prove a patch actually fixed the vulnerability? and How do you prioritise vulnerabilities?

See findings checked in context in CybaOps.

Book a CybaOps demo