Vulnerability Management

Identification: how vulnerabilities are discovered

Objective 4.3 questions almost never ask "what is this weakness?"; they drop you into one phase of a continuous loop, identify → analyze and prioritize → respond → validate → report → repeat, and ask for the right next action there (CompTIA's objectives and NIST SP 800-115 / SP 800-40 Rev. 4 frame the same loop, where each cycle's residual risk feeds the next). This section covers the first phase, identification: the ways an organization learns a weakness exists, because this lifecycle within Domain 4 (Security Operations, 28% of the exam)^[1] has to find a flaw before anyone can score or fix it. Recognizing each source and what it is good at is the whole game.

Vulnerability scans

A vulnerability scan automatically probes hosts, applications, and networks against a database of known flaws and misconfigurations. The single most-tested distinction is credentialed vs. non-credentialed (authenticated vs. unauthenticated):

A credentialed scan logs in with valid credentials and reads installed versions, patch levels, and configuration directly. It is far more accurate (fewer false positives and fewer false negatives) because it sees the system's true state instead of guessing from outside.
A non-credentialed scan probes only what is exposed to an unauthenticated attacker, mirroring an outsider's view but over-reporting, generating more false positives.

Scans further split into active (the scanner sends probes/packets to the target, which can disrupt fragile systems) and passive (it observes traffic without touching the target). NIST's testing guidance treats vulnerability scanning as a core technical assessment technique for identifying missing patches and misconfigurations, described in the Technical Guide to Information Security Testing and Assessment (SP 800-115)^[2].

Application security testing

Applications are scanned with techniques the exam names explicitly:

Static application security testing (SAST) analyzes source code without running it. It finds flaws like unsanitized input early but cannot see runtime behavior.
Dynamic application security testing (DAST) tests the running application from the outside, like an attacker would; it catches runtime and configuration flaws SAST misses but needs a deployed app.
Package / dependency (software composition) analysis inventories third-party and open-source libraries and flags those with known CVEs (catalogued public-vulnerability identifiers; defined under Analysis below), addressing supply-chain risk in the components you did not write.

Mnemonic: SAST reads the code (white-box, early); DAST runs the app (black-box, later); package analysis checks what you imported.

Threat intelligence, OSINT, and pen testing

Threat feeds and open-source intelligence (OSINT) supply external context (newly published CVEs, indicators, and exploit availability) flagging a flaw being weaponized before your scanner's signatures catch up.
Penetration testing goes beyond scanning. NIST defines it as "a test methodology in which assessors, typically working under specific constraints, attempt to circumvent or defeat the security features of a system"^[3]: a human actively exploiting flaws to prove real-world impact and chain weaknesses a scanner reports separately.
Responsible disclosure and bug-bounty programs invite external researchers to report flaws through a coordinated, often rewarded channel instead of releasing or selling them.
System / process audits review configurations, accounts, and procedures against a baseline, surfacing drift and policy gaps a scanner does not test.

Exam cue: "which method actively exploits the flaw to demonstrate impact" → penetration testing; "automated check against a database of known flaws" → vulnerability scan; "analyzes source code without executing it" → SAST.

The five lifecycle phases run as a continuous loop, with each cycle's residual risk feeding the next round of identification.

Analysis: confirmation, CVE, CVSS, and prioritization

Identification produces raw findings; analysis turns them into a prioritized, trustworthy work list. This is the densest part of objective 4.3 and the highest-yield on the exam.

Confirmation: true/false, positive/negative

Before acting, an analyst confirms each finding. NIST defines a false positive in security testing as "an alert that incorrectly indicates that a vulnerability is present"^[4]. Map the four outcomes:

Scanner says...	Flaw really present	Flaw really absent
Vulnerability found	True positive (correctly flagged; remediate)	False positive (noise; verify and dismiss)
Nothing found	False negative (missed real flaw; most dangerous)	True negative (correctly clean)

The false negative is the one that hurts you: a real flaw the scan never reported, so no one investigates it. Credentialed scans and follow-up penetration testing exist largely to shrink the false-negative rate. The false positive wastes analyst time but is safe; the exam's test is recognizing that an analyst who manually verifies and closes a finding as 'not exploitable here' has handled a false positive.

CVE: naming the flaw

CVE (Common Vulnerabilities and Exposures) assigns a unique identifier to one specific publicly-disclosed vulnerability, e.g., CVE-2021-44228. A CVE names the flaw and links to its description; it does not rate severity. The U.S. National Vulnerability Database (NVD) enriches each CVE with metadata, as described on the NVD CVSS metrics page^[5].

CVSS: scoring the severity

CVSS (Common Vulnerability Scoring System) is, per NIST, "a method used to supply a qualitative measure of severity"^[5] on a 0.0–10.0 scale. The v3.x base score maps to severity bands you should memorize:

Severity	CVSS v3.x base score
None	0.0
Low	0.1 – 3.9
Medium	4.0 – 6.9
High	7.0 – 8.9
Critical	9.0 – 10.0

The contrast the exam tests: CVE tells you which flaw; CVSS tells you how severe. A CVE without a score does not tell you urgency; a CVSS score without context does not tell you which to fix first in your environment.

Prioritization beyond the raw score

CVSS base score is a starting point, not the final order. SY0-701 lists factors that adjust priority for your organization:

Classification (how the finding is categorized, e.g., by asset type, data sensitivity, or finding type).
Exposure factor (the proportion of an asset's value that would be lost if the vulnerability were exploited; a higher exposure factor raises priority).
Environmental variables (is the asset internet-facing, is there a compensating control, is the vulnerable feature even enabled). A Critical CVSS flaw on an isolated, patched-around host may rank below a Medium flaw on an exposed crown-jewel server.
Industry / organizational impact (regulatory and business consequences specific to your sector).
Risk tolerance (the organization's appetite for risk sets the threshold for what must be fixed now versus deferred).

Exam cue: when a stem gives you a CVSS score and environmental detail (internet-facing, sensitive data, compensating control), the correct prioritization weighs the context: the highest base score is not automatically first.

Response, validation, and reporting

Once a finding is confirmed and prioritized, objective 4.3 expects you to choose a response, then validate and report. The exam's core lesson here is that patching is only one of four legitimate responses. The figure groups those four responses so you can see at a glance that remediate (eliminate the flaw) sits beside three answers that leave the flaw in place but manage its risk.

The four responses

Remediation (patching). Eliminate the flaw: apply the vendor patch, upgrade, or fix the configuration. This is the default and most complete response. NIST's Guide to Enterprise Patch Management Planning (SP 800-40 Rev. 4)^[6] frames patching as preventive maintenance that an enterprise must operationalize and prioritize by risk, not treat as optional.
Mitigation via compensating / segmentation controls. When you cannot patch immediately (a legacy or end-of-life system, a patch that breaks an application, a maintenance window weeks away) you reduce exposure with compensating controls: network segmentation or isolation, virtual patching at a WAF/IPS, tighter access control, or disabling the vulnerable feature. The flaw remains, but its reachability and impact shrink.
Exceptions and exemptions (risk acceptance). When the cost or operational impact of fixing exceeds the risk, the organization may formally accept the risk through a documented exception/exemption that a designated risk owner approves, with a defined review/expiry date. Undocumented 'we'll fix it later' is not acceptance: the documentation and sign-off are what the exam wants.
Transfer via insurance. Cyber-insurance transfers the financial impact of a residual risk to a third party. It does not remove the vulnerability; it offsets the cost if exploitation occurs.

Validation of remediation

No finding is closed on faith. Objective 4.3 names the validation methods:

Rescanning (run the scanner again and confirm the finding no longer appears, the most common, most testable validation step).
Audit (a review confirming the control or patch is in place and effective).
Verification (confirming, often manually, that the specific vulnerability can no longer be exploited).

Exam cue: "the team applied the patch; what is the next step?" → rescan/validate to prove the fix, then close. Closing without re-scanning is the classic wrong answer.

Reporting

The lifecycle ends with reporting: communicating findings, remediation status, residual risk, and trends to the right audience. Technical teams need per-asset findings to act; management needs aggregated risk and trend data to make decisions and demonstrate compliance. Good vulnerability reports tie back to the prioritization factors (severity, exposure, criticality) so stakeholders see why an item ranked where it did. Reporting also feeds the next cycle: today's residual risk and accepted exceptions become inputs to the next round of identification and analysis, which is what makes vulnerability management a continuous loop rather than a project.

The four responses to a confirmed vulnerability: remediation removes the flaw, while mitigate, accept, and transfer leave it in place and manage the risk.

Exam-pattern recognition: process, not weakness

SY0-701 objective 4.3 items are process questions: the stem drops you into one phase of the lifecycle and asks for the right next action or the right term. The discipline is to locate which phase you are in (identify, analyze/prioritize, respond, validate, or report) and answer for that phase. Naming the underlying weakness class (overflow, SQLi, misconfiguration) is objective 2.3's job and is usually a distractor here.

Stem cue → phase and answer

Stem says...	Phase	Right answer / term
Logged-in scan reads installed versions accurately	Identify	Credentialed scan (fewer false positives/negatives)
Analyzes source code without running it	Identify	SAST (DAST runs the app)
Human actively exploits the flaw to prove impact	Identify	Penetration test
External researcher reports a flaw for a reward	Identify	Bug bounty / responsible disclosure
Scanner flagged it but the flaw isn't really there	Analyze	False positive (verify, dismiss)
Real flaw the scan never reported	Analyze	False negative (most dangerous)
Unique ID like CVE-2021-44228	Analyze	CVE (names, does not score)
0.0–10.0 severity number	Analyze	CVSS (Critical = 9.0–10.0)
Order findings using internet-exposure + asset value	Analyze	Prioritization by exposure factor / environmental variables
Legacy system can't be patched right now	Respond	Mitigate / segment (compensating control)
Documented sign-off to defer a fix	Respond	Exception / exemption (risk acceptance)
Buy a policy to cover breach cost	Respond	Cyber-insurance (risk transfer)
Patch applied, what next?	Validate	Rescan / verify before closing
Communicate status and residual risk to management	Report	Reporting

High-frequency traps to pre-empt

Patch is not the only answer. When the stem says the system cannot be patched (legacy, EOL, breaks production), the right response is mitigate/segment or a documented exception, not 'apply the patch'.
False negative beats false positive in danger. A false positive wastes time; a false negative is an unfound real flaw, the higher-risk error. Credentialed scans and pen tests exist to reduce it.
CVE vs. CVSS. CVE identifies; CVSS rates. A question giving you only a CVE number is not telling you severity; one giving a 0.0–10.0 number is CVSS.
Highest CVSS ≠ always first. Prioritization weighs exposure factor, environmental variables, asset criticality, and risk tolerance: an isolated Critical can rank below an exposed Medium.
Don't close on the patch alone. The phase after remediation is validation (rescan/verify); skipping it is the classic wrong choice.
Acceptance must be documented. Risk acceptance is a formal, signed exception/exemption with a review date, not an informal deferral.

The five ideas that resolve most 4.3 items

It's a continuous lifecycle: identify → analyze/prioritize → respond → validate → report → repeat.
Confirm before you fix: true/false positive/negative; credentialed scans and pen tests cut false negatives.
CVE names, CVSS scores, and prioritization adds your environment's context on top of the base score.
Four responses: remediate (patch), mitigate (compensating/segmentation), accept (documented exception), transfer (insurance).
Validate every fix (rescan/audit/verify) and report results, feeding the next cycle. The whole process is objective 4.3 of Domain 4, Security Operations, 28% of SY0-701^[1].

Confirmation matrix: scan result vs. reality

Scan result	Vulnerability actually present	Vulnerability actually absent
Scanner reports a vulnerability	True positive: real flaw, correctly flagged; proceed to prioritize and remediate	False positive: reported but not real; verify and dismiss, but wasted effort if unchecked
Scanner reports nothing	False negative: real flaw missed; the dangerous gap, often caught only by pen testing or credentialed scans	True negative: correctly clean; no action needed

Decision tree

Cheat sheet

Sharp facts the exam loves — give these one last read before exam day.

Cheat sheet

Sharp facts the exam loves — scan these before test day.

Vulnerability management is a continuous lifecycle, not a one-time scan

SY0-701 objective 4.3 frames vulnerability management as a repeating loop (identify, analyze/prioritize, respond, validate, report, then repeat) so a scan report is an input, not the finish line. The exam-correct stance treats findings as something to confirm, fix, and re-scan rather than blindly patching the raw list. Residual risk and accepted exceptions from one cycle feed the next.

2 questions test this

Credentialed scans cut both false positives and false negatives

A credentialed (authenticated) scan logs into the host and reads installed versions, patch levels, and configuration directly, making it far more accurate than a non-credentialed scan that only probes from outside and over-reports. Authenticated reading lowers BOTH error types: fewer false positives (less guessing from banners) and fewer false negatives (it sees internal flaws an external probe can't). Choose credentialed when accuracy matters.

Trap Assuming a non-credentialed external scan is just as accurate: it over-reports and misses internal flaws a login would reveal.

5 questions test this

Active scans send probes; passive scans only observe traffic

An active scan sends packets and probes to the target, which can disrupt fragile or legacy systems, whereas a passive scan watches existing traffic without touching the host. Pick passive for sensitive, legacy, or production-critical systems you cannot risk crashing, accepting that it only sees what crosses the wire. Active gives deeper coverage where the host can tolerate it.

Trap Running an active probe scan against a fragile legacy or OT host you can't afford to crash, where passive observation was the safe choice.

SAST reads source code; DAST exercises the running app

Static application security testing (SAST) analyzes source code without executing it (white-box, early in the SDLC) and catches code-level flaws like buffer overflows and injection. Dynamic application security testing (DAST) tests the running application from the outside (black-box, later) and catches runtime and configuration flaws. They are complementary: SAST finds the flaw in the code, DAST finds what's exploitable when it runs.

Trap Calling testing of a live running application SAST: exercising the running app from outside is DAST; SAST never executes the code.

2 questions test this

Package/dependency analysis flags vulnerable third-party libraries

Package (software composition) analysis inventories third-party and open-source dependencies and flags those with known CVEs, addressing supply-chain risk in components you did not write. It covers the blind spot SAST and DAST of your own code miss: a vulnerable library you merely imported. This is why a known-vulnerable dependency shows up here, not in a scan of your own source.

Trap Expecting SAST or DAST of your own code to catch a vulnerable imported library, when an unmodified third-party dependency surfaces only in software composition analysis.

Pen testing actively exploits to prove impact; scanning only detects

A penetration test is a human, per NIST, attempting to "circumvent or defeat the security features of a system", actively exploiting and chaining flaws to prove real-world impact. A vulnerability scan only automatically checks targets against a database of known flaws and reports possible existence. So a stem describing someone who actively exploits to demonstrate impact points to a pen test, not a scan.

Trap Picking vulnerability scanning when the stem says the tester actively exploited flaws to prove impact: that's a penetration test.

Bug bounty and responsible disclosure intake external researcher reports

Responsible (coordinated) disclosure gives external researchers a structured channel to report flaws, with the issue going public only after the vendor has had time to patch; a bug-bounty program adds a reward for those reports. Both are legitimate identification inputs and beat ignoring or threatening the reporter. Threat feeds and OSINT supply related external context like newly weaponized CVEs.

Trap Treating an external researcher's report as a threat to silence, rather than intake through responsible disclosure or a bug-bounty channel.

Confirmation matrix maps scanner result against ground truth

The four outcomes pair what the scanner said with what is really there: true positive = a real flaw correctly flagged (remediate); false positive = flagged but absent (noise to verify and dismiss); true negative = correctly reported clean; false negative = a real flaw the scan missed. NIST SP 800-115 defines a false positive as "an alert that incorrectly indicates that a vulnerability is present." Knowing which quadrant a described result lands in is the testable skill.

2 questions test this

A false negative is the most dangerous scan error

A false positive only wastes analyst time verifying a flaw that isn't there, but a false negative is a real, unfound flaw nobody investigates: the genuinely dangerous outcome. Credentialed scanning and follow-up penetration testing exist largely to shrink the false-negative rate by seeing what an external probe misses. When a question ranks the errors by risk, false negative wins.

Trap Ranking a false positive as the worst error: it only wastes time; the false negative is the unfound real flaw nobody chases.

A CVE names the flaw but assigns no severity

A CVE (Common Vulnerabilities and Exposures) is a unique identifier for one publicly known vulnerability, formatted CVE-YYYY-NNNNN (e.g., CVE-2021-44228 / Log4Shell). The identifier only names and describes the flaw: it carries no severity rating of its own; severity comes separately from CVSS, as enriched in the NVD. A bare CVE number tells you which flaw, never how urgent.

Trap Reading a CVE number as a severity or urgency signal: the CVE only identifies the flaw; CVSS supplies the score.

1 question tests this

After running a vulnerability scan, the report lists each finding with a CVE identifier, a severity score, a weakness type, and affected…

CVSS scores severity on a 0.0-10.0 scale

CVSS (Common Vulnerability Scoring System) is, per NVD/NIST, "a method used to supply a qualitative measure of severity," producing a numeric base score from 0.0 to 10.0. The contrast with CVE is the testable pair: a CVE tells you which flaw, CVSS tells you how severe. A 0.0-10.0 number is a CVSS score; a CVE-YYYY-NNNNN token is not.

Trap Reading a CVSS score as the identifier of which vulnerability it is, when CVSS only rates severity and the CVE is what names the flaw.

1 question tests this

A vulnerability scanner maps a discovered flaw to CVE-2025-5678. The security analyst needs to prioritize remediation using a standardized…

Memorize the CVSS v3.x severity bands, especially where Critical starts

CVSS v3.x maps base scores to bands: None = 0.0, Low = 0.1-3.9, Medium = 4.0-6.9, High = 7.0-8.9, Critical = 9.0-10.0. The two boundaries the exam leans on are High starting at 7.0 and Critical starting at 9.0. A score like 8.5 is High, not Critical: the band edges are the trap.

Trap Calling an 8.x score Critical: Critical begins at 9.0; 7.0-8.9 is the High band.

Highest CVSS is not automatically remediated first

The CVSS base score reflects a vulnerability's intrinsic severity, constant across environments, so it is only a starting point: CVSS is explicitly not a measure of risk. Real prioritization layers on environmental and exposure factors (internet-facing? compensating control present? feature enabled?), asset criticality, organizational impact, and risk tolerance. An isolated Critical can therefore rank below an internet-exposed Medium.

Trap Remediating strictly in descending CVSS order, ignoring that an exposed, business-critical Medium can outrank an isolated Critical.

2 questions test this

Exposure factor is the fraction of asset value lost per event

The exposure factor (EF) is the proportion of an asset's value destroyed if the vulnerability is exploited, expressed 0-1.0 (or 0-100%); it drives the loss math via SLE = Asset Value x EF. As an analysis input it raises remediation priority: more of the asset at stake per event means a more urgent fix. It is one environmental input layered on top of the raw CVSS score, not a severity score itself.

Trap Treating the exposure factor as a standalone severity rating, when EF is only the fraction of asset value lost per event feeding SLE, not a CVSS-style score.

Patching is one of four vulnerability responses, not the only one

Objective 4.3 tests four legitimate responses: remediate (patch/fix/upgrade, the default and most complete), mitigate (compensating control or segmentation when you can't patch), accept (a documented exception/exemption signed by the risk owner), or transfer (cyber-insurance offsets the financial cost). Patching is the first choice but the wrong single answer when the stem rules it out: match the response to the constraint.

Trap Choosing patch every time, even when the stem says the system can't be patched and a compensating control, exception, or transfer is the fit.

2 questions test this

When you can't patch now, mitigate by shrinking reachability

When a flaw can't be patched immediately (legacy/EOL system, the patch breaks production, or the maintenance window is weeks away) reduce exposure with compensating controls: network segmentation or isolation, virtual patching at a WAF/IPS, tighter access, or disabling the affected feature. The flaw itself remains, but its reachability and blast radius shrink until a real fix lands.

8 questions test this

Risk acceptance is valid only as a documented, signed exception

Accepting a vulnerability's risk is legitimate only as a formal, documented exception/exemption approved by the designated risk owner, with a defined review or expiry date. An informal "we'll fix it later" is not acceptance: the documentation and sign-off are the testable point that distinguishes accepted risk from ignored risk. The exception then becomes residual risk tracked into the next cycle.

Trap Calling an unwritten "we'll get to it later" risk acceptance: without the documented, risk-owner-signed exception it's just unmanaged risk.

Cyber-insurance transfers the cost, never the flaw

Transfer via cyber-insurance shifts the financial impact of a residual risk to a third party, but it does not remove, fix, or reduce the vulnerability: only the cost is offset if exploitation occurs. The flaw and its likelihood remain exactly as before. Treat transfer as a financial response, not a technical remediation.

Trap Treating buying cyber-insurance as remediating the vulnerability: it offsets loss only; the flaw and its likelihood are untouched.

Enterprise patching is risk-prioritized preventive maintenance

NIST SP 800-40 Rev.4 frames patch management as "a critical component of preventive maintenance... a cost of doing business", a routine process of identifying, prioritizing, acquiring, installing, and verifying patches, not optional cleanup. Patches should be prioritized by risk rather than applied uniformly. This makes remediation a standing, risk-driven business operation, which is why the exam treats it as expected baseline practice.

Trap Applying every available patch uniformly and immediately, instead of prioritizing the patch backlog by the risk each flaw poses.

Validate every fix by rescanning before you close the finding

After any remediation, validate that the vulnerability is actually gone via rescanning (the most common and most testable method), audit, or verification, never close a finding on the strength of the patch alone. A patch can fail to apply, miss a host, or be reverted. So "patch applied, what next?" resolves to rescan/verify, then close.

Trap Closing a finding the moment the patch is applied, without a rescan to confirm the flaw is actually gone on every affected host.

6 questions test this

Reporting closes the loop and seeds the next cycle

The lifecycle ends with reporting findings, remediation status, and residual risk: per-asset technical detail for the teams that fix things, and aggregated risk and trend data for management and compliance. Residual risk and any accepted exceptions documented here become inputs to the next identification and analysis round, which is what makes the lifecycle continuous rather than linear.

4 questions test this

Inhibitors to remediation delay a fix even when the flaw is known

Inhibitors to remediation are factors that prevent or postpone applying a fix despite a known vulnerability: uptime/availability SLAs that limit maintenance windows, legacy or proprietary systems, organizational governance and change control, and vendor end-of-life status where no patch will ever ship. When an inhibitor blocks patching, the response shifts to mitigation or a documented exception rather than waiting indefinitely.

Trap Assuming a known vulnerability can always be patched promptly, ignoring inhibitors like uptime SLAs, EOL status, or change-control governance.

14 questions test this

Identification: how vulnerabilities are discovered

Vulnerability scans

Application security testing

Threat intelligence, OSINT, and pen testing

Analysis: confirmation, CVE, CVSS, and prioritization

Confirmation: true/false, positive/negative

CVE: naming the flaw

CVSS: scoring the severity

Prioritization beyond the raw score

Response, validation, and reporting

The four responses

Validation of remediation

Reporting

Exam-pattern recognition: process, not weakness

Stem cue → phase and answer

High-frequency traps to pre-empt

The five ideas that resolve most 4.3 items

Confirmation matrix: scan result vs. reality

Decision tree

Cheat sheet

Also tested in

References