Separate Fields for Native VulnID and Source

[stevespringett]

Currently, the response from ossindex api contains more than one type of data in a single field leading to non-deterministic behavior.

Current response:

{
  "id": "2a9810aa-3800-4e8e-8071-636e81c98386",
  "title": "[CVE-2014-3577] org.apache.http.conn.ssl.AbstractVerifier in Apache HttpComponents HttpClient",
 ...
}

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:

{
  "id": "2a9810aa-3800-4e8e-8071-636e81c98386",
  "vulnId": "CVE-2014-3577",
  "source": "NVD",
  "title": "org.apache.http.conn.ssl.AbstractVerifier in Apache HttpComponents HttpClient",
 ...
}

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.

[jdillon]

FYI title is just an opaque text field, and some have different formatting; its not meant to be decoded.

[ken-duck]

FYI, The title comes from a few different places, but we are working on unifying it.

• IF a CWE has been assigned, then we generate the title from the CWE
• Otherwise IF the vulnerability is a CVE we tend to use the CVE ID and its title or a substring of its body if there is no title.
• Otherwise we use the description provided by the researcher. This will tend to happen on older issues, as we are attempting to ALWAYS provide a CWE for new non-CVE issues (and some CVEs have CWEs assigned as well).

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.

[stevespringett]

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.

[ken-duck]

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).

[stevespringett]

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.

[ken-duck]

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.

[ken-duck]

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.

[stevespringett]

Perfect. Thanks @ken-duck. I've verified the API is sending back CVE, score and vector if it's available.

[ken-duck]

Great to hear. Thank you for your patience!