Closed stevespringett closed 6 years ago
FYI title is just an opaque text field, and some have different formatting; its not meant to be decoded.
FYI, The title comes from a few different places, but we are working on unifying it.
So as mentioned by @jdillon the title field is not uniform and will be difficult to make it so in the near future due to the variety of ways the title is generated and stored.
However it should be quite possible for us to provide the CVE in a separate field to aid in automated processing.
Thanks for the clarifications. I'm all for continuous improvement and if there's a way to separate out the CVE or OSVDB ID or whatever, into it's own field, that would be an excellent short-term solution.
Ya, understood. I will look into what we can do there for NVD and possibly other sources. I will point out that though there is likely a lot of overlap between our data and that in OSVDB, we do not have any knowledge or information of OSVDB findings or IDs due to possible licensing restrictions (unfortunately).
Curious if there's any progress on this ticket?
I've had an OSSIndex scanner in Dependency-Track for some time now, but haven't been able to finish it without this enhancement. Same will likely be true for Dependency-Check.
Hi.
Sorry for the delay. Things have been rather wild lately. I was talking to the team, and things are looking good for us to be able to get you something by the end of the week.
You should now see a new "cve" field for any vulnerability for which the CVE ID is known. For example:
{
"id": "f61bf942-e6d1-4532-b6c2-6a72415a5343",
"title": "[CVE-2014-6071] Improper Neutralization of Input During Web Page Generation (\"Cross-site Scripting\")",
"description": "jQuery 1.4.2 allows remote attackers to conduct cross-site scripting (XSS) attacks via vectors related to use of the text method inside after.",
"cvssScore": 6.1,
"cvssVector": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N",
"cve": "CVE-2014-6071",
"reference": "https://ossindex.sonatype.org/vuln/f61bf942-e6d1-4532-b6c2-6a72415a5343"
},
We do not currently track other IDs, so there are no other ID fields at this time. If and when such a time comes we might use custom ID fields, or a common field name, but I expect that CVE will always retain its own field not only because of backwards compatibility, but also because it is a particularly special case.
Perfect. Thanks @ken-duck. I've verified the API is sending back CVE, score and vector if it's available.
Great to hear. Thank you for your patience!
Currently, the response from ossindex api contains more than one type of data in a single field leading to non-deterministic behavior.
Current response:
The brackets appear to be optional, and the combining of a description, native vulnId, and an ambiguous source makes the title in its current format, extremely difficult to parse and perform an action on in an automated way.
Proposed response:
For items that do not have a single source of truth (i.e. a vuln identified from a GitHub issue), then simply leave the vulnId blank.