Vulnerability Scanning — Glossary

The practice of systematically examining systems, networks, and applications to identify security weaknesses that could be exploited by an attacker. A vulnerability scan does not perform an attack — it checks for the potential for an attack to exist. It may detect an open port, an unpatched service version, or a misconfigured setting, but it does not exploit any of those conditions. This makes vulnerability scanning minimally invasive: production systems can typically be scanned without disruption. Vulnerability scanning answers the question "where are the weaknesses?" Exploitation is left to intentional penetration testing.

An authorized security assessment that actively attempts to exploit identified vulnerabilities to confirm whether they are real and assess how far an attacker could progress. Unlike vulnerability scanning, penetration testing is intentionally invasive — it can crash services, modify data, trigger alerts, and cause operational disruption if not carefully scoped and coordinated. Pen testing answers "are these weaknesses actually exploitable, and what is the impact?" The distinction the Security+ exam tests directly: vulnerability scanning = reconnaissance and identification; penetration testing = active attack simulation. Both are valuable but answer different questions and carry different risk profiles.

The simplest form of vulnerability scanning: probing a system to discover which TCP and UDP ports are open and which services are listening on them. An open port is not inherently a vulnerability, but it represents attack surface — every listening service is a potential entry point. Port scanning answers "what doors exist?" More comprehensive vulnerability scanning then asks "which of those doors have broken locks?" Port scans also reveal service software and version numbers, enabling the scanner to match running services against known-vulnerable version databases (CVE databases). Nmap is the canonical port scanning tool referenced in most security curricula.

The sum of all points where an attacker can attempt to enter or extract data from a system or network. Every open port, running service, network-facing interface, user account, and publicly accessible application contributes to the attack surface. Vulnerability management's foundational goal is to reduce and monitor the attack surface. A port scan maps the attack surface; a vulnerability scan assesses which parts of that surface are exploitable. Shadow IT — devices and services deployed without IT approval — expands the attack surface invisibly, which is why internal scanning and asset inventory are interdependent security controls.

A vulnerability scan performed from outside the organization's network perimeter, simulating what an attacker on the internet sees. An external scan targets systems that are reachable from the internet: web servers, VPN gateways, email servers, DNS servers, public APIs, and any other internet-facing service. External scans reveal the organization's attack surface from the outside perspective — what is visible, what is reachable, and what services are exposed to the public internet. External scanning is the most commonly associated form of vulnerability scanning. It is necessary but not sufficient on its own.

A vulnerability scan performed from inside the network perimeter. Internal scans identify devices not accessible from the internet but visible to anyone already on the network: workstations, printers, internal servers, databases, network infrastructure, and any unauthorized or shadow IT devices. Internal scanning addresses threats that external scanning cannot see: insider attacks, compromised credentials used for lateral movement, and vulnerabilities that only exist in the internal network segment. The outdated assumption that "we already checked the perimeter, so internal scanning is optional" fails to account for the reality that attackers routinely compromise the perimeter first and then move laterally.

A vulnerability scanner finding that investigation reveals is not actually a real or exploitable vulnerability. Scanners use pattern matching and version-number comparisons to identify potential weaknesses. A false positive occurs when the scanner flags something that resembles a vulnerability but is actually safe in context — for example, the service version matches a known-vulnerable version but the vulnerable code path has been separately patched, or the configuration resembles a risk pattern but is not exploitable in this environment. False positives are common in vulnerability management. The required response: verify each finding against the actual system before taking action. Acting on a false positive (patching something that isn't vulnerable) can cause operational disruption with no security benefit.

A technique that examines source code, bytecode, or compiled binary to detect patterns associated with known vulnerability classes — without executing the application. SAST identifies issues like calls to buffer-unsafe functions, SQL string concatenation, hardcoded credentials, and deprecated cryptographic algorithm usage. The security value is timing: vulnerabilities found during development cost a fraction of vulnerabilities found post-deployment. SAST integrated into CI/CD pipelines scans every code commit automatically. Limitations: SAST finds code patterns, not logic errors. It cannot detect authentication design flaws, insecure cryptographic implementations where the algorithm is correct but usage is wrong, race conditions, or business logic vulnerabilities. False positives are common and require human judgment before remediation.

A dynamic testing technique that examines running applications by generating large volumes of malformed, random, or boundary-value input and submitting it to the application, then monitoring for anomalous responses: crashes, unhandled exceptions, unexpected server errors, or memory corruption indicators. Any anomalous response reveals a gap in input handling that an attacker could seek to trigger and control. Fuzzing is inherently dynamic — the application must be running. It complements SAST (which requires no execution) by finding vulnerabilities that only manifest at runtime. Attackers use fuzzing offensively to discover exploitable weaknesses; security teams use it defensively during development and security assessments.

The Security+ exam uses several terms to describe the same core fuzzing technique: submitting unexpected, malformed, or boundary-value input to an application and observing behavior. Know all four synonyms: Fault injection — deliberately injecting invalid data to cause faults; Robustness testing — testing how the application handles adversarial conditions; Negative testing — testing with inputs outside the expected range (contrast with positive testing, which uses valid inputs); Syntax testing — submitting inputs that violate the expected format or protocol structure. All four terms refer to the same technique as fuzzing. On the exam, if a question describes submitting malformed input to find crashes or errors, the answer is fuzzing regardless of which synonym appears in the answer choices.

A structured fuzzing environment developed by Carnegie Mellon University's Computer Emergency Response Team (CERT/CC) that provides organizations with an accessible, systematic approach to fuzzing their own applications. The BFF automates the process of generating mutated inputs, submitting them to target applications, monitoring for crashes, and organizing crash results for analysis. It lowers the expertise threshold required to apply fuzzing to custom software. Fuzzing in general is computationally intensive — finding a vulnerability may require thousands or millions of input iterations. The 1988 original "Fuzz Generator" project at the University of Wisconsin under Professor Barton Miller established fuzzing as a methodology; the CERT BFF represents its modern institutionalization for defensive use.

The continuous practice of tracking all third-party libraries, packages, and open-source dependencies installed in an organization's applications, and comparing them against known-vulnerability databases (CVE databases) and vendor security advisories. When a new CVE is published for a library version currently in production, the monitoring system alerts the security and development teams. The goal is to eliminate the gap between "vulnerability publicly disclosed" and "organization aware of it" — this gap is the window during which the organization is exposed without knowing. Tools implementing this include OWASP Dependency-Check, GitHub Dependabot, and Snyk. Package monitoring addresses the supply chain risk dimension of vulnerability management: vulnerabilities in dependencies are real vulnerabilities in the applications that use them.

The security risk introduced by the third-party libraries, frameworks, packages, and open-source components that modern applications depend on. Supply chain risk has two dimensions: (1) Known vulnerabilities in dependencies — a CVE is published for a library included in production, but the team is not aware and does not update; (2) Malicious packages — an attacker publishes a package with a name similar to a legitimate one (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 payload. Supply chain attacks are particularly dangerous because they subvert trusted channels. Mitigations: digital signatures, hash validation, repository authentication, package monitoring, and isolated lab testing before production deployment.