如何為新客戶進行首次弱點掃描，建立基準

The first scan for a new client is different from every scan after it. There's no previous report to compare against, the asset list is probably incomplete, and the results will almost certainly look worse than anyone expected. Handled well, it becomes the baseline every future report is measured against. Handled badly, it becomes the scary PDF that made the client nervous in week one.

Before the scan: agree on scope in writing

A one-page scope note avoids most first-scan surprises. It should cover:

• What's in: public IP ranges and hostnames for the external scan; subnets, sites and cloud networks for the internal one
• What's out: anything fragile or owned by someone else, such as medical devices, industrial controls or a landlord's network
• When: a scan window, and who to call if something misbehaves
• Credentials: which accounts the scanner will use, and who created them
• Permission: written sign-off from someone authorized to approve scanning, especially for anything hosted by a third party

The sign-off isn't just formality. Scanning systems you aren't authorized to test can breach a hosting contract, and occasionally the law.

Get credentials working before scan day

A failed login silently turns a credentialed scan into a network-only scan, and the results look misleadingly clean. Test the scan account on a couple of Windows and Linux hosts first. On scan day, check the scanner's own authentication results before you trust a single number.

Expect a big number, and say so first

A first credentialed scan of a network nobody has scanned before routinely produces hundreds or thousands of findings. That doesn't mean the previous IT provider did a terrible job. It usually means nobody was looking.

Tell the client before they see the report:

"First scans always look worse than later ones, because they include everything that's built up over the years. Most of it comes down to a small number of fixes."

Setting that expectation turns a shock into a plan.

Present a baseline, not a verdict

The first report should do four things:

1. Show what was covered. Which hosts were scanned, which had working credentials, and anything that couldn't be reached.
2. Group findings into actions. Hundreds of findings usually collapse into ten or twenty actions: update a browser everywhere, patch a server, replace an end-of-life machine.
3. Pick a first wave. Known exploited vulnerabilities and anything exposed to the internet go first. Agree a short list the client can approve in one meeting.
4. Record the starting point. Total findings by severity, number of known exploited issues and number of hosts covered. Those are the numbers future reports compare against.

Fill the gaps the scan reveals

First scans almost always uncover something about the environment itself:

• Devices nobody had on the asset list
• Systems the scanner couldn't log in to
• End-of-life operating systems that can't be patched
• Network segments that weren't in scope because nobody knew they existed

Put these in the report as findings in their own right. An unknown device is a risk, and a host that couldn't be assessed is a gap, not a pass.

Plan the second scan now

The second scan is where the client sees progress. Book it before you leave the first meeting, usually 30 days later, after the first wave of fixes. When the next report shows known exploited issues going from twelve to two, the value of the work explains itself.

Varaxon Scan Hub reads exports from the scanners you already use and turns them into clear, client-ready reports that show coverage and gaps up front. Your first 3 reports are free, no credit card needed: varaxontech.com.

Related: Credentialed vs non-credentialed scans · Vulnerability management for MSPs

This post first appeared on the Varaxon Blog. Drafted with AI assistance and reviewed by the Varaxon team.