We've just released a follow-up paper in our research agenda about prioritizing actions during vulnerability management, Prioritizing Vulnerability Response: A Stakeholder-Specific Vulnerability Categorization.

In the paper, we present a testable Stakeholder-Specific Vulnerability Categorization (SSVC) that avoids some of the problems with the Common Vulnerability Scoring System (CVSS). SSVC takes the form of decision trees for different vulnerability management communities. Jonathan Spring, Eric Hatleback, Art Manion, Deana Shick, and I are the authors.

Since there are many different stakeholders in vulnerability management, we aim to avoid one-size-fits-all solutions as much as is practical. In the paper, we develop decision trees for two stakeholder roles: patch developers and patch appliers. In the CERT Guide to Coordinated Vulnerability Disclosure, these roles correspond to the vendor and deployer roles, respectively.

For example, we propose that patch developer and patch applier stakeholders consider the exploitation status and potential safety impact (for a broad definition of safety). But the concerns diverge beyond that; we suggest that patch developers consider the technical impact and attacker utility (which is itself comprised of virulence and value density), while patch appliers should account for the exposure of vulnerable systems and potential mission impact.

The result of applying SSVC is a priority decision, which we categorize into four priorities: defer, scheduled, out-of-band, and immediate.

• Developer - Do not work on the patch at present.
• Applier - Do not act at present.

• Developer - Develop a fix within regularly scheduled maintenance, making normal use of developer resources.
• Applier - Act during regularly scheduled maintenance time.

• Developer - Develop a fix out-of-band, taking resources away from other projects and releasing the fix as a security patch when it is ready.
• Applier - Act more quickly than usual to apply the fix out-of-band during the next available opportunity, working overtime if necessary.

• Developer - Develop and release a fix as quickly as possible, drawing upon all available resources. This potentially includes drawing upon or coordinating resources from other parts of the organization.
• Applier - Act immediately. Focus all resources on applying the fix as quickly as possible, pausing the organization's regular operations if necessary.

For more details, see the full paper.

We do not claim that this approach is the only viable option. This paper provides a proposal, a detailed hypothesis to test, or at least a conversation starter. In any case, we do not present it as a final proposal. We welcome others to try it out and recommend improvements.

In the year since we released our first report, we've received valuable feedback from the community, including the FIRST Common Vulnerability Scoring System SIG. We hope to continue this conversation moving forward.

For more background and a discussion of problems with CVSS as it currently stands, see the first part of our research agenda, Towards Improving CVSS. SSVC also builds on a history of related vulnerability classification and prioritization work at the CERT Division of the Software Engineering Institute, including A Structured Approach to Classifying Security Vulnerabilities, Vulnerability Response Decision Assistance (VRDA), and Effectiveness of the Vulnerability Response Decision Assistance (VRDA) Framework.