Vulnerability Scanning -- Tricks

Trick 1 Scanning Identifies; Pen Testing Exploits — The Exam Never Confuses These

The Security+ exam treats the scanning/pen-testing distinction as a core competency. Questions will describe a scenario and ask which activity is being performed, or ask which is appropriate for a given risk tolerance. The distinguishing word is always exploit.

Vulnerability scanning: identifies, detects, discovers, reports potential weaknesses. No exploitation. Minimally invasive. Production-safe. Answers: "where might we be vulnerable?"
Penetration testing: attempts, exploits, simulates, demonstrates actual attack. Intentionally invasive. Can crash services. Answers: "are these vulnerabilities real and what is the attacker's reach?"

If the scenario says someone is "probing systems to identify open ports and unpatched software" — that is scanning. If it says someone is "attempting to gain unauthorized access by exploiting a known vulnerability" — that is a pen test. The activity type determines the correct answer regardless of what tools are mentioned.

Mnemonic: Scan = See. Pen = Pierce. Scanning sees weaknesses; penetration testing pierces through them.

Trick 2 False Positives Are Expected — Verify Before You Act

The exam tests false positives in two ways: (1) recognizing that a described situation is a false positive, and (2) knowing the correct response. Both have a single right answer.

How to recognize a false positive on the exam: The scenario will say the scanner flagged a finding AND investigation revealed the system is not actually vulnerable — often because a patch was backported, a compensating control exists, or the configuration only resembles a vulnerable pattern without being exploitable.

The correct response to a false positive is always: Document the verification findings, classify the finding as a false positive, and remove it from the active remediation queue. No system change is needed.

Wrong answers that appear on the exam:

"Patch it anyway" — wrong; no vulnerability exists to fix; patching causes operational risk with zero security benefit
"The scanner is broken" — wrong; false positives are an expected output of pattern-matching scanners, not a defect
"Escalate to pen test to confirm" — wrong in most contexts; if investigation already confirmed it is safe, no pen test is needed

Rule: Verify first, then act. Never act on an unverified scanner finding.

Trick 3 Internal Scanning Is NOT Optional — Reject the Perimeter-Only Fallacy

The exam frequently includes distractors that suggest external scanning alone is sufficient. This is always wrong. The specific threat model that internal scanning addresses is the insider and post-breach attacker — threats that have already crossed the perimeter or were never stopped by it.

What external scans find: Internet-facing services, open ports on public IPs, exposed APIs, public server versions.

What external scans cannot find: Unauthorized devices on internal segments, workstations with unpatched OS, printers and IoT devices, databases that are internal-only, rogue access points, shadow IT devices, lateral movement paths.

Trigger for internal scanning on the exam: Any question about finding unauthorized devices, shadow IT, insider threats, devices not in asset inventory, or an attacker who has "already breached the perimeter" requires internal scanning as part of the answer.

The dismissal phrase to reject: "We have a firewall, so internal scanning is unnecessary" is always a wrong answer on Security+. Firewalls protect the perimeter; internal scanning addresses what is already inside.

Rule: One scan perspective = incomplete. External sees the front door; internal sees what is already inside.

Trick 4 SAST = Static (No Execution) vs. Fuzzing = Dynamic (Running App) — They Complement Each Other

Two exam-tested distinctions in application security testing:

SAST: Static — analyzes source code, bytecode, or binary without executing the program. Can run before the application is even compiled. Finds code-pattern vulnerabilities (buffer-unsafe functions, SQL concatenation, hardcoded credentials, deprecated algorithms). Cannot find runtime-only behavior, authentication design flaws, business logic errors, or crypto implementation mistakes where the algorithm is correct but used improperly.

Fuzzing: Dynamic — requires the application to be running. Submits malformed input and monitors for anomalous responses (crash, unhandled exception, 500 error, timeout). Finds runtime vulnerabilities that static analysis cannot see. All four synonyms (fault injection, robustness testing, negative testing, syntax testing) refer to this same dynamic technique.

The complementarity: SAST catches design-time code patterns; fuzzing catches runtime-behavior issues. Neither replaces the other. A question that asks which technique "requires the application to be running" always has fuzzing as the answer. A question that asks which technique "does not require execution" always has SAST as the answer.

Fuzzing history fact for the exam: 1988 → University of Wisconsin → Professor Barton Miller → "Fuzz Generator" project. Modern tool: CERT Basic Fuzzing Framework (BFF) from Carnegie Mellon.

Mnemonic: S-AST = Static. Fuzzing = Flying inputs at a running app.

Practice Scenarios

Scenario A: A company discovers that an attacker compromised a developer's laptop and used it to access internal systems for two weeks. The external vulnerability scans performed during that period showed no findings. The security team is asked to improve their scanning program to detect such threats earlier. Which scanning addition addresses this gap?

Answer: Internal vulnerability scanning. The attacker was operating from inside the network (compromised laptop), which is invisible to external scans that only cover internet-facing systems. Internal scans would have detected the compromised device's anomalous network presence and any unauthorized services it was running. External scans showing no findings is expected — the threat was internal. The gap is not in the external scan quality; it is in the absence of internal scanning.

Scenario B: A security engineer runs a vulnerability scan and receives 340 findings. She prioritizes the 12 Critical and 28 High findings for immediate review. Of those 40, she verifies 31 against actual systems and confirms they are real vulnerabilities. The remaining 9 are determined to be false positives after investigation. What is the correct treatment for the 9 false positives?

Answer: Document each as a verified false positive with the specific reason (e.g., backported patch applied, compensating control in place, code path unreachable), and remove them from the active remediation queue. No system changes are required for these 9 findings. The engineer should retain the documentation for audit purposes — if the same findings appear in the next scan, the prior verification record allows rapid disposition. Acting on them (patching, changing configurations) would cause operational disruption with no security benefit.

Scenario C: An application security team uses SAST in their CI/CD pipeline and fuzzing in their pre-release testing phase. A security question asks: which technique would more likely find a buffer overflow caused by a specific combination of inputs at runtime, versus a hardcoded API key left in the source code by a developer? Which technique finds which?

Answer: SAST finds the hardcoded API key — it is a code pattern in the source file, detectable by static analysis without executing the program. Fuzzing finds the buffer overflow caused by a specific runtime input combination — this vulnerability only manifests when the running application receives the specific input pattern that exceeds the buffer boundary; static analysis of the code may not reveal the vulnerable path without execution context. This is the core SAST/fuzzing complementarity: SAST finds what is wrong in the code as written; fuzzing finds what breaks when the code runs under adversarial conditions.

Vulnerability Scanning — Exam Tricks