Support for additional fields for Vulnerability type

[prabhu]

Is your feature request related to a problem? Please describe. The current structure for a vulnerability is missing variables to store the following:

• Id (To store the CVE or GHSA id)
• Problem category Id (Typically CWE id found in problemtype_data.description.value)

Describe the solution you'd like These two fields are required to make sense of any reported vulnerability. They can be called Id and CategoryId to make them generic.

Describe alternatives you've considered related_urls cannot be used for this purpose

Additional context Also consider a third id say Vendor Id to support linking into commercial vulnerability databases.

[vtsao]

The CVE ID is typically stored as the note ID in the note name.

We currently don't have a field for CWE, but I imagine it would go at the top-level of a vuln note: https://github.com/grafeas/grafeas/blob/master/proto/v1/vulnerability.proto#L46

@aysylu this could be added easily if we think it's useful.

[vtsao]

FYI @nms2140

[prabhu]

@vtsao Thank you for the prompt response. I still think that vulnerability should have its id separate from note id. This is because the format of the vulnerability id would change depending on the provider/advisory such as CVE or GitHub and so on. Note id on the other hand can be kept consistent by the organization for easy lookups perhaps based on a project code.

[aysylu]

@prabhu: regarding CWE information, this has been requested in #164 as well. I'd be happy to review a PR that adds it -- could you please describe the use case you intend for this?

[prabhu]

I am working on an oss dependency scanner (will be called dep-scan) with built-in grafeas output and submission. A category id such as CWE id is necessary:

• to provide more information about the given vulnerability to developers and security professionals
• to link the issue with other application security findings that may not necessarily have a CVE attached (say from a sast-scan report)

For eg: lets take the CVE CVE-2020-0001. This links to CWE-269. A grafeas-integrated tool could then cleverly link this vulnerability note with other static analysis-based issues based on the CWE so that the vulnerability could be prioritized properly using a risk formula. Without such links, manual triages would be required to categorize and prioritize vulnerabilities.

[prabhu]

I am completely stuck. Happy to create a separate ticket if required.

As promised I have committed a preview of dep-scan, my oss dependency audit tool. I am using the same data structures defined by Grafeas such as VulnerabilityDetail, VulnerabilityOccurence etc (https://github.com/AppThreat/vulndb/blob/a9f282986eb152cc35f79fd817c157094b12b0fb/vulndb/lib/__init__.py)

I was of the assumption that a storage other than grafeas would be used to store Vulnerability object with details and the note sent to grafeas via VulnerabilityNote would be just Vulnerability Occurrences. But it turns out that the api for creating notes is expecting the whole Vulnerability object with details and windows_details (!) etc. This approach is not optimal since the information contained within a CVE can change over time - severities can change, related urls could get added, whole CVE can become unconfirmed and dropped.

Hence, I do not agree with the current design where a note contains the whole vulnerability including details. It should just be a reference and VulnerabilityOccurence is kinda alright for this. (Although the PackageIssue stuff is such a hack to construct correctly!)