Implement the appropriate vulnerability scanning method
Asset discovery, scan types and timing, credentialed vs non-credentialed, agent vs agentless, and scanning fragile systems safely.
- Reading time
- 24 min read
- Flashcards
- 18 cards
- Practice questions
- 8 questions · 2 PBQs
Scanning is not one decision. It is five or six, and each one trades coverage against risk, cost, or disruption. The exam almost always gives you a constraint — a fragile system, a regulatory requirement, a business-hours restriction — and expects the scan design that respects it.
So do not memorise scan types. Memorise what each choice costs you.
Know what you have first
Asset discovery
Finding and inventorying what is actually on the network, including what nobody documented. An unknown asset is unscanned by definition, and it is where the unpatched vulnerability lives.
Discovery comes before scanning for a reason worth stating plainly: a vulnerability management programme's coverage is capped by its asset inventory. A perfect scanner pointed at 80% of the estate produces a report that is confidently wrong about the other 20%.
Mapping identifies live hosts and the topology. Enumeration goes further — open ports, running services, versions, and shares. Both precede assessment.
Asset criticality
How much the organisation depends on an asset. It drives scan scheduling, scan aggressiveness, and — later, in 2.3 — remediation priority. A vulnerability's severity is not the same as its importance to you.
The scanning decisions
Credentialed
- Logs in and reads actual patch and configuration state
- Far more accurate, far fewer false positives
- Sees what an attacker sees after gaining access
- Requires managing privileged scan accounts
Non-credentialed
- Probes from outside like an unauthenticated attacker
- More false positives — infers versions from banners
- Shows exposure before authentication
- No credentials to protect
The tellCredentialed for accuracy, non-credentialed for the attacker's-eye view. If a question complains about false positives, credentialed scanning is usually the fix.
Agent-based
- Software installed on each host
- Works for laptops that are rarely on the network
- Continuous, no scan window needed
- Deployment and maintenance burden
Agentless
- Scans over the network, nothing installed
- Nothing to deploy or update on the host
- Needs the host to be reachable and powered on
- Cannot cover roaming or off-network devices
The tellIf the stem mentions remote workers, laptops that are seldom on the VPN, or cloud instances that come and go, the answer is agent-based.
Internal vs external scanning
External scanning runs from outside the perimeter and shows what an internet-based attacker can reach. Internal scanning runs inside and shows what an attacker with a foothold can reach. They answer different questions, and mature programmes do both.
Passive vs active
Active scanning sends traffic and probes systems. Passive scanning observes existing traffic and infers what is there. Passive finds less and is invisible to the systems it discovers — which is why it is the answer for fragile equipment.
Check yourself
A hospital needs vulnerability data for networked infusion pumps that have crashed during previous scans. What approach is appropriate?
Scheduling and the constraints around it
The recurring considerations, and what each one means in practice:
| Consideration | What it forces |
|---|---|
| Business operations | Scan windows outside peak hours; agreed maintenance windows |
| Performance impact | Throttled scans, or agent-based to spread the load |
| Data sensitivity | Tighter handling of scan results, which are themselves a target |
| Regulatory requirement | A minimum cadence — PCI DSS requires quarterly plus after significant change |
| Segmentation | Scanners placed inside each segment, or the firewall hides what is behind it |
Assessing code, not just hosts
- SAST — static analysis of source code without executing it. Finds flaws early and cheaply; produces false positives because it cannot see runtime context.
- DAST — dynamic testing against the running application. Finds what is actually exploitable; needs a deployed instance and cannot point at the offending line.
- IAST — instruments the running application from inside, combining both views.
- Fuzzing — throwing malformed and unexpected input at an application to find crashes and unhandled conditions.
- Reverse engineering — analysing a binary you have no source for, to understand what it does.
- SCA — software composition analysis, inventorying third-party components and their known vulnerabilities. This is how you answer "are we affected" when a library CVE breaks on a Friday.
Check yourself
A development team wants vulnerabilities caught before code is deployed, as part of the build pipeline. Which technique fits?