CySA+ v4 · Objective 2.4
Governing vulnerability management
Connect technical findings to accountable risk decisions and repeatable security practices. Evaluate control purpose, remediation objectives, software assurance, and dependencies on external suppliers.
What you will be able to do
- Classify controls by implementation type and security function.
- Explain inherent risk, residual risk, risk appetite, and the four treatment strategies.
- Define a measurable remediation objective with ownership, evidence, and exception handling.
- Differentiate SAST, DAST, SAMM, SCA, and SBOM contributions to application and supply-chain assurance.
Learn the concepts
- Lesson 1
Make risk decisions visible and accountable
A vulnerability programme needs more than scanners and patch tools. It needs agreed decision rights, measurable expectations, and controls that address the specific outcomes the organisation wants to prevent.
Open lesson → - Lesson 2
Build assurance across code, components, and suppliers
An application inherits risk from its design, its implementation, its dependencies, and the organisations supporting it. Different assurance activities expose different weaknesses and must be connected to actual releases.
Open lesson →
Apply your judgement · Synthetic scenario
A supplier launch with an unresolved dependency
A fictional museum is launching an externally hosted catalogue. The supplier provides a component list and asks the museum to accept an unresolved dependency issue so the launch date can remain unchanged.
- Supplier evidence
- SBOM for release 12; deployment confirmation for release 11; no authenticated DAST coverage report.
- Risk context
- Catalogue contains public exhibit data; its administration service also controls publication and staff accounts.
- Proposed controls
- Restricted administrative access, access logging, and a supplier update planned after launch.
- Governance gap
- No named exception approver, no expiry date, and no agreed evidence for confirming the update.
Your task
- Explain what the supplied evidence does and does not establish.
- Classify the proposed controls and identify remaining risk.
- Propose an accountable launch decision and improvement plan.
Compare your response
The SBOM describes release 12, while the deployed service is release 11, so component exposure remains unconfirmed for the actual service. Request matching inventory and assessment evidence, including relevant authenticated application coverage. Public catalogue data does not make the administration system unimportant because unauthorised changes and staff-account access have separate consequences.
Administrative-access restrictions are technical preventative controls when they block unwanted access. Logging is technical and detective when reviewed or connected to detection. A tested update is corrective treatment of the dependency condition. These controls may reduce risk, but none of the proposed statements yet demonstrates the effective access path or removes the unpatched weakness.
The authorised service or risk owner should decide whether to defer launch, reduce functionality, or approve a time-bound exception based on the clarified evidence. Document residual risk, supplier responsibilities, control checks, update deadlines, and escalation triggers with relevant advisers. Use the missing release linkage and coverage evidence to improve procurement and release-assurance procedures for the next launch.
Put it into practice
Use these labs alongside this module.
Check your understanding
Source reading: supplied book, chapters 8. Lessons, scenarios, and questions are original CyberCorps course material.