Application Security

False Positives

A false positive is when a security tool reports a problem that does not actually exist.

False Positives

TL;DR

In security, a false positive occurs when a tool reports a problem that does not actually exist.

What Is a False Positive?

A false positive is when a security tool reports a problem that does not actually exist.

Simple example:

  • Real problem: The smoke alarm goes off because there’s a fire.
  • False positive: The smoke alarm goes off because of steam from cooking.

The alert is real, but there is no actual danger.

Why False Positives Are a Problem

False positives do more than waste time. They can lead to real problems as time goes on.

They lead to:

  • Wasted time fixing problems that don’t exist
  • Frustration between security and development teams
  • Higher risk because real problems get ignored

Why False Positives Happen

Security tools are designed to be careful. It is safer for them to give too many warnings than to miss a real attack.

Common reasons:

  1. No context

    A tool sees a hardcoded password, but it’s only in a test file.

  2. Complex code

    The tool thinks user input is unsafe, but the code already cleans it.

  3. Old rules

    New, safe software looks like an old threat.

  4. Rules that are too broad

    For example, flagging every use of eval() even when it’s safe.

The Real Cost of False Positives

The real problem comes when too many alerts build up.

  • Teams stop paying attention to alerts.
  • Builds and releases slow down.
  • Skilled engineers waste time reviewing fake issues.

False Positives vs False Negatives

TermWhat It Means
True PositiveA real problem is correctly found
False PositiveA problem is reported but isn’t real
True NegativeSafe code is correctly ignored
False NegativeA real problem is missed (this is dangerous)

FAQ

How do I know if an alert is a false positive?

You should review the code to determine whether a real user could trigger the issue.

Can tools have zero false positives?

No. The goal is to reduce them, not remove them completely.

Should I stop using a tool with many false positives?

Not immediately. Most tools need tuning to match your codebase.

Ready to validate what matters?

Ready to validate what matters?

Plexicus is Proof-Driven AppSec: validated findings, contextual understanding, and reviewed remediation — anchored in evidence, scoped with you.

Qualification

Check whether AI Swarm Pentest fits your environment.

Share the minimum context. We will review the scope and tell you the next commercial step.

Before submitting — verify you fit

Teams with fewer than 50 developers: start a 14-day Trial instead of booking a demo. Start a 14-day Trial →

0 / 280

No commitment. If you don't fit, we'll tell you.

SAMPLE HANDOVER · ILLUSTRATIVE

Sample evidence handover

A trimmed view of what your team receives at the end of an AI Swarm Pentest engagement. Real engagements include full technical evidence, executive narrative, and a remediation plan.

VALIDATED FINDING Evidence attached

Server-Side Request Forgery in webhooks/receiver

demo-project/sample-app · src/webhooks/receiver.py:42

SeverityHigh CVSS 3.18.6 Priority79 Confirmedvia replay

Untrusted caller-supplied URLs reach an internal egress without an allowlist. Replayed in a sandbox against a fresh authorised target — the same control was validated to fail twice.

REVIEWER-READY REMEDIATION Merge-ready PR

Validate the target URL against an allowlist of permitted hostnames. Reject private/internal IP ranges. Enforce HTTPS only.

plexicus/remediation/webhooks-ssrf 3 changed · 0 new files
42resp = requests.get(target_url)
42+if not is_allowed_host(target_url):
43+  raise WebhookRejected(target_url)
44+resp = requests.get(target_url, timeout=5)
Every engagement hands over:
  • Executive briefing
  • Validated findings list
  • Merge-ready PRs
  • Compliance mapping (NIS2 · DORA · CRA)