Most of your scan findings are noise

A PCI DSS scan comes back with forty-seven findings and a red "FAIL" at the top, and the room panics. It shouldn't. A passing scan and a defensible posture are different things, and the gap between them is almost entirely noise. We've worked the merchant side and the Approved Scanning Vendor side, and the first thing we do with a fresh report is the least glamorous: we throw most of it away, on purpose, with evidence.

The noise comes in predictable shapes. False positives — the scanner flags a header it can't see behind your CDN, or a CVE for a library version you don't actually run. Informational findings that are findings the way a smoke detector beeping at toast is a fire. And the big one, duplicates: thirty rows that are all the same missing patch on the same host, counted thirty times because the tool counts ports, not problems. None of those are a vulnerability. All of them have a checkbox.

The breakdown above is a real scan, anonymised. Of a hundred findings, eighty-six were noise we could close with a documented reason — a false-positive review, a compensating control, evidence packaged so the QSA's life is easy and the dispute is already written. Fourteen were real. The work that earns the pass isn't finding the fourteen; the scanner already found them. The work is being able to defend the eighty-six you closed without touching, in writing, when someone asks why.

But triage is the first ten percent of the job, not the job. Finding a real bug — even a serious one — is the cheap part; the scanner did it for free. The expensive part is everything after the finding, and that's the part most reports skip. They hand you a CVSS score and a sentence of advice and call it a day. We stay through the fix, because a finding nobody owns is just a finding you'll see again on the next scan.

The bar above is where the hours actually go on one real finding. Ten percent to confirm it's real and reproduce it. Then the ninety percent nobody quotes you for: scoping the blast radius, threat-modelling whether it's exploitable in your environment or just in theory, writing the patch, getting the patch through code review, and re-scanning so you can prove the thing is closed. "Finding the issue is the first ten percent" is on our service page because it's the line clients remember a year later, usually while paying someone else for the other ninety.

What we won't sell you is reverse-engineering protection by default. It's the easiest upsell in security — obfuscation, anti-tamper, a binary nobody can read — and most of the time it's armour on a door that was never the way in. We'll scope it when the threat model warrants it: an app shipping secrets to a hostile client, a real piracy surface. We won't bolt it onto a payment backend whose actual risk is an over-broad cardholder data environment and a forgotten admin endpoint. Honest scoping is cheaper than honest-looking scoping, and it survives the next auditor.

What changed since we started saying this out loud: the questions got better. Clients used to arrive asking "how do we make the scan pass" — a question with a dishonest answer and an expensive one. Now they arrive asking "which of these forty-seven actually matter," which is a question we can answer in an afternoon and defend for a year. The scan was never the point. The posture behind it is, and the posture is mostly the six you decided to fix.