What is a false positive?
A false positive is a detection error in which a security tool reports a problem that does not exist. The scanner says a patch is missing when it is installed, the IDS raises an exploit alert on harmless traffic, or the antivirus quarantines a legitimate admin tool. The tool said yes; reality says no. False positives occur in every kind of detection: vulnerability scanners, IDS and IPS, SIEM correlation rules, EDR and antivirus, DLP, SAST tools and spam filters.
The four detection outcomes
| Tool reports a problem | Tool reports nothing | |
|---|---|---|
| Problem exists | True positive | False negative |
| No problem | False positive | True negative |
The words describe the tool's verdict. Positive means it raised an alert or finding; false means the verdict was wrong.
Common causes
- Inferred versions: a non-credentialed scan reads a version banner, but the vendor backported the fix without changing the version number.
- Hidden mitigations: the vulnerable feature is disabled, or a setting the scanner cannot see blocks the flaw.
- Authorized activity: the organization's own vulnerability scanner trips IDS exploit signatures, or a backup job looks like data exfiltration.
- Thresholds without context: a rule fires on every after-hours admin logon, including a service account's scheduled jobs.
- Legitimate change: anomaly detection flags a new application, month-end processing or VPN egress that makes a user appear to travel impossibly fast.
- Pattern collisions: DLP flags order numbers that are 16 digits long and happen to satisfy the card-number checksum.
Example: confirming a scanner false positive
A scan of a Red Hat Enterprise Linux 8 web server reports several Apache CVEs because the server's banner shows httpd 2.4.37, an old upstream version. Red Hat backports security fixes into its own 2.4.37 packages. The analyst checks the installed build with rpm -q httpd and searches the package changelog with rpm -q --changelog httpd | grep CVE-, which lists the CVEs the vendor has fixed. If the reported CVEs appear there, the findings are false positives. The analyst saves that proof, adds an exception for those findings on that one host with a date to revisit it and, better still, moves the server to credentialed scanning so the scanner reads the package version itself.
Why false positives matter and how to reduce them
Every false positive costs analyst time. When they pile up, the result is alert fatigue: analysts learn that most alerts mean nothing, start dismissing them in batches and eventually dismiss a real one. On an IPS or an automated response, a false positive blocks legitimate business activity. To reduce them:
- Use credentialed or agent-based scans, which read real versions instead of guessing.
- Tune rules: adjust thresholds, add context such as asset criticality or source host, and deduplicate repeats.
- Suppress narrowly, one rule and one source at a time, with a documented reason, an owner and an expiry date.
- Run new IPS, DLP and detection rules in alert-only or monitor mode first, and test tuning changes against historical events.
Never fix noise by disabling the rule. That trades a false positive problem for a false negative one, and every broad exclusion is a place an attacker can hide.
False positive on the CompTIA Security+ exam
False positives come up in SY0-801 objective 4.3, where scan results must be validated before remediation, and in objective 4.4, where alerts are tuned so analysts act on them. Wording such as the report lists a missing update that the server owner proves is installed describes a false positive, and analysts are overwhelmed and closing alerts unread points to alert tuning. Distractors include false negative, which is a real problem the tool missed, true positive and true negative. Answers that disable the rule or ignore every alert from a source are usually wrong; a narrow, documented exception or a credentialed rescan is usually right.