Automated vulnerability scanning case study: from 8,400 results to a list people act on
This retail and logistics company was already scanning for vulnerabilities, but nobody acted on the results. The reports were too long and too noisy, so the same weaknesses came back quarter after quarter. Meanwhile, its PCI DSS audit (the security standard for companies that handle card payments) was getting close.
SCAN
REMOVE DUPLICATES
PRIORITIZE
Scans with and without login · insecure settings · exposed services · linked weaknesses
A pile of reports nobody read
The company ran more than 2,000 IP addresses and over 300 web applications, with new releases every week. Its security relied on an annual penetration test and occasional scans with a commercial tool (Nessus). Each scan produced a spreadsheet thousands of rows long. IT teams could not tell which rows mattered, so mostly they ignored them.
PCI DSS 4.0 Requirement 11.3 asks for regular internal and external vulnerability scans, with evidence that problems get fixed. The company needed a process it could show its assessor, and one its own teams would actually follow.
Turning scans into a short list
We set up scanning that runs every week and also whenever a new system or deployment appears. It covers networks, servers, web applications and cloud services. Some scans log in to each system, which gives accurate patch levels. Others run from outside without credentials, which shows what an attacker would see.
The important work came after each scan. Our analysts removed duplicates, suppressed known false alarms and checked whether each issue could actually be reached. Every remaining finding went straight to the team that owned the system, with its severity, evidence and the dates it was first and last seen.
The approach follows NIST SP 800-115, the US government’s technical guide to security testing, and PCI DSS Requirement 11.3.
What was really on the list
The first cycle produced 8,400 raw results. After triage, 132 were unique and needed action.
The most urgent were 9 internet-facing servers with flaws that let an attacker run code on them remotely, in Microsoft Exchange, Fortinet devices and website software. Four of those flaws had public exploit code available, so an attack would take little skill.
Inside the network, 23 servers still ran outdated services such as Telnet, SMBv1 and Redis with no password. Two of them could be reached from the network segment used by outside vendors.
Many findings traced back to a single cause. The standard server image used to build new machines was 14 months behind on patches, so every new server started life already vulnerable.
What happened next
The client closed the critical internet-facing issues first. It then rebuilt the server image so new machines start out patched, and fewer old findings now come back after each release. The assessor accepted the internal and external scan evidence for PCI DSS 4.0.
Scans now run every week, and a report of what changed arrives on the Security Dashboard each Monday.
Teams that have stopped reading their scan reports because of the noise usually need better triage more than they need more scanning.