What Vulnerability Scanning Is — and What It Is Not
Vulnerability scanning is the practice of systematically examining systems, networks, and applications to identify security weaknesses that could be exploited by an attacker. The critical distinction that the Security+ exam tests directly: a vulnerability scan does not perform an attack. It checks for the potential for an attack to exist. It identifies that a port is open, that a service is running an unpatched version, that a configuration is insecure — but it does not exploit any of those conditions. This makes vulnerability scanning minimally invasive. Production systems can typically be scanned without disruption.
A penetration test, by contrast, actively attempts to exploit identified vulnerabilities to confirm they are real and assess how far an attacker could go. Pen testing is intentionally invasive — it can crash services, modify data, and cause operational disruption if not carefully scoped. Vulnerability scanning is reconnaissance; penetration testing is the attack simulation. Both are valuable, but they answer different questions and carry different risk profiles.
Port Scanning and System Identification — The Foundation of Vulnerability Assessment
The simplest form of vulnerability scanning is the port scan: probing a system to discover which TCP and UDP ports are open and what services are listening on them. An open port is not inherently a vulnerability, but it represents an attack surface. Every open port is a potential entry point — if the service running on that port has an unpatched vulnerability, is misconfigured, or accepts unauthenticated access, an attacker can leverage it. A port scan answers: "What doors exist?" More comprehensive vulnerability scanning then asks: "Which of those doors have broken locks?"
Beyond ports, vulnerability scanners identify the systems themselves: operating system type and version, network device types (routers, switches, firewalls, load balancers), service software and version numbers, security appliances, and any other detectable device. This information is essential for patch management — you cannot patch what you haven't identified. It also validates the asset inventory: devices that appear in a scan but are absent from the asset tracking system are shadow IT or unauthorized devices that require immediate investigation.
Internal and External Scanning — Two Perspectives on the Same Network
Effective vulnerability management requires scanning from both perspectives. An external scan simulates what an attacker on the internet sees: it probes systems that are reachable from outside the organization's perimeter (internet-facing web servers, VPN gateways, email servers, publicly accessible APIs). External scans reveal the organization's attack surface as an outsider would experience it — what is visible, what is reachable, what services are exposed. This is the perspective most commonly associated with vulnerability scanning, and it is essential.
But it is not sufficient. An internal scan is performed from inside the network perimeter and reveals a completely different picture. Internal scans identify: devices that are not accessible from the internet but are visible to anyone already on the internal network (workstations, printers, internal servers, databases); unauthorized devices that were connected without going through procurement and asset tracking; vulnerabilities that would only be accessible to an insider or an attacker who has already breached the perimeter. Treating internal scanning as optional reflects the outdated assumption that the perimeter is reliably secure — insider threats, compromised credentials, and lateral movement after an initial breach all operate from inside the network. Internal scanning addresses the threat model that the perimeter has already been crossed.
Managing Scan Output — False Positives and Severity Triage
Vulnerability scanners generate large amounts of data. A scan of a moderately complex network may produce hundreds of findings across dozens of systems, classified by severity: critical, high, medium, low, and informational. Not all of these findings represent real, exploitable vulnerabilities. False positives are findings that the scanner flags as vulnerabilities based on pattern matching, but which investigation reveals to be safe — perhaps the service version number matches a known-vulnerable version but the vulnerable code path has been separately patched, or the scanner detected a configuration that resembles a vulnerability but is not exploitable in context.
The required workflow after receiving scan output is: review each finding, verify it against the actual system, classify it as real or false positive, then prioritize the real findings by severity and exploitability for remediation. Critical and high-severity findings affecting internet-facing systems, authentication mechanisms, or data stores receive immediate attention. Medium and low findings are addressed through scheduled maintenance cycles. The scan is not the end of the vulnerability management process — it is the beginning. Acting on unverified scan findings (patching based on a false positive, for example) can cause operational disruption without any security benefit. Acting without prioritizing (trying to fix all findings simultaneously) is operationally infeasible. Triage is the skill.
Static Application Security Testing (SAST) — Finding Vulnerabilities in Code Before Execution
Network vulnerability scanning identifies weaknesses in deployed systems. Static Application Security Testing (SAST) identifies weaknesses in application source code — before the application is ever deployed or even run. A SAST tool examines source code, bytecode, or binary to detect patterns associated with known vulnerability classes: calls to buffer-unsafe functions, string concatenation in database queries, hardcoded credentials, use of deprecated cryptographic algorithms, improper input handling patterns.
The value proposition of SAST in vulnerability management is timing. Vulnerabilities found during development cost a fraction of what they cost to remediate post-deployment. A developer who receives SAST feedback immediately after writing a vulnerable function can fix it in minutes. The same vulnerability discovered after deployment, through a production incident or external research, requires a security response, customer notification, emergency patching, and potentially regulatory reporting. SAST integrated into CI/CD pipelines provides this early-warning capability automatically, scanning every code commit for regressions.
SAST has documented limitations that are important for the exam. It identifies code patterns — it cannot evaluate whether the logic of the code is secure. Authentication design flaws (session token predictability, race conditions in authentication flows), insecure cryptographic implementations (correct algorithm but wrong mode, improper key management), and business logic vulnerabilities are typically invisible to static analysis. False positives are common — SAST flags code that resembles a vulnerable pattern but is actually safe in context. Every SAST finding requires human judgment before action is taken.
Dynamic Analysis — Fuzzing Running Applications
Where SAST examines static code, fuzzing examines running applications by observing how they respond to unexpected input. A fuzzer generates large volumes of malformed, random, or boundary-value input and submits it to the application, monitoring for anomalous responses: crashes, unhandled exceptions, unexpected server errors, memory corruption indicators, or any behavior that deviates from the expected output.
The significance of an anomalous response is that it reveals a gap in the application's input handling. If submitting a 10,000-character string to a field that expects 20 characters causes the application to crash, the developer has found a potential buffer overflow — the same crash that an attacker would seek to trigger and control. Fuzzing explores the edge cases that manual testing never reaches: the combinations of inputs that no developer thought to test, the encoding variants that bypass validation, the boundary values that trigger off-by-one errors. Attackers use fuzzing offensively; security teams use it defensively during development and assessment.
Fuzzing is known by several equivalent terms on the exam: fault injection, robustness testing, negative testing, and syntax testing all describe the same core technique of submitting unexpected input to observe behavior. Fuzzing is inherently a dynamic technique — the application must be running. It complements SAST (which does not require execution) by finding vulnerabilities that only manifest at runtime.
Fuzzing History and Frameworks
The history of fuzzing is worth knowing for the exam: the first formal fuzzer was created in 1988 as a class project at the University of Wisconsin in a course titled "Operating System Utility Program Reliability," led by Professor Barton Miller. The project — called the Fuzz Generator — demonstrated that random input could reliably expose reliability and security flaws in UNIX utilities. This foundational research established fuzzing as a methodology that is now foundational to both security research and software testing.
Modern fuzzing has evolved far beyond the original random-input model. Platform-specific fuzzers target particular operating systems. Language-specific fuzzers are optimized for Python, JavaScript, Go, or other languages. Protocol-aware fuzzers understand the structure of specific protocols (HTTP, DNS, TLS) and generate technically valid but semantically invalid inputs that simple random generators would never produce. Coverage-guided fuzzers (like AFL and libFuzzer) use code coverage feedback to prioritize inputs that explore new code paths, dramatically improving efficiency.
Fuzzing is computationally intensive — it may require thousands or millions of input iterations to find a vulnerability. The CERT Basic Fuzzing Framework (BFF), developed by Carnegie Mellon University's Computer Emergency Response Team, provides a structured, accessible fuzzing environment for organizations that want to apply fuzzing to their own applications systematically.
The Software Supply Chain Risk
Modern applications are not built entirely from first-party code. They depend on libraries, frameworks, packages, and open-source components maintained by third parties — often dozens or hundreds of them in a single application. These dependencies accelerate development but introduce a supply chain risk: a vulnerability or malicious modification in any dependency propagates to every application that uses it.
The risk has two dimensions. First, known vulnerabilities in dependencies: a library that is included in production has a CVE published against it, but the development team is not aware of the CVE and the dependency is not updated. The application remains exposed indefinitely. Second, malicious packages: an attacker publishes a package with a name similar to a popular legitimate package (typosquatting), or compromises a legitimate package repository to inject malicious code into a trusted package. Any application that installs the compromised package also installs the attacker's code.
Package Verification and Integrity Checking
Before any software package is deployed, its integrity and provenance should be verified. This applies to commercial software, open-source libraries, and internally developed packages. The verification process answers the same questions that code signing addresses for applications: is this package from the expected source, and has it been modified since the maintainer published it?
Digital signatures allow package maintainers to sign releases; consumers verify the signature using the maintainer's public key before installation. If the signature is invalid or missing, the package has been modified or did not come from the expected source. Hash validation (comparing the SHA-256 hash of the downloaded file against the hash published by the maintainer) confirms file integrity — any modification changes the hash. Repository authentication ensures the download came from the official repository rather than a mirror, fork, or third-party host. For packages of uncertain origin, testing in an isolated lab environment before production deployment adds a final verification layer.
Continuous Monitoring for Vulnerable Dependencies
Verification at installation time is necessary but not sufficient. A package that is clean today may have a CVE published against it tomorrow. Without continuous monitoring, the organization will not know about the new vulnerability until a security researcher, a vulnerability scan, or — in the worst case — an attacker discovers it first.
Package monitoring solutions continuously track all installed dependencies against CVE databases and vendor security advisories. When a CVE is published for a library version that is installed in the organization's applications, the monitoring system generates an alert. The security and development teams can then assess severity, determine whether the vulnerability is exploitable in their deployment context, and schedule or immediately deploy an update. Tools like OWASP Dependency-Check, Dependabot (GitHub), Snyk, and similar solutions implement this monitoring automatically as part of the development pipeline. The goal is to eliminate the gap between "vulnerability disclosed" and "organization aware" — that gap is the window during which the organization is exposed without knowing it.