3.4 Common Traps in Vulnerability Management

3.4 Common Traps in Vulnerability Management

The traps in this domain are predictable, and CySA+ deliberately builds answer options around them. If you can name the trap a question is testing, the distractors collapse. Below are the recurring patterns, each with the reasoning the exam wants you to apply.

Trap 1: Treating the highest CVSS as the top priority

The single most-tested trap. A CVSS 10.0 on an air-gapped lab host with no data is lower business risk than a CVSS 7.0 on an internet-facing server in the CISA Known Exploited Vulnerabilities (KEV) catalog holding regulated data. When the stem mentions exposure, active exploitation, or asset criticality, the correct answer reorders by risk, not raw severity.

Trap 2: Closing a finding without validation

Applying a patch is not remediation until a re-scan confirms it. PCI DSS even mandates a rescan after a high-risk finding is fixed. Distractors that say "patch and close the ticket" omit the validation step that the lifecycle requires.

Trap 3: Confusing vulnerability, threat, and risk

Options deliberately swap these. A vulnerability is a weakness (unpatched service). A threat is the actor or event (a ransomware crew). Risk is likelihood x impact. If a question asks for the vulnerability and an answer names an attacker group, it is a trap. The same swapping happens with CVE (a specific flaw ID), CVSS (its severity score), and CWE (the weakness category) - read precisely which one the stem asks for. A common variant offers a threat-intelligence term where a scanning term belongs, betting you will pick the word you recognize rather than the one that fits.

Trap 4: False positives versus false negatives

Do not act on scanner output blindly - validate against configuration and vendor advisories before opening change tickets.

Trap 5: Skipping governance and the exception process

The fast answer that bypasses sign-off is usually wrong. A defensible decision routine:

• Identify the governing policy, SLA, or regulation (PCI DSS, NIST SP 800-40)
• Confirm asset criticality and data classification
• Score with CVSS, then adjust for exposure and exploitability
• Choose mitigate, transfer, accept, or avoid - with documentation
• Record exceptions and residual risk in the risk register
• Validate with a re-scan and report metrics

Trap 6: Misreading SLA timelines

Remediation SLAs are tied to severity, and the exam may present an organization-specific table. A typical pattern: Critical within 7-15 days, High within 30, Medium within 90, Low by the next maintenance cycle. Read the stem's stated policy rather than assuming a universal number - but know the typical shape so you can spot an out-of-order choice. If the organization's own table says Critical within 72 hours, that number wins over any textbook default.

Trap 7: Choosing the operationally convenient answer

Professional exams reward the controlled, auditable action over the fast one. "Just disable the account," "reimage immediately," or "turn off the firewall rule to test" may resolve a symptom while creating a bigger problem - lost evidence, an outage, or an unauthorized change. The defensible answer follows change management, preserves an audit trail, and gets the right approval. When two options both fix the technical issue, prefer the one that also documents the decision.

Trap 8: Ignoring downstream and compensating-control effects

A single change ripples outward. Patching a shared library can break a dependent application; segmenting a host can sever a legitimate integration. The strong answer accounts for the maintenance window, regression testing, and rollback plan. Conversely, do not over-remediate: if a robust compensating control (WAF virtual patch, isolation, monitoring) already reduces a finding to acceptable risk, emergency-patching a fragile production system off-cycle may create more risk than it removes.

Trap 9: Treating scanner output as ground truth

Scanners infer; they do not always confirm. Banner-grabbing can misidentify a version, and a back-ported security fix may leave an old version string that looks vulnerable but is not - a classic false positive on Linux distributions that patch without bumping the visible version number. Always corroborate high-impact findings with the asset's real configuration or a credentialed scan before opening change tickets or declaring an emergency.

Trap 10: Forgetting the inhibitors to remediation

The exam explicitly tests inhibitors to remediation - real-world constraints that block the textbook fix. These include memorandums of understanding (MOUs) and service-level agreements (SLAs) that forbid unscheduled changes, organizational governance and business process interruption concerns, degrading functionality when a patch breaks a feature, and legacy or proprietary systems the vendor no longer supports. When a stem names one of these inhibitors, the answer is rarely "patch now" - it is the compensating control, the documented exception, or the scheduled change that respects the constraint.

Recognizing the inhibitor is half the question.

The takeaway across all traps: the best answer is controlled, validated, documented, and risk-aligned, even when a faster or higher-severity-looking option exists. Train yourself to ask, for every Domain 2 question, "which trap is this testing?" - the answer usually reveals itself once you name the pattern.