Every QA engineer I respect is afraid of the same thing, and it isn’t the test that fails.

A failing build is almost a relief. It’s loud, it’s specific, it tells you where to look. The one that keeps me up is the test that passes — the green checkmark on a test that asserted nothing, the suite that finished early because half of it never reached the code it was supposed to touch. It confirms the pipeline ran. It does not confirm the software works. On my team we have a name for that checkmark: the all-clear that’s really an all-blind.

These days I spend most of my time testing an autonomous offensive system — a platform whose whole job is to find the things other tools swear aren’t there. And the longer I do it, the more I think the security industry has spent ten years scared of the wrong mistake.

Two ways to be wrong

A detector can lie to you in exactly two ways.

It can go off when nothing is wrong. That’s a false positive. The alert fires, you stop what you’re doing, you chase it down, and there’s nothing there. Annoying, and expensive when it happens all day. It’s the subject of every “alert fatigue” talk you’ve ever sat through.

Or it can stay quiet when something is wrong. That’s a false negative: no alarm, no ticket, nothing red anywhere, and a real exploitable flaw sitting in production the whole time. You didn’t chase it, because nothing told you to.

Here’s the asymmetry QA beats into you early and that security keeps relearning the hard way. A false positive costs you an hour. A false negative costs you the incident. One you pay for in wasted afternoons; the other shows up in the post-mortem as the root cause. They are not the same size of mistake, and the moment you start treating them like they are, you’ll quietly optimize for the wrong one.

Why the industry flinched at the wrong threat

I get how we ended up here. The false-positive problem is real and I’m not going to pretend otherwise.

Legacy scanners are generous with alarms. SAST, DAST, the vulnerability appliances that have sat in every enterprise for fifteen years — they’ll flag the same string concatenation a thousand times, light up on dead code and unreachable branches and patterns that look dangerous but are perfectly fine in context. A team drowning in that does the only thing a human team can do. It turns the sensitivity down. It writes suppression rules. It builds a triage queue and then, slowly, stops working it.

That’s the trap. The moment you tune a tool to stop crying wolf, you’ve also tuned it to go quiet about some real wolves. Every false positive you suppress is a small bet that there’s nothing important hiding in the noise you just muted. Make that bet enough times and you’ve built yourself a false-negative machine — on purpose, with a change ticket, feeling productive the whole way.

And here’s the part nobody likes to say out loud: most “clean” scan reports are clean because the scanner couldn’t reach the bug, not because there’s no bug. The report can’t tell the difference between “I looked and found nothing” and “I never got there.” On the dashboard they’re the same green. To an attacker, only one of them is true.

The false negatives that matter are structural

If this were only about over-aggressive tuning, discipline would fix it. It’s worse than that. The dangerous false negatives aren’t tuning accidents, they’re structural — whole classes of vulnerability that a signature-matching, single-pass scanner cannot see no matter how you configure it.

Take a broken object-level authorization bug, the kind where I change one ID in a request and start reading another user’s data. A scanner looking at that one request sees a clean, well-formed API call. Right method, valid token, 200 OK, nothing to flag. The vulnerability isn’t in the request. It’s in the relationship between two requests, two users, two sessions — in the business logic, which has no signature to match against. The DAST scan comes back green, and the green is a lie of omission.

This is the part that gets under my skin as a QA engineer, because it’s the exact thing we obsess over in functional testing. A test that checks the happy path and never checks authorization isn’t a passing test. It’s an untested feature wearing a passing test’s clothes. The bug was always there. The suite just never wrote an assertion that could see it.

You don’t find these by scanning harder. You find them the way an attacker does — which is also the way a good adversarial tester does — by performing the dangerous sequence yourself. Chaining one step into the next. Treating the app as something you reason about and operate over several moves, not something you pattern-match in a single glance.

What “validated” has to mean

In QA you don’t get to call something done on vibes. “It works” isn’t an opinion, it’s a claim, and a claim has to survive evidence. A bug report with no repro steps gets bounced back. A passing test that asserts nothing gets caught in review. The whole job runs on one stubborn rule: show me.

Point that rule at security and a lot changes.

A finding you can’t prove is exploitable isn’t a finding, it’s a theory — and theories are what false positives are made of. An all-clear you can’t prove you exercised isn’t safety, it’s a hope — and unexamined hope is what false negatives are made of. The same bar kills both, because underneath they’re the same disease: a result claimed without evidence behind it.

This is the part of the job I like, because the system I test is built around that bar instead of around the dashboard. Ares doesn’t stop at “this looks vulnerable.” There’s a stage whose entire job is to prove it — to build a real triggering input that shows the flaw is reachable, not hypothetical. A finding that can’t be proven doesn’t get to graduate into a finding. That’s false-positive control done the way QA would do it: not by muting the alarm, but by making the alarm earn its place with evidence.

And evidence is usually unglamorous, which is sort of the point. The finding that stuck with me wasn’t some clever memory-corruption exploit. It was a monitoring API that would happily hand back its stored credentials in cleartext to anyone already allowed to read them. API tokens, CI keys, SNMP passphrases — more than a thousand of them — all returned in one authenticated request that came back a clean 200 OK. Nothing about the call looked wrong, and no signature scanner was ever going to flag it. I spent fifteen years as a network engineer in telecom before this work, standing up and living with exactly this kind of monitoring stack, and that’s probably why it hit the way it did — I knew how many other doors in a real network those same credentials would quietly open. This was found during authorized testing, and the details here are intentionally anonymized. The point is not the vendor, product, or customer; the point is the failure pattern — a real security weakness that looked completely normal to traditional scanning:

// Anonymized reconstruction — product and values changed, mechanism faithful.

POST /api/v2/fleet HTTP/1.1

Authorization: Bearer <api_token>

Content-Type: application/json

{ "op": "node.describe",

  "select": ["id", "name", "variables"],

  "expand": "variables" }

200 OK

{ "id": "<id>", "name": "<node>",

  "variables": [

    { "key":     "UPSTREAM_API_TOKEN",

      "value":   "tok_0123…redacted",   // returned in cleartext

      "storage": "plain" }              // "encrypted" / "vault" existed — never enabled

  ] }

// Same pattern across most of the fleet → north of a thousand

// credential-shaped values, all readable through one ordinary authenticated call.

The platform even had an encrypted storage type meant for exactly these values. Nobody had switched it on. There’s no signature for “the safe option exists and went unused.” There’s only the evidence you get from asking the question and reading the answer carefully.

On the other side — the silence side, the one I’m actually scared of — the architecture goes after false negatives directly. Instead of one scanner making one pass, a set of autonomous agents reasons about the target the way a human operator would, chaining steps to reach the business-logic flaws a single pass can’t structurally see. And they don’t mistake their own confidence for correctness: when the analysis is shaky, the doubt becomes a reason to dig in rather than something to average away. Distrusting the easy all-clear is exactly what closes the gaps a confident, lonely scanner leaves open.

The thing that won me over, though, was how seriously the platform takes not becoming the incident itself. It’s safe by design — it can show a flaw is real and reachable without barreling all the way through it and breaking the thing it was sent to check. Proving the door opens without walking through it and wrecking the room. That’s the cleanest version of the QA ideal I’ve seen on the offensive side: real evidence, in production-like conditions, without turning into the breach you were hired to prevent.

The oldest defense against silence

This is also why, on the testing side, the false negative is the error I treat with the most paranoia. The instinct that guards against it is older than any scanner — the lab sciences named it the positive control. You never trust that an instrument detects nothing until you’ve first shown it can detect something: you hand it a sample you already know is positive and watch it react. Point a detector at the open world and relax when nothing comes back, and you’ve skipped that step. The open world is never going to tell you whether the silence was earned or accidental.

So the only silence I trust is silence I’ve tried to break on purpose. When something comes back clean that I had every reason to expect would light up, that clean result isn’t reassurance — it’s an alarm. It means the instrument failed, not the target.

That isn’t a setting you toggle or a feature you ship. It’s a posture: treat the quiet as a lie until something has really tried to disturb it. I hold onto that one hard, because the cost of dropping it never lands on me. It lands on someone else, in production, months after the dashboard went green.

Stop measuring safety in silence

So here’s what I’d say to anyone who reads a “no critical findings” report and exhales.

Silence isn’t safety. A quiet dashboard is telling you one of two things and it will never tell you which: either there was nothing to find, or nothing actually went looking. Two opposite realities, the same shade of green.

The question was never “did anything fire?” It’s the one QA has been asking since long before any of us touched a security tool: did we try to break it, and can we prove both what we found and what we didn’t?

Look at where the time goes. According to Mandiant's M-Trends 2026 report, the global median dwell time — how long an intruder sits in an environment before anyone notices — was 14 days. When an organization was tipped off by an outside party rather than catching it themselves, that figure jumped to 25. And for the quietest categories, cyber-espionage and state-aligned operators with every incentive not to trip an alarm, the median was 122 days.

The industry will keep holding conferences about alert fatigue, and fair enough — it’s a real cost. But I’ve read a lot of breach post-mortems by now, and I have never once seen “too many false positives” listed as the root cause. Nobody gets breached by an alarm that rings too much. They get breached by the one that never rang — for fourteen days, or twenty-five, or a hundred and twenty-two.

Green isn’t an answer. It’s a question you haven’t finished asking.

About the Author

Shqiperim Krasniqi, MSc in Telecommunications, is a Senior QA Engineer at Assail, where he has worked on Ares since the beginning — testing an autonomous offensive platform whose non-deterministic, continuously evolving behavior demands a different kind of quality discipline than traditional software ever did. He came to it after more than 15 years as a Senior Network Engineer in telecommunications, a background that still shapes how he thinks about where real systems quietly fail. Assail is the developer of Ares, an autonomous red teaming platform for APIs, web applications, and mobile apps. Learn more at assailai.com.