CVE Use Cases

During the last board call there was a discussion of use cases, and we had agreed that it was the homework of the board. I would like to start this thread to collect and identify the various use cases that exist surrounding the use of a vulnerability identifier. I also took a swing at identifying some requirements that these use cases create. I tried to capture use cases that I have heard others voice in addition to those that I am familiar with, and hopefully they can respond, update, and correct them where I went astray. I found some of the information at [1] useful while developing this list. I’m not sure if this is enough, or the right level of detail for this activity, but wanted to start with something relatively simple and go from there.

In the absence of any sort of glossary:

Software Provider: someone who creates, distributes, hosts, or maintains products which can contain vulnerabilities for End Users

End User: someone who is the final user of products which can contain vulnerabilities

Security Researcher: someone who investigates the security of products, i.e. discover vulnerabilities

Vulnerability Coordinator: someone who as acts as a coordinator during the vulnerability disclosure lifecycle

Each use case description is in the format of: <actor(s)> would like to <perform some action/activity> in order to <satisfy some objective/need>.

In no particular order:

1.

Description:

Software Provider, Security Researcher, and Vulnerability Coordinators would like to be able to identify vulnerabilities throughout the discovery, fix, and advisory publication lifecycle in order to track and share information across disparate groups.

Implied Requirements:

Either same identifier used throughout the process or when different identifiers are used a mechanism is needed to relate them.

2.

Description:

End users would like to know what vulnerabilities exist in order to track through the assessment, prioritization, and remediation lifecycle for any vulnerabilities that exist within their environment

Implied Requirements:

All vulnerabilities are identified and listed to the end user

Enough actionable information is associated with the identifier to allow an end user to perform necessary activities

3.

Description:

End users would like to have a common identifier for vulnerabilities in order refer to vulnerabilities using the same methodology while using different/multiple tools as part of their vulnerability management lifecycle.

Implied Requirements:

Interoperable identifier used by a broad cross-section of tools/information providers (absent that, some methodology to relate vulnerabilities will be needed)

4.

Description:

Information providers would like to provide information about vulnerabilities in order to assist users throughout the vulnerability management lifecycle.

Implied Requirements:

All vulnerabilities have an associated identifier and are listed with enough information to identify the issue

[1] https://insights.sei.cmu.edu/cert/2014/12/vulnerability-coordination-and-concurrency-modeling.html