CS0-003 Vulnerability Management Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  CVSS score

  Why this is correct

  CVSS is a standardized severity score that synthesizes exploitability characteristics (attack vector, attack complexity, privileges required, user interaction) and impact metrics (confidentiality, integrity, availability) into a 0–10 score. In v3.x, this score provides the critical first filter for triage, allowing an analyst to quickly separate low-severity flaws from those that demand immediate attention. However, it is only a measure of intrinsic severity, not a guarantee of real-world exploitation, so it must be combined with threat likelihood and business impact. As a severity benchmark, it remains the primary initial factor in any prioritization workflow.

• ✗

  CVE publication date

  Why it's wrong here

  The CVE publication date simply records when a vulnerability identifier was assigned or made public; it does not describe the risk that a specific vulnerability poses to your environment. A CVE published years ago may have a reliable, weaponized exploit and remain widely unpatched, while a newly published CVE may still lack proof-of-concept code and not yet appear in active attacks. Prioritizing strictly by age can lead analysts to deprioritize ancient, still-exploited flaws or overprioritize brand-new vulnerabilities that are not actually being exploited. Thus, publication date alone is only metadata and is not a meaningful prioritization factor.

• ✓

  Asset criticality

  Why this is correct

  Asset criticality encodes the business value and operational consequence of the system on which a vulnerability is present. A high-CVSS flaw on an isolated development server may be far less urgent than a medium-CVSS flaw on a public-facing payment system or a domain controller, because the latter failures could jeopardize sensitive data or core services. Including asset criticality allows the analyst to contextualize vulnerabilities and apply compensating controls where remediation cannot occur immediately. This business-aware factor ensures the vulnerability management program reflects organizational risk tolerance and mission impact, not just the vulnerabilities' intrinsic properties.

• ✓

  EPSS score

  Why this is correct

  The EPSS score is a threat-likelihood metric, from 0 to 1, generated by a machine-learning model that ingests exploit code availability, attack observations, CVE characteristics, and other threat intelligence to estimate the probability of exploitation in the wild. It complements CVSS by capturing the dynamic, real-world exploitation landscape, which CVSS's static base score cannot reflect. For example, a critical CVSS vulnerability with an EPSS score below 0.01 is far less likely to be attacked than a high-CVSS flaw with an EPSS nearing 0.9. This empirical likelihood of exploitation makes EPSS essential for ranking which vulnerabilities should be patched first.

• ✗

  Number of vendors affected

  Why it's wrong here

  The number of vendors affected reflects only the breadth of product impact, not the actual risk to your organization. A vulnerability affecting hundreds of products might not impact a single product in your environment, while an obscure flaw in a niche component could be directly present on your business-critical systems. Moreover, a large vendor count often correlates with faster public disclosure and patch availability, making affected-vendor count an unreliable proxy for urgency. Prioritization must instead be driven by your own asset inventory, exposure context, and threat intelligence, not by the popularity of the vulnerability across the software ecosystem.

Go deeper

Related to this question