Vulnerability Management — Identify, Analyze, Remediate
Find weaknesses before attackers do, then prioritize by exposure and business impact — not just CVSS score. The full lifecycle from scan to validated patch.
Vulnerability management is not a scan; it is a program. Security+ 4.3 tests the full pipeline: identify (scan, pen test, threat feed, audit), analyze (confirm true positives, score with CVSS, prioritize by business impact), respond (patch, segment, compensating control, or accept with exception), and validate (rescan, audit, verify). The common novice mistake is treating CVSS score as risk. CVSS is severity. Risk adds exposure (is it internet-facing?), business impact (is it customer-facing?), and compensating controls (is there a WAF in front of it?).
The exam will hand you scenarios — a CVE score of 9.8 on an internal-only, firewalled system; a score of 7.5 on a public-facing payment API; a false positive flagged by an unauthenticated scan — and expect you to prioritize correctly. The answer pattern is nearly always: exposure + business criticality outranks raw score, and responsible disclosure is a process, not a product.
Identification methods. You find vulnerabilities through a blend of mechanical and human discovery.
- Vulnerability scan — authenticated (logs into the target with credentials; finds deeper issues like missing patches and insecure configs) vs. unauthenticated (tests from the outside; shows the attacker view). Use both. Tools: Nessus, Qualys, Rapid7, OpenVAS.
- Application security testing — SAST scans source code for known-bad patterns (Semgrep, SonarQube, Checkmarx). DAST tests the running app, often with fuzzing (OWASP ZAP, Burp Suite). Package/dependency monitoring flags known-vulnerable libraries (Snyk, Dependabot, GitHub Advisories).
- Threat feeds — OSINT (public feeds like CISA KEV, MITRE), proprietary (commercial intel from Mandiant, CrowdStrike), information-sharing organizations (ISACs/ISAOs for finance, health, energy), and dark web monitoring for leaked credentials or insider sales.
- Penetration testing — simulated attack with different information levels: black-box (no info, attacker emulation), white-box (full info, thorough), gray-box (partial info, credentialed user emulation).
- Responsible disclosure / bug bounty — the process where an external researcher privately reports a vuln, the vendor fixes it, and public disclosure follows on an agreed timeline. Bug bounty programs formalize this with monetary rewards.
- System/process audit — manual review of configs and procedures against a baseline.
Analysis — confirm and prioritize. Not every finding is real and not every real finding is urgent.
- False positive — scanner flagged, but verification shows no actual weakness. Mark and document.
- False negative — scanner missed a real vulnerability. These are what red-team and pen-test engagements surface.
- CVSS — 0.0–10.0 severity scale. Base metrics describe the vuln itself (attack vector, complexity, privileges required). Temporal reflect current exploit maturity. Environmental adjust for your deployment. CVSS is severity, not risk.
- CVE — unique identifier (CVE-YYYY-NNNNN) for a specific vulnerability. Does not score severity; that is CVSS.
- Prioritize by exposure + impact. Internet-facing + sensitive data + no compensating control = top of the list, even if CVSS is 7.0. Offline lab system with CVSS 9.8 = not urgent.
- Exposure factor — fraction of asset value lost if exploited. Environmental variables — deployment context. Industry/organizational impact — regulator sensitivity, customer trust.
- Risk tolerance — how much residual risk leadership accepts before demanding action.
Vulnerability response and remediation. You have four levers:
- Patching — primary remediation. Vendor fix applied within SLA (critical = days, high = weeks, medium = months).
- Segmentation — wall off the vulnerable system until patched.
- Compensating control — alternate mitigation (WAF rule, IPS signature, firewall block) that reduces risk when the primary fix is delayed.
- Exception / exemption — documented, time-bound, signed-off acceptance of residual risk.
Insurance is not a remediation — cyber insurance covers financial residual; it does not fix the vulnerability.
Validation. After remediation, verify: rescan to confirm the scanner no longer flags the finding, audit remediation records against SLA, independent verification (another engineer or team confirms). Reporting closes the loop: findings, fixes, residual risk, and any exceptions are reported to asset owners, leadership, and, for regulated environments, to regulators.
| Identification Method | Best For | Limitation |
|---|---|---|
| Authenticated scan | Missing patches, config drift, insecure settings | Requires credential management; misses attacker view |
| Unauthenticated scan | Attacker’s external perspective | Shallow; cannot see inside the host |
| SAST | Source-code patterns (injection, unsafe functions) | False positives; cannot see runtime behavior |
| DAST | Running application behavior, HTTP-layer issues | Coverage depends on test case quality |
| Package monitoring | Known-vulnerable third-party libraries | Only as good as the advisory database |
| Pen test | Human creativity, chained exploits | Point-in-time; expensive |
| Bug bounty | Diverse external researcher pool | Requires mature triage capacity |
| CVSS Severity | Score Range | Typical SLA (public-facing critical asset) |
|---|---|---|
| Critical | 9.0–10.0 | Patch within 7 days; emergency change |
| High | 7.0–8.9 | Patch within 30 days |
| Medium | 4.0–6.9 | Patch within 90 days |
| Low | 0.1–3.9 | Patch at next regular cycle |
| Response Option | When to Use | Gotcha |
|---|---|---|
| Patch | Vendor fix available and testable | Untested patches can cause outages |
| Segment | Patch delayed; contain exposure | Only reduces blast radius, not the vuln |
| Compensating control | Patch not feasible; WAF rule, IPS sig, firewall block | Must be documented and monitored |
| Exception | Risk accepted formally | Time-bound, signed, revisited |
| Insurance | Financial residual coverage | NOT a remediation of the vuln |
CVSS is severity, not risk. A CVSS 9.8 on a firewalled internal asset may be lower risk than a CVSS 7.5 on a public payment API. Always layer exposure + business impact + compensating controls on top of the score before you prioritize.
A SaaS company’s SCA tool flags CVE-2024-NNNNN (hypothetical) in libauth-1.9, a library used transitively by 14 microservices. CVSS base score is 8.1 (High). Four services are public-facing; ten are internal. The vendor patched it in libauth-1.9.4 two days ago. The dev lead wants to schedule it into the next sprint (three weeks out); security wants action this week.
Transitive CVE on a shared auth library
SaaS · 14 services · libauth-1.9When you cannot patch immediately, layer controls. WAF rules, IPS signatures, tightened rate limits, or temporary segmentation buy time until the patch ships. Document each compensating control with an owner, a target removal date, and a monitoring task — compensating controls are meant to be temporary, not permanent.
Vulnerability management lives at the seam of dev velocity and security urgency. You will not win every “patch this week” fight, and you should not try to. Pick the hills where exposure and impact justify the emergency, and let the rest follow the regular cadence. That judgment — not the scanner — is the job.
On the exam: “CVSS 9.8 on an offline lab” → low risk despite high severity. “CVSS 7.5 on a public API with PII” → high risk, prioritize.
A new security team is setting up the first organization-wide vulnerability scan cycle. Scanner licenses are limited. The ops lead argues for unauthenticated scans (simpler, looks like an attacker). The security engineer argues for authenticated scans (deeper). Budget allows one primary cycle. Which should it be, as the primary program?
Unauthenticated scans only
External attacker perspective. No credential management overhead. Looks like what the internet sees.
Authenticated scans as primary + unauthenticated as supplement
Credentialed scans find patch/config issues inside the host; unauthenticated scans run periodically to verify external view.
Option B fits better — authenticated scans catch far more
Option B: Authenticated scans find missing patches, insecure configurations, and local privilege issues an unauthenticated scan cannot see. Unauthenticated scans still matter — they show what an attacker observes — but they should supplement, not replace, the deeper view. Credential management (scan service accounts with least privilege, rotated) is an overhead worth paying.
Option A’s kernel of truth: Simplicity is real; no credentials to manage. But you will miss the majority of actionable findings.
On the exam: when asked for depth, pick authenticated. When asked for attacker view, pick unauthenticated. Best practice uses both.
4.3 questions test three patterns: (1) prioritize by risk, not raw CVSS (exposure + business impact + compensating controls reshape the queue), (2) pick the right identification method (SAST for source, DAST for running apps, package monitors for dependencies, pen tests for chained attacks), and (3) response is a menu — patch first, segment or compensate when you cannot patch, exception with signoff when you must accept risk. Insurance is financial coverage, not remediation.
- A The 9.8 because CVSS is the authoritative ranking
- B The 7.5 on the public payment API because exposure and business impact make risk higher
- C Neither — wait for vendor advisories
- D Assign both to the next quarterly patch cycle
Correct: B. Risk = severity + exposure + business impact. Internet-facing + PCI-scoped + payment data outranks a higher CVSS on an isolated asset.
A wrong: CVSS is severity, not risk.
C wrong: Public-facing criticals do not wait.
D wrong: Quarterly is not a critical SLA.
Source: CompTIA SY0-701 Objectives v5.0 — 4.3
- A Ignore the finding; CVE is only advisory
- B Prioritize the public-facing services for emergency patching; patch internal services on the regular cadence; apply WAF compensating controls where patches must wait
- C Rewrite every service to remove the library
- D File a cyber-insurance claim and move on
Correct: B. Risk-based prioritization: fix exposed services fast, internal ones on cadence, compensating controls bridge the gap.
A wrong: CVEs are findings, not suggestions.
C wrong: Rewriting is disproportionate response.
D wrong: Insurance is not remediation.
Source: CompTIA SY0-701 Objectives v5.0 — 4.3
- A Unauthenticated network scan
- B Package/dependency monitoring (e.g., Snyk, Dependabot, GitHub advisories)
- C Degaussing
- D Password rotation policy
Correct: B. Package monitoring tracks known-vulnerable libraries via advisory feeds (CVE, GHSA, PyPI/npm advisories) and is the direct control for transitive dependencies.
A wrong: Network scan sees services, not libraries.
C wrong: Degaussing is media destruction.
D wrong: Unrelated to vulnerabilities in code.
Source: CompTIA SY0-701 Objectives v5.0 — 4.3