CompTIA CySA+ Domain 2: Vulnerability Management

CVSS v3.1 maps base scores of 9.0–10.0 to the Critical qualitative rating, and 9.6 falls squarely within that Critical band.

• AIn CVSS v3.1 the Medium band is 4.0–6.9; a 9.6 base score is far above that range and would never be rated Medium.
• BThe High band in CVSS v3.1 is 7.0–8.9; a 9.6 exceeds 8.9, so it crosses into the next, more severe rating rather than High.
• DThe None rating is reserved for a base score of 0.0; a 9.6 indicates a severe, exploitable vulnerability, not the absence of impact.

The CVE program catalogs publicly disclosed vulnerabilities and assigns each one a unique CVE ID so tools and teams can reference the same issue consistently.

• ACVSS produces a numeric severity score for a vulnerability; it rates how severe an issue is but does not assign the unique identifier that names the vulnerability.
• CCWE enumerates categories of software weakness types (e.g., buffer overflow); it classifies the kind of flaw, not a specific disclosed vulnerability instance.
• DCPE is a structured naming scheme for IT products and platforms; it identifies affected products, not the individual vulnerability identifier.

Both the NVD and the CVSS specification state that CVSS is owned and managed by FIRST.Org, Inc., the non-profit that publishes and updates the specification.

• AMITRE maintains CVE and ATT&CK, not CVSS; conflating the CVE list operator with the scoring system's owner is a frequent CySA+ trap.
• BNIST's NVD applies CVSS and publishes scores for CVE records, but it does not own the standard and explicitly attributes ownership to another body.
• DISO/IEC publishes many security standards but not CVSS; the Common Vulnerability Scoring System is governed by a different, incident-response-focused organization.

A credentialed scan authenticates with valid credentials to inspect installed software, patch levels, and configuration directly on the host, producing deeper and more accurate results.

• AA non-credentialed scan runs without login credentials and only enumerates exposed ports and services, so it cannot read local registry keys or patch state.
• CPassively capturing copied traffic observes packets on the wire and never logs in to a host, so it cannot enumerate local patch levels or registry entries.
• DAn external perimeter scan probes internet-facing addresses from outside and has no host login, so it cannot read the internal host configuration described here.

Passive testing identifies systems and weaknesses without any direct interaction with the targets, relying solely on observing existing network traffic as described in the scenario.

• AActive testing directly interacts with targets by sending packets or probes to them, which is exactly the interaction this traffic-only tool deliberately avoids.
• BA credentialed scan logs in to hosts with valid accounts to read local data, yet this tool only reads mirrored traffic and authenticates to nothing.
• DDAST sends crafted requests to a running web application to elicit responses, which is direct interaction, unlike the purely observational monitoring of mirrored traffic here.

An external scan assesses internet-accessible assets from outside the perimeter, revealing how systems and infrastructure appear to potential attackers on the public internet, matching the goal.

• BAn internal scan runs from inside the trusted network to find flaws reachable by insiders, not the outside-attacker perspective the team requested in this scenario.
• CA credentialed audit logs in to inspect local settings and patch state, which is deep host inspection rather than the outside-in perimeter assessment described here.
• DStatic code analysis inspects application source for flaws before runtime and has nothing to do with scanning live internet-facing hosts from outside the firewall.

SAST analyzes source or compiled code without running it, highlighting flaws such as injection and overflows by file, location, and line number as described.

• ADAST scans a running application from the outside by sending requests, so it requires execution and cannot point to a specific source-code line number.
• BIAST instruments a running application with sensors to observe execution, so it also needs the application running rather than parsing static source code only.
• CSCA inventories third-party and open-source dependencies for known vulnerable components, not first-party source-code patterns such as injection or buffer-overflow flaws.

IAST uses sensor modules inside the running application to track behavior and data flow while tests exercise it, reporting issues with precise code-level context.

• ASAST examines source code in a non-runtime environment and cannot observe live data flow during execution, unlike the in-application runtime sensors described here.
• CDAST probes the application from the outside as a black box and lacks visibility into the internal code paths and data flow these embedded sensors provide.
• DA non-credentialed network scan enumerates exposed ports and services across hosts and does not instrument application code or trace internal application data flow.

SCA identifies third-party and open-source components and checks them for known disclosed vulnerabilities, exactly the dependency-inventory matching described in this scenario.

• ASAST inspects first-party source code for insecure patterns and is not designed to inventory bundled third-party libraries against a known-vulnerability database.
• BFuzzing feeds malformed inputs to a running program to trigger crashes, which does not enumerate dependency versions or match them to published vulnerability records.
• DA credentialed host scan checks operating-system patch state and configuration, not the open-source libraries embedded inside an individual application build artifact.

Fuzzing automatically supplies unexpected, malformed, or semi-malformed inputs to a program to surface bugs, crashes, and unexpected behavior, exactly as this scenario describes.

• BSCA examines third-party and open-source dependencies for known vulnerable versions and does not generate malformed inputs to crash a running parser application.
• CPassive testing only observes existing traffic without interacting with targets, whereas fuzzing actively injects crafted, malformed inputs into the application under test.
• DA credentialed scan logs in to enumerate patches and configuration and does not bombard an application's inputs with malformed data to trigger faults.

The Base metric group represents the intrinsic characteristics of a vulnerability that are constant over time and across user environments, exactly matching the description given.

• AEnvironmental metrics capture traits unique to a particular user's environment, such as mitigations present, not the intrinsic constant qualities the analyst described here.
• BTemporal metrics reflect traits that change over time, like exploit code maturity or patch availability, whereas the stem describes qualities constant over time.
• DThreat is a CVSS v4.0 metric group reflecting exploitation activity over time; CVSS v3.1 uses Base, Temporal, and Environmental, and Base holds the constant traits.

Network means the component is bound to the network stack and attackers can reach it remotely, up to the entire Internet, often termed remotely exploitable.

• BPhysical requires the attacker to physically touch or manipulate the vulnerable component, which contradicts a flaw reachable remotely across the Internet at the protocol level.
• CLocal applies when the component is not bound to the network stack and the path is via local access or user interaction, unlike this remote case.
• DAdjacent limits the attack to a logically adjacent topology like a shared LAN or VPN; here exploitation crosses the wider network, so Network applies instead.

EPSS is a data-driven model that estimates the probability a published CVE will be exploited in the wild in the next 30 days, scored 0 to 1.

• AThe CVSS Base Score rates intrinsic technical severity on a 0 to 10 scale; it does not estimate the near-term probability that a vulnerability will be exploited.
• BA CWE entry categorizes the type of weakness behind a flaw; it provides no probability estimate of exploitation activity within any future time window.
• CThe KEV catalog confirms exploitation that has already been observed; it is a record of active exploitation, not a forward-looking probability prediction model.

CISA maintains the KEV catalog as the authoritative source of vulnerabilities exploited in the wild, used as an input to vulnerability management prioritization regardless of CVSS.

• AEPSS predicts future exploitation likelihood probabilistically; the catalog described records vulnerabilities with confirmed evidence of active exploitation, which is a different, confirmation-based source.
• CNVD CVSS enrichment provides Base severity scores reflecting intrinsic characteristics; it is not a catalog of confirmed active exploitation maintained by CISA for prioritization overrides.
• DThe CWE Top 25 ranks dangerous weakness classes generally; it does not list specific CVEs with confirmed in-the-wild exploitation as the KEV catalog does.

NIST SP 800-40 defines enterprise patch management as identifying, prioritizing, acquiring, installing, and verifying the installation of patches, updates, and upgrades throughout an organization.

• ARisk acceptance is a governance decision to tolerate residual risk; it does not describe the operational process of acquiring, installing, and verifying patches across systems.
• BConfiguration baselining documents an approved specification for a system; it is not the recurring process of obtaining, deploying, and confirming software patches and updates.
• DPenetration testing simulates attacks to discover weaknesses; it neither acquires nor installs patches, so it does not match the remediation process described here.

A compensating control is employed in lieu of a recommended control in the baselines and provides equivalent or comparable protection for the information system.

• BRisk avoidance removes the activity or asset to eliminate exposure; here the database stays in service with substitute safeguards, which defines a compensating control instead.
• CA configuration baseline is an approved, change-controlled set of specifications; it is not a substitute safeguard standing in for a recommended security control.
• DA zero-day mitigation addresses a flaw lacking a patch; the scenario describes substituting for a recommended control due to a legacy constraint, not an unpatched zero-day.

NIST SP 800-128 defines a baseline configuration as a formally reviewed and agreed specification set, changeable only through change control and used as a basis for future builds.

• AA service-level agreement sets contractual performance or remediation timeframes; it is not a reviewed, change-controlled specification set used as the basis for system builds.
• BA compensating control substitutes for a recommended control to give comparable protection; it is not an approved baseline of system specifications under change control.
• CRisk acceptance documents tolerating residual risk; it does not describe a formally agreed, change-controlled specification set that future builds and releases are based on.

CWE-89 occurs when externally influenced input builds a SQL command without neutralizing special elements, letting that input modify the intended query logic exactly as the injected OR clause does here.

• AXSS involves unneutralized input placed into a web page served to other users; here the tampered input alters a backend database query, not page output, so this label misclassifies the flaw.
• CInsecure deserialization concerns rebuilding untrusted serialized objects into program state; no object stream is processed here, only a string concatenated into a query, so the underlying cause differs.
• DSSRF is the server retrieving an attacker-controlled URL; this routine issues no outbound request and instead mishandles input inside a database query, so the classification does not fit.

CWE-79 stored XSS occurs when an application saves dangerous data in a data store and later includes it in dynamic content served to other users, matching the persisted comment described here.

• ACSRF forces a state-changing request the user did not intend; here injected script executes in visitors' browsers, which is cross-site scripting rather than a forged request to the server.
• BReflected XSS reads data from the current HTTP request and returns it in the same response; this payload is persisted in storage first, so the reflected classification does not apply.
• DDOM-based XSS injects the payload entirely client-side by manipulating the Document Object Model; here the server stores and re-serves the script, so it is the stored server-side variant.

CWE-352 arises when a web application cannot sufficiently verify whether a request was intentionally provided by the user, letting a forged authenticated action execute, exactly as the auto-submitting form does.

• BReflected XSS requires the server to echo injected script into its response; here no script is reflected, only a forged state-changing request rides the victim's existing authenticated session.
• CInsecure deserialization needs an untrusted serialized object to be reconstructed; this attack submits ordinary form fields with the victim's cookie, so deserialization is not the underlying weakness here.
• DSSRF coerces the server into fetching an attacker-supplied URL; here the victim's own browser sends the forged request to the bank, so the server is not the confused requester.

CWE-918 occurs when a server retrieves a URL from input but does not ensure the request goes to the expected destination, letting the tester reach the internal metadata endpoint shown here.

• AStored XSS requires persisting attacker script that later executes in users' browsers; here the server itself is tricked into fetching an internal address, so page output is not the issue.
• BCSRF abuses the victim's browser and session to forge a request; in this case the server, not a victim browser, is coerced into making the unexpected request to the metadata endpoint.
• CInsecure deserialization depends on reconstructing an untrusted serialized object; the flaw here is the server retrieving an attacker-chosen URL, independent of how the response is later parsed.

CWE-502 occurs when a product deserializes untrusted data without sufficiently ensuring the result is valid, allowing crafted object graphs and gadget chains to execute code as described here.

• ASQL injection needs untrusted input merged into a SQL statement; here the danger is reconstructing an attacker-built object stream, with no database query involved in the exploit path.
• CXSS executes script in a browser from unneutralized page output; this exploit runs server-side during object reconstruction, so reflecting content to a browser is not what happens here.
• DSSRF coerces the server into requesting an attacker-chosen URL; the researcher instead supplies a malicious serialized object, so no outbound fetch defines this vulnerability at all.

CPE is the SCAP specification providing a standard naming convention for operating systems, hardware, and applications so multiple parties and solutions can refer to the same platform type.

• AXCCDF is the SCAP language for authoring checklists and reporting checklist results, not the naming convention that identifies which operating system or application a particular finding concerns.
• BOVAL specifies low-level procedures to test system state and report results; it performs assessment rather than supplying the consistent product names used to correlate findings across tools.
• DCCE assigns unique identifiers to security configuration settings, not to the platforms themselves, so it cannot serve as the naming convention for operating systems and applications here.

NIST defines a false positive as an alert that incorrectly indicates a vulnerability is present; the scanner flagged a patch gap that manual review proved does not actually exist.

• BA false negative is the tool failing to detect a real vulnerability; here the scanner reported an issue that does not exist, which is the opposite of a missed detection.
• CA true positive would mean the reported vulnerability genuinely exists; manual validation showed the patch is installed, so the finding is not a correct detection of a real flaw.
• DA compensating control is an alternative safeguard, not a description of scanner accuracy; the question concerns whether the reported vulnerability is real, which is a detection-quality issue.

Prepared statements with variable binding force the developer to define SQL code first and pass parameters later, so the database always distinguishes code from data regardless of input.

• AOWASP labels manual escaping of all user input strongly discouraged and fragile because it cannot guarantee prevention of SQL injection in every situation across databases.
• CDenylisting known bad keywords is trivially bypassed and blocks legitimate input, so it is an unreliable defense compared with structurally separating code from data through parameterization.
• DCredential hygiene does nothing to stop injected SQL from being interpreted as code, because the flaw is in how the query is constructed, not the password.

OWASP and CWE-79 state proper output encoding, escaping, and quoting is the most effective solution for preventing cross-site scripting by rendering input as data, not executable code.

• AHttpOnly only reduces the damage of a stolen session cookie and is defense in depth; it does not stop the injected script from executing in the page.
• BOWASP warns a CSP is easy to misconfigure and should not be your primary defense mechanism, but rather an additional layer of defense on top of encoding.
• DLength limits do not neutralize markup and short payloads still execute, so restricting field size fails to address how untrusted data is rendered into the page.

The synchronizer token pattern is a recommended CSRF defense because, without the secret unpredictable token, an attacker cannot craft a valid forged request that the backend will accept.

• BBrowsers already auto-attach session cookies on forged cross-site requests, so re-presenting cached credentials still cannot distinguish a genuine action from an attacker-driven one.
• CUsing GET for state changes increases CSRF exposure and can leak tokens through history and logs, which is the opposite of the recommended guidance.
• DStronger cookie encryption does not prove user intent; the browser still transmits the cookie automatically on a forged request, so the server cannot tell the requests apart.

Allowlist validation defines exactly what is authorized so everything else is rejected, and for a fixed option set the input must match one offered value, validated server-side.

• AOWASP states input validation should not be the primary method of preventing SQL injection or XSS; it reduces impact but the primary fixes are parameterization and output encoding.
• BDenylisting dangerous characters is easily bypassed and frequently blocks legitimate input like O'Brian, so it should supplement rather than replace allowlist validation.
• CClient-side checks can be disabled or bypassed with a proxy, so validation must run server-side before the data is processed by the application.

CWE notes an application firewall helps when code cannot be fixed because it is third-party, as an emergency measure or defense in depth, reducing exploitation without removing the underlying weakness.

• ADoing nothing on a confirmed, exploitable internet-facing flaw leaves the organization exposed for weeks when a recognized stopgap control exists to lower the likelihood of exploitation.
• CA firewall is a mitigating control that lowers exploitation likelihood; it does not correct the vulnerable code, so calling it remediation misrepresents that the root-cause flaw remains.
• DInsurance shares financial consequences after a loss but does not reduce the technical likelihood of the SQL injection being exploited, so it is not an interim technical safeguard here.

Network segmentation isolates the vulnerable asset behind managed boundaries, reducing its attack surface and serving as a recognized compensating control when patching is not possible.

• ALeaving the unpatchable device on the flat network adds no safeguard and keeps its attack surface fully exposed, which does not meet the requirement to limit exploitation.
• BScanning more frequently re-discovers the known flaw but does nothing to reduce the device's exposure or the likelihood that the unpatched weakness is exploited.
• DA stronger admin password may slow credential guessing but does not contain network-borne exploitation of the unpatched software, so it does not limit the device's overall attack surface.

NIST's SSDF integrates secure development practices into each SDLC phase to reduce vulnerabilities in released software and address root causes so the same classes of flaws stop recurring.

• BAn annual point-in-time test finds only a sample of issues after release and does not build security into development, so the same flaws keep being coded in.
• CDetecting flaws faster post-deployment still leaves them written into every release; it manages symptoms rather than addressing why the vulnerabilities are introduced in the first place.
• DInsurance shifts some financial consequences to a third party but does nothing to stop developers from reintroducing the same coding flaws into each new release.

The Environmental group represents characteristics relevant and unique to a particular user's environment, letting consumers customize the base score for asset importance and local security controls present.

• AThe Temporal group reflects characteristics that change over time, like exploit maturity or remediation level, not the importance of an asset within a specific organizational environment.
• BBase metrics describe intrinsic qualities that stay constant over time and across user environments, so they cannot capture organization-specific asset importance or local mitigating controls the analyst wants to reflect.
• DCVSS v3.1 has only Base, Temporal, and Environmental groups; the Threat group belongs to CVSS v4.0, so it is not the v3.1 answer for environmental customization here.

Within SCAP, XCCDF is the language for expressing security checklists and benchmark rules, while OVAL standardizes how to assess and report upon the machine state of systems.

• BThis reverses the two roles: OVAL encodes the machine-state tests and XCCDF expresses the checklist, so swapping them misstates how these SCAP component languages divide responsibility.
• CCPE and CVE are SCAP enumerations that name platforms and disclosed vulnerabilities respectively; neither is the checklist language nor the machine-state testing language used in SCAP content.
• DCCE enumerates configuration issues and CVSS scores severity; neither serves as the checklist language nor the machine-state assessment language that XCCDF and OVAL provide within SCAP.

CIS Benchmarks are prescriptive, consensus-based secure configuration recommendations maintained by the nonprofit Center for Internet Security, exactly matching the request for community-developed hardening guidance for the platform.

• AThe NVD CVE feed enumerates disclosed vulnerabilities; it does not provide the prescriptive consensus configuration settings a team needs to harden the servers from scratch.
• BEPSS estimates the probability that a vulnerability will be exploited; it scores threats, not configuration settings, so it cannot serve as a hardening baseline for these servers.
• CRules of engagement govern how a penetration test is conducted; they define test scope and limits rather than supplying secure configuration recommendations for hardening the operating system.

Because finite resources make equal protection of every asset infeasible, an accurate inventory with criticality ratings lets the team prioritize remediation on mission-essential systems first, matching risk-based prioritization.

• AAsset criticality reflects business importance, not exploit likelihood; converting a Base score into a probability conflates CVSS with EPSS and does not describe how criticality aids prioritization.
• CAsset inventories underpin remediation prioritization, not merely license auditing; framing inventory as administrative paperwork ignores its foundational role in knowing what must be monitored and protected.
• DCriticality measures how much the organization depends on a system for its mission and is assigned by the organization, not derived from a vendor's CVSS Base severity score.

Disabling unneeded services, closing ports, and applying least privilege and least functionality reduces the attack surface, giving attackers less opportunity to exploit weaknesses, which is the stated objective.

• AExposing more services and APIs enlarges the attack surface and adds entry points for attackers, which is the opposite of the hardening goal these least-functionality measures are meant to achieve.
• BTemporal scoring reflects factors like exploit maturity and is unrelated to disabling services or ports; these hardening steps change exposure, not how a vulnerability's severity is scored over time.
• DCyber-insurance transfers financial impact after an incident; it does not remove exposed entry points, so it is risk transfer rather than the attack-surface reduction the hardening tasks accomplish.