Objective 4.3 asks you to explain the activities associated with vulnerability management, and almost all the study time goes to the front of that list. Scanning, then arguing with what the scanner said. After that the material trails off somewhere around the word "patch," and the exam does not.
The back half of that objective hands out points, because it is the part that looks like a real ticket queue instead of tool output. Here is the sort I use when a question drops a scan finding in front of me.
CVE names the broken thing. CWE names the mistake.
Study notes swap these two constantly. They answer different questions.
MITRE defines a vulnerability as "a specific instance of one or more weaknesses in a specific product that can be exploited." That is what a CVE identifies: one flaw in one product, with a number you can hand to a vendor.
A weakness is broader. MITRE calls it a condition in a component that "could contribute to the introduction of vulnerabilities," and that is a CWE. It names the category of error, and one CWE entry usually sits underneath hundreds of CVE records.
Made concrete? Building a SQL statement out of unchecked user input is a class of mistake, and it has a CWE. The specific version of the specific product where somebody actually did that is the instance, and it gets a CVE.
CVSS is neither of those. It is the severity score (0 to 10) hung on the instance. FIRST publishes the specification, and the spec is honest about what its number leaves out. A base score "reflects the severity of a vulnerability according to its intrinsic characteristics which are constant over time." Constant over time, and identical for every organization on earth, which is exactly why the same document tells you to supplement it with environmental scoring for your own deployment.
So when a stem asks what identifies the flaw found on that host, you want the CVE. Where did the "critical" rating come from? CVSS. What kind of coding error produced the whole family of them? CWE.
"We can't patch it" does not end the question
Patching is the default and it is correct most of the time. Questions get interesting when the stem quietly takes that option away. A medical device that loses its certification if you touch the firmware. A controller that cannot be rebooted while the line is running. A vendor that went out of business in 2019.
The 4.3 vocabulary for that situation is worth learning as a menu:
- Compensating controls. Disable the vulnerable service, or put an ACL or a firewall policy in front of it.
- Segmentation. Move the thing somewhere the rest of the network cannot reach.
- Insurance. Shift the financial damage rather than the flaw.
- Exception or exemption. A review committee looks at the risk and formally decides this one does not get patched.
That last item is the one people refuse to pick, because choosing it feels like admitting defeat. It is a legitimate outcome. An exception somebody reviewed and wrote down is vulnerability management working as designed; an unpatched system nobody ever decided about is the failure. Those two situations look identical from the outside until you go looking for the paperwork.
Validation is what separates the last two answers
Watch for this shape. The stem describes a fix being applied, then asks what happens next. Two choices look responsible: close the ticket and notify the requester, or rescan the host.
Rescanning wins, and the reason is worth internalizing. Your deployment tool reporting "success" is a claim made by the same machine you are asking about. Validation of remediation means independent confirmation, which in practice is a rescan plus an audit of a sample of systems, checking that the patch installed where the console says it did. Anyone who has watched a patch report disagree with reality knows why CompTIA bothers testing this.
If one option verifies and another documents, verification comes first.
Reporting is doing work
The final activity in the objective is reporting: which systems took the patch, and what has shown up since the last cycle. Paperwork, right? Ask what happens without it. That exception granted for one quarter turns permanent, because the only thing that would have surfaced it again is a report nobody runs. Findings age out of everyone's memory except the attacker's.
Drilling it
Run any vulnerability scenario through four questions, in this order:
- Is the finding real?
- How bad is it here, in this environment, rather than in the abstract?
- What is the response, and if it is not a patch, which alternative and who signed off?
- What proves it worked?
Answer sets for this objective tend to include one option from each of those four steps. Figuring out which step the stem stopped at will usually knock out three choices before you have read any of them closely.
I write practice questions for this objective over at secplusmastery.com, and if you want to know which domains are quietly costing you points before you build a study plan, there is a free diagnostic at secplusmastery.com/diagnostic.
Top comments (0)