18.3 Scanning Tools and Simple Vulnerability Reports
What a Scanner Actually Does
A scanner is a comparison engine: it collects facts about a target, matches them against a signature feed of known issues, and emits findings. Four collection styles cover most estates. Discovery and service probing enumerates live hosts, open ports, listening services, and protocol banners. Authenticated or credentialed checks log in with a read-only account and read ground truth: installed package lists, patch registry keys, running service versions, kernel build. Configuration and compliance checks evaluate state against a benchmark -- disabled protocols such as TLS 1.0, weak cipher suites, default or empty credentials, excessive permissions, missing audit settings -- which are findings no patch can fix. Application and container-image scanning adds dependency manifests and static or dynamic probing of request handling.
Credentialed Truth Versus Uncredentialed Guesswork
Uncredentialed scanning infers from banners and version strings. It is cheap and reaches segmented systems, but it under-counts because version numbers frequently survive without their fixes: enterprise Linux distributions backport security patches while keeping the original version string, so "openssh 7.4" can be patched or not depending on the release notes. It also cannot see local privilege issues, missing hotfixes, registry state, or software behind load balancers. Credentialed scanning queries package managers directly -- rpm and dpkg databases, Windows uninstall and hotfix keys -- and reports patch-level reality with fewer false positives and more findings. The trade-off is operational: scoped least-privilege scan accounts, key protection, and scan windows that avoid stressing fragile services.
Reading a Report Without Panicking
A useful finding is a tuple of asset, check identifier, severity, and evidence. Evidence is the decisive field: the package version observed, the banner captured, the registry value read. Read evidence first and mark false positives when a backport, an unused component, or a decommissioned duplicate host explains the result. Then deduplicate: one CVE reported by both an agent and a network scan on the same box is one issue, and the same CVE on two hundred assets is one work item with an asset list attached, not two hundred tickets. Aggregate counts by severity look alarming by design; the actionable views are "unremediated for over N days", "internet-facing assets only", and month-over-month trend of open findings against total inventory.
Keeping the Feed and the Baseline Honest
Signature feeds age within days, so a scanner that has not updated is quietly reporting a stale world. Confirm the plugin feed date, coverage percentage of known inventory, and success rate per scan target before trusting any dashboard. Unknown hosts are the largest risk in most estates, so reconcile scan results against asset inventory and directory records rather than treating the scan as the inventory. Finally, capture a baseline of configuration findings at build time -- golden images and infrastructure templates -- so drift on running systems stays visible.
Architecture Diagram
Key Takeaways
- Scanners compare collected facts against a signature feed; the feed date determines how useful the result is.
- Credentialed checks read package and registry ground truth; uncredentialed probes infer from banners and miss backported fixes.
- Configuration findings -- weak protocols, default credentials, missing audit settings -- need remediation, not patches.
- Evidence decides true versus false positive; deduplicate one CVE per asset into a single work item.
- Reconcile scans against inventory: unknown hosts and stale feeds are the two biggest blind spots.