Security+ 801 Countdown, T-13: Vulnerability Management Becomes a Scenario Workflow

Vulnerability management is the ongoing practice of finding the weaknesses in an organization’s systems, deciding which ones matter most, fixing or containing them, proving that the fix worked, and telling the right people what happened. It exists because scanners, cloud accounts, and code repositories produce far more findings than any team can fix at once, and because a finding that is fixed on paper but never confirmed is still an open door. Treated as a loop rather than a one-time project, it turns a pile of tool output into a queue with owners, deadlines, and evidence.

SY0-801 objective 4.3 frames the topic as a scenario task, “Given a scenario, perform tasks associated with vulnerability management,” organized as a five-step loop of identify, prioritize, remediate, verify, and report, with IPAM, CSPM, and source code review appearing in the objectives for the first time (CompTIA 2025). That framing shapes how the exam will test it: expect a sequence, where you are given a finding, an address list, or a pen test report and asked to pick the next correct step. The concepts that feed the loop, such as CVSS and CVE at T-33, are covered elsewhere in this series; this post is about doing the work.

Identification: finding what the scanner never reached

Identification is the step that builds the list of weaknesses, and the first thing to understand about it is that the obvious tool has a structural blind spot. A vulnerability scanner tests only the addresses in its target list, and NIST SP 800-115 notes that network vulnerability scanning “uncovers vulnerabilities only for active systems” (Scarfone et al. 2008). A host that is missing from the list, or that was powered off during the scan window, produces no findings, which looks identical to a host with nothing wrong. The three identification methods that join scanning in objective 4.3 each close a different part of that gap: IPAM finds hosts the scanner never knew about, CSPM inspects cloud configuration that no network scan can see, and source code review finds flaws before there is a running system to scan. (The scanning activity itself and the vulnerability scanner as a tool are covered with objective 4.8 at T-8, on November 9, 2026.)

IPAM: coverage, not vulnerabilities

IP address management (IPAM) is the discipline, and the tooling, for tracking which addresses exist, which are allocated, and what holds them. Microsoft describes IPAM as “an integrated suite of tools to enable end-to-end planning, deploying, managing and monitoring of your IP address infrastructure” (Microsoft n.d.-b). IPAM finds assets, not flaws. Its job in vulnerability management is reconciliation. Compare what DHCP, DNS, and the address plan say exists with what the scanner actually scanned; every difference is a host (a forgotten VLAN, a piece of shadow IT) that has never been assessed. CISA’s Binding Operational Directive 23-01 builds the same split into federal policy: starting April 3, 2023, federal civilian agencies must “Perform automated asset discovery every 7 days” and run vulnerability enumeration across the discovered assets every 14 days (CISA 2022). That cadence is a federal benchmark rather than a universal rule, but the ordering is the lesson: discover first, then scan what you discovered.

The reconciliation is a set operation, and ordinary tools can do it.

PS> Get-DhcpServerv4Scope -ComputerName dhcp01 |
      Get-DhcpServerv4Lease -ComputerName dhcp01 |
      ForEach-Object { $_.IPAddress.ToString() } |
      Set-Content dhcp_leases.txt

$ comm -23 <(sort -u dhcp_leases.txt) <(sort -u scan_targets.txt) | tee unscanned.txt
198.51.100.15
198.51.100.37
$ nmap -sn -iL unscanned.txt

The PowerShell pipeline exports the active leases from every scope on the DHCP server; adding -AllLeases would include offered, declined, and expired leases as well (Microsoft n.d.-a). comm -23 keeps only the lines unique to the first file, i.e., addresses that hold a lease but were never scan targets, and the nmap ping scan confirms they are live before they are added to the scan policy.

CSPM: the cloud control plane

Cloud security posture management (CSPM) evaluates a cloud account’s configuration (logging, IAM policy, encryption, public exposure) against a benchmark, either continuously or whenever a setting changes. It works on the control plane, the management layer where cloud resources are defined, rather than on the operating systems running inside those resources. It does not inspect OS packages, so a scenario that pairs “CSPM found an unpatched kernel” has matched the wrong tool to the finding. In AWS, Security Hub CSPM evaluates CIS AWS Foundations Benchmark controls through AWS Config rules and recommends benchmark v5.0.0. The example used below is control CloudTrail.1, “CloudTrail should be enabled and configured with at least one multi-Region trail that includes read and write management events,” which maps to CIS v5.0.0 section 3.1 (Amazon Web Services n.d.-a). No network scan would reveal that an account’s audit logging is off; only the control plane knows. The public-bucket finding, the other classic CSPM result, is covered at T-29.

Source code review: a person reads the code

Source code review is the practice of a human reading code to find security flaws before the software is deployed. NIST SP 800-218, the Secure Software Development Framework (SSDF), separates the two halves of practice PW.7: code review, where a person looks directly at the code, and code analysis, where tools find the issues. PW.7.2 says to record and triage every issue in the team’s tracker (Souppaya, Scarfone, and Dodson 2022). That tracker entry is what makes review a vulnerability management activity rather than a quality gate: each issue becomes a finding that enters the same prioritize, remediate, and verify loop as a scanner result. On the exam, keep the roles straight: source code review under 4.3 is the management task of finding flaws before deployment, while static code analysis (under Application security) and secrets scanning (under Repositories) in objective 4.1 are mitigating controls.

Prioritization: severity assessment and the pen test report

Prioritization decides the order in which findings get fixed, and objective 4.3 names two inputs: severity assessment and penetration test report review. CompTIA does not define “severity assessment,” so what follows is interpretation: start from the label the tool assigned, then adjust it for exposure, exploitability, and asset criticality. SP 800-115 supports the adjustment, telling assessors to determine risk themselves “and not simply accept the risk levels assigned by vulnerability scanners”; its example is a cleartext FTP password finding that matters less on a server that allows only anonymous access (Scarfone et al. 2008). Confirm before you rank: the same guide makes identifying false positives the first goal of analysis, because a finding that is not real has a priority of zero. The scoring systems that feed the first step (CVSS, KEV, and EPSS) belong to T-33. Asset criticality needs its own field in whatever tracks findings; AWS encodes it as the ASFF Criticality attribute, a 0 to 100 scale where 75 to 100 marks mission-critical resources.

The penetration test report is the second input because it proves something a scanner cannot: that a finding is exploitable, and that it connects to other findings in an attack path. A scanner rates each finding in isolation. A tester chains them. Consider an illustrative case.

Finding	Scanner label	Pen test report	New rank
LLMNR and NBT-NS enabled	Medium	Step 1: name-resolution poisoning	1
SMB signing not required	Medium	Step 2: relayed authentication	1
Same local admin password everywhere	Medium	Step 3: lateral movement to domain admin	2
Outdated web server, isolated lab VLAN	High	No path demonstrated	3

Steps 1 and 2 together are ATT&CK technique T1557.001, “Adversary-in-the-Middle: Name Resolution Poisoning and SMB Relay” (MITRE n.d.). Three Medium findings that chain into domain admin outrank one High finding with no demonstrated path, so the chained Mediums jump the queue. The remediation order follows from the chain: break it at its cheapest link first (disable LLMNR or require SMB signing), then fix the rest. When I teach this in ITN 260, the confusion is usually reading “only” Mediums as low priority; the chain is the finding. Test types and rules of engagement are covered at T-3.

Remediation: choosing a response and a deadline

Remediation is the step that changes the system so the finding stops being true or, when that is not possible, reduces the harm it can do. Objective 4.3 lists remediation without sub-bullets, so the scenario supplies the constraint: a patch that does not exist, or a maintenance window that is weeks away. NIST SP 800-40 Rev. 4 gives the full menu of responses: accept the risk; mitigate it, which covers patching, disabling a feature, upgrading, or adding controls such as firewalls and network segmentation; transfer it, through cybersecurity insurance or a SaaS provider; or avoid it by uninstalling or decommissioning the asset. For assets that cannot be patched it points to isolation such as micro-segmentation, and it says organizations “should closely track and monitor all exceptions to maintenance plans” (Souppaya and Scarfone 2022). In practice that tracking is a time-boxed exception: a justification, a compensating control, a named owner, and an expiry date. Formal risk acceptance and the register owner are 5.2 topics covered at T-6. Basically, remediation removes the flaw and mitigation lowers the risk while the flaw remains, though SP 800-40r4 files patching under “Mitigate,” so read a scenario for its intent rather than its label.

Every response needs a deadline, and deadlines come from policy. The table below shows how a policy might tie them to severity and exposure; it is an example, not a standard.

Severity and exposure	Example SLA
Critical, internet-facing	7 days
Critical internal, or High internet-facing	15 days
High, internal	30 days
Medium	90 days
Low	Next maintenance window

One CSPM finding through the loop

To see the steps connect, carry one finding from identification to verification: the CloudTrail.1 control from above, failed in a production account.

$ aws securityhub get-findings --filters '{"ComplianceSecurityControlId":[{"Value":"CloudTrail.1","Comparison":"EQUALS"}],"ComplianceStatus":[{"Value":"FAILED","Comparison":"EQUALS"}],"RecordState":[{"Value":"ACTIVE","Comparison":"EQUALS"}]}'
  ...finding excerpt, values illustrative:
"Compliance": {"SecurityControlId": "CloudTrail.1", "Status": "FAILED"},
"Severity": {"Label": "HIGH"}, "Workflow": {"Status": "NEW"},
"RecordState": "ACTIVE", "Criticality": 90
$ aws securityhub batch-update-findings --finding-identifiers Id="<findingID>",ProductArn="<productARN>" --workflow Status="NOTIFIED"
$ aws cloudtrail create-trail --name org-trail --s3-bucket-name <log-bucket> --is-multi-region-trail --enable-log-file-validation
$ aws cloudtrail start-logging --name org-trail
$ aws cloudtrail get-trail-status --name org-trail
    "IsLogging": true,
    "LatestDeliveryTime": "2026-11-04T14:12:09.512000+00:00",

The first command pulls the active, failed findings for that control, and the excerpt shows the fields that drive the rest of the loop. Severity assessment: the tool says High, the Criticality of 90 marks a production resource, and an account with no management-event logging blinds incident response, so the finding gets the 7-day clock from the SLA table. The batch-update-findings call sets the workflow status to NOTIFIED, so the tracker shows the finding is being handled. The two cloudtrail commands are the remediation: create a multi-Region trail with log file validation, then start logging. The final get-trail-status output, with IsLogging true and a recent delivery time, is the first piece of verification evidence.

Verification and reporting: closing on evidence

Verification is the step that proves the remediation took effect, and it is the step most often skipped. SP 800-115 names two forms, a system audit and retesting, and it adds that a retest verifies only “if a mirror copy of the original test is performed,” meaning the same policy, the same credentials, and the same target (Scarfone et al. 2008). SP 800-40r4 frames the same idea for patches as confirming “that the patch is installed and has taken effect” (Souppaya and Scarfone 2022). The CSPM example shows what evidence looks like inside a tool: in Security Hub CSPM, a PASSED control evaluation moves the finding’s workflow to RESOLVED on its own, and if logging later stops, a FAILED evaluation resets it to NEW (Amazon Web Services n.d.-b). Setting RESOLVED or SUPPRESSED by hand verifies nothing, because the status then records a decision rather than a measurement. Close tickets on evidence, never on “patch deployed.”

Reporting is the step that turns the loop’s state into something other people can act on, and the objective splits it into internal and external audiences. Internal reports carry metrics: mean time to remediate, SLA compliance, open findings by severity and age, exceptions nearing expiry, and scan coverage, measured as IPAM-known hosts versus scanned hosts, which is where the identification gap shows up as a number. SP 800-115 adds methodology, results, analysis, and a plan of action and milestones (POA&M) to the assessment report (Scarfone et al. 2008). External reporting runs in the other direction: it is how outsiders report to you. A bounty program pays outside researchers for valid, in-scope findings, while responsible disclosure policies set how outsiders report, the scope, the safe harbor, and when details go public. The policy document and security.txt are covered at T-7.

What you need to know for SY0-801

• The loop: identify, prioritize, remediate, verify, report; do not skip verification.
• IPAM exposes unscanned assets by reconciling DHCP, DNS, and address records against scan targets; it is not a vulnerability scanner.
• CSPM checks cloud configuration against a benchmark (logging off, admin wildcard policies, unencrypted or public storage), not OS packages.
• Source code review (4.3) is a task; static code analysis and secrets scanning (4.1) are mitigating controls.
• Severity assessment adjusts a tool’s label for exposure, exploitability, and asset criticality.
• A pen test report’s proven chain outranks an isolated, higher-scored finding.
• No patch: reconfigure, disable, segment, add a compensating control, or accept with an owner and expiry.
• Verification needs evidence: a mirror-copy retest, an audit, or a passing control evaluation.
• Internal reporting is metrics and trends; external is the bounty program (pays) and disclosure policies (rules and timing).
• “False positive” and “rescanning” are 701-era vocabulary; the ideas survive as confirming a finding before ranking it and retesting as verification.

Check yourself

1. A monthly report shows every scanned host patched within SLA, yet an incident began on a workstation in a VLAN created six weeks earlier. The scanner logs show no activity in that VLAN. Which task would most directly have exposed the gap?

• A. Lowering the scanner’s minimum reported severity.
• B. Reconciling IPAM and DHCP lease data against the scanner’s target list.
• C. Running a CSPM benchmark against the cloud accounts.
• D. Launching a public bounty program.

Answer: B. The scanner never targeted the VLAN, so the failure is coverage; IPAM reconciliation lists addresses that exist but were never scanned.

2. A scan lists one High finding on a server in an isolated lab VLAN and three Medium findings on workstations. The latest pen test report shows the three Mediums chained into domain admin access. The team has capacity to fix one item before the next maintenance window. What should it do?

• A. Fix the High, because its score is higher.
• B. Break the Medium chain, e.g., by requiring SMB signing.
• C. Formally accept all four findings.
• D. Rescan the lab server to confirm the High.

Answer: B. The report proves exploitability and an attack path, which outranks a higher score with no demonstrated path; breaking one link stops the chain.

3. To fix a failed CSPM control, an administrator created a multi-Region CloudTrail trail and set the finding’s workflow to RESOLVED by hand. Which action best completes verification?

• A. Close the ticket, because the change request was approved.
• B. Suppress the finding to keep the dashboard clean.
• C. Confirm logging is active and that the next control evaluation returns PASSED.
• D. Send the result to the bounty program.

Answer: C. Verification requires evidence that the fix took effect; a manual status change or an approved change request is not evidence.

This is T-13 of the Security+ 801 Countdown: one change from SY0-701 to SY0-801 every morning until the new exam launches on November 17, 2026. Tomorrow, T-12: Accounts Become First-Class With gMSA, Break-Glass, and Access Reviews. New here? Start with T-38: The Blueprint Was Reweighted and Trimmed to 27 Objectives.

References

Amazon Web Services. n.d.-a. “CIS AWS Foundations Benchmark in Security Hub CSPM.” AWS Security Hub CSPM User Guide.

Amazon Web Services. n.d.-b. “Setting the Workflow Status of Findings in Security Hub CSPM.” AWS Security Hub CSPM User Guide.

CISA (Cybersecurity and Infrastructure Security Agency). 2022. “BOD 23-01: Improving Asset Visibility and Vulnerability Detection on Federal Networks.” Binding Operational Directive 23-01.

CompTIA. 2023. CompTIA Security+ SY0-701 Certification Exam Objectives. Version 5.0.

CompTIA. 2025. CompTIA Security+ SY0-801 V8 Certification Exam Objectives. Document Version 2.0.

Microsoft. n.d.-a. “Get-DhcpServerv4Lease.” Microsoft Learn.

Microsoft. n.d.-b. “IP Address Management (IPAM).” Microsoft Learn.

MITRE. n.d. “Adversary-in-the-Middle: Name Resolution Poisoning and SMB Relay.” ATT&CK Enterprise T1557.001.

Scarfone, Karen, Murugiah Souppaya, Amanda Cody, and Angela Orebaugh. 2008. Technical Guide to Information Security Testing and Assessment. NIST Special Publication 800-115.

Souppaya, Murugiah, and Karen Scarfone. 2022. Guide to Enterprise Patch Management Planning: Preventive Maintenance for Technology. NIST Special Publication 800-40 Rev. 4.

Souppaya, Murugiah, Karen Scarfone, and Donna Dodson. 2022. Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities. NIST Special Publication 800-218.