Security · Topic 09 of 23 · Part II — Catalog of testing methodologies

Vulnerability Scanning

Automated tools that identify known weaknesses at scale — the workhorse of operational security, and the most misunderstood tool in the field.

Syllabus: § Testing Methodologies and Tools of the Trade (2, 4) → Vulnerability scanning

Topic 09 · Automated detection

Not a pentest. Not a magic bullet. The beginning of the work.

By the end of this topic you can:

Define vulnerability scanning and distinguish it from penetration testing, vulnerability management, and configuration auditing
Name the major scanner categories and the surface each covers
Interpret scanner output critically — severity, false positives, false negatives, authenticated vs. unauthenticated
Plan a vulnerability scan with sensible coverage, rate-limiting, and impact considerations
Place scanning correctly in a continuous vulnerability-management program

What a vulnerability scanner does

1Discover targets — hosts, services, applications, containers

2Probe each target for known indicators — ports, banners, versions, patterns

3Match observations against a database of known vulnerabilities

4Report findings with CVSS severity, evidence, CVE/CWE refs, remediation

Critical constraint The defining word is known. A scanner finds problems whose pattern is in its database — not zero-days, not logic flaws, not anything requiring business context.

What scanning is not

Not penetration testing Scanning identifies potential vulnerabilities. Pentesting exploits selected ones to confirm and demonstrate impact. Many critical findings are not exploitable in context.

Not vulnerability management Scanning is one feed into the full lifecycle: discover → triage → assign → remediate → verify → close. Scanning alone produces dashboards no one acts on.

Not configuration audit Compliance checks (CIS benchmarks, STIG) verify a desired baseline, not whether the system is exploitable — useful but distinct.

Not asset discovery A scanner sees what is reachable, not necessarily what exists. Authoritative asset inventory requires CMDBs and cloud APIs.

Scanner categories

Category	What it covers	Representative tools
Network / infrastructure	IP ranges, open ports, service vulnerabilities	Nessus, Qualys VM, InsightVM, OpenVAS
Host / agent-based	Installed software, missing patches, config — from inside	Tenable agent, Tanium, Defender VM
DAST (web app)	Injection, XSS, auth flaws via live crawl and probe	Burp Suite, OWASP ZAP, Acunetix
SAST (source code)	Risky patterns in source — no runtime required	SonarQube, Semgrep, CodeQL, Checkmarx
SCA (dependencies)	Vulnerable open-source libraries in the dependency tree	Snyk, Dependabot, OWASP Dep-Check
Container / image	Vulnerable OS packages and app deps in images	Trivy, Grype, Snyk Container
CSPM (cloud posture)	Cloud misconfigurations: open buckets, permissive IAM	Wiz, Prisma Cloud, AWS Security Hub

Coverage requires the right tool for the right surface — no single scanner covers all of these.

Authenticated vs. unauthenticated scans

Unauthenticated

Sees only what an external attacker sees: open ports, banners, observable behaviour
Useful as a "stranger's view"
Higher false-positive rate — relies on banner-version guessing
Should never be the only scanning a mature program does

Authenticated

Scanner logs in with credentials — reads installed software, config files, patch state
Finds 5–10× more findings; far more accurate
Requires protected scanner credentials — scanner accounts are powerful targets
Default for internal scanning in mature programs

This is a scoping decision — make it deliberate and document it.

Active vs. passive techniques

Active scanning Sends probes to the target — port scans, banner grabs, service-specific packets, web requests with payloads. The scanner generates new traffic. This is what most commercial scanners do.

Passive scanning Observes existing traffic from a tap or flow records. Fingerprints hosts without sending anything new. No disruption risk, but limited to what traverses the observation point.

OT / ICS environments Active scanning can crash older industrial devices. Passive techniques and conservative profiles are mandatory in operational technology environments.

How a network scanner works

1Discovery — ping sweep, TCP/UDP probes, ARP scan

2Service detection — banner grab, protocol handshake

3Version fingerprinting — identify software and version

4Vulnerability matching — cross-reference against CVE database and plugins

5Active checks — non-destructive probes that confirm exploitability, not just version

6Reporting — aggregate, deduplicate, attach metadata

Steps 3–4 are version-based (false-positive-prone). Step 5 is behavioural (more trustworthy). Know which kind each plugin uses.

Reading scanner output critically

A finding typically includes: title, severity (CVSS), affected target, evidence, CVE/CWE references, suggested remediation.

Before acting, ask:

Is the evidence specific enough to confirm — or is it banner-version only?
Is the CVSS severity appropriate in this context (isolated vs. public-facing with PII)?
Is the vulnerability actually reachable and exploitable here?
What does remediation actually require — is "upgrade" even feasible?

Transformation required Raw scanner output is not a useful report. The analysis work — confirming findings, adding context, assessing real risk — is where professional value lives and cannot be skipped.

False positives and false negatives

False positives Scanner reports a vulnerability that is not present or not exploitable.

Version-string-only matching
Backported patches not reflected in version strings
Compensating controls the scanner cannot see
Offline services flagged from unrelated probes

False negatives Vulnerabilities present but missed.

Vulnerability not yet in the database
Requires authenticated access; scan was unauthenticated
Logic-level flaw — no signature exists
Scanner never reached the asset

Treating scanner output as ground truth produces noisy reports clients learn to ignore. Triage is part of the work.

Planning a scan

Confirm scope and authorization — scanning unauthorized assets is illegal regardless of intent (Topic 04)
Choose the right scanner for the target surface
Decide on authentication — authenticated where possible
Set aggressivity — conservative/safe profiles on production; exploit-style checks can crash services
Rate-limit — a full-port scan against a fragile network can degrade service; coordinate with operations
Maintenance windows — coordinate with the client; avoid known blackout periods
Verify coverage — confirm the scanner reached the expected assets; a clean report because the scanner never arrived is the worst outcome

Scanning in a continuous program

1Discovery — continuous asset inventory

2Scanning — scheduled and triggered scans

3Triage — review, deduplication, false-positive marking, context overlay

4Prioritization — severity, exploitability, exposure, business impact

5Assignment — owners, SLAs, ticketing

6Remediation — patch, configure, mitigate, accept

7Verification — rescan to confirm fix; close the ticket

Perspective Scanning is step 2 of 7. Write reports with awareness of where they fit in the client's downstream process.

Syllabus tools: Nessus and OpenVAS

Nessus (Tenable) De facto commercial reference for network/host vulnerability scanning. Wide plugin coverage, mature reporting, extensive authenticated-scan support. Tenable.io and Security Center extend it to enterprise programs.

OpenVAS / Greenbone Open-source descendant of the original Nessus codebase. Less polished than commercial alternatives but capable and widely used in smaller organizations and cost-constrained contexts.

Web-application scanners (Burp, ZAP) are covered in Topic 17. SCA tools in Topic 15. Cloud posture is covered in Part III.

Check — interpreting scanner findings

Reflection

A scanner reports a critical CVSS 9.8 finding on a server. What do you actually know, and what would you verify before treating it as a confirmed problem?

Reveal answer

You know the scanner observed a pattern matching a known vulnerability. You do not know: whether the vulnerable code is reachable; whether compensating controls neutralize it; whether the asset is critical or sandboxed; whether the version-string match is accurate (backported patches?); whether a public exploit exists. Verify: reachability, exploit availability (KEV/EPSS), asset sensitivity, version vs. actual behaviour.

What you take home

Scanners find known weaknesses at scale — not zero-days, not logic flaws, not problems requiring business context
Scanning is not penetration testing, not vulnerability management, not configuration audit
Authenticated scans find 5–10× more findings and are far more accurate than unauthenticated scans
Different surfaces require different scanner categories — no single tool provides full coverage
Raw scanner output requires triage; false positives and false negatives are routine, not exceptional
Planning a scan means confirming scope, authentication, aggressivity, rate-limiting, and coverage
Scanning is step 2 of a 7-step continuous vulnerability-management cycle

Next: Topic 10 — Manual Review. Where automation stops, human judgment begins — code review, design analysis, and the findings no scanner will ever produce.

END · TOPIC 09

Known vulnerabilities. Automated detection. Human judgment.

Before the next session: identify one scanner category relevant to a system you use or build — and note what it cannot see.