CVE resolution or recommendation as a seperate attribute in the output json

[arupm2007]

People normally want to find what is the Resolution /fix available for a Vulnerability.

There is no separate attribute in the output Json when I search for a vulnerability. Sometimes resolution/fix/suggestion is coming along with the text of the problem statement for a CVE.

It should be segregated for better readability and understanding.

[andrewpollock]

Hi @arupm2007

People normally want to find what is the Resolution /fix available for a Vulnerability.

Agreed.

There is no separate attribute in the output Json when I search for a vulnerability. Sometimes resolution/fix/suggestion is coming along with the text of the problem statement for a CVE.

Could you cite some specific CVE records? I think you're either looking at records that have no fix available, or you've misunderstood how to read the record. Some examples would help clarify.

It should be segregated for better readability and understanding.

https://ossf.github.io/osv-schema/#affected-fields discusses in more detail how to interpret records

OSV records are intended to be used for programmatic consumption, by tools like OSV-Scanner. Can you share more details about your use case?

[andrewpollock]

Thinking about this a bit more, would a companion FAQ entry to https://google.github.io/osv.dev/faq/#how-do-i-use-osv-as-a-vulnerability-database-maintainer for consumers of OSV data have been helpful for you?

[arupm2007]

I need to get the fix details if it is already in fixed status. I can see only reference links landing on different website probably vendor-provided fix descriptions. How can I get it from this DB?

[andrewpollock]

Hi @arupm2007

I'm still unclear about a few things

I can see only reference links landing on different website probably vendor-provided fix descriptions. How can I get it from this DB?

Could you please advise of the specific records you're looking at, and how you are looking at them?

I'll state my assumptions and provide an annotated worked example:

When you say "CVE" you mean OSV records with a CVE- prefix.

I'm not sure which specific records you're looking at in relation to this issue, so I'll provide a worked example with one I just took from the top of https://osv.dev/list, CVE-2020-36830

The web interface view

https://osv.dev/vulnerability/CVE-2020-36830

The resolution or fix here is to ensure that https://github.com/nescalante/urlregex is upgraded to or past commit e5a085afe6abfaea1d1a78f54c45af9ef43ca1f9, or past version v0.5.0.

The API JSON output

https://api.osv.dev/v1/vulns/CVE-2020-36830

All of the pertinent information is contained with the OSV record's affected field

[arupm2007]

Hi Andrew, Here are the full details outlining the issue the organization is encountering.

Problem:

Many organizations struggle with effectively addressing specific vulnerabilities, even when a CVE is available. Typically, after identifying a CVE number from various scanning tools, we manually search for details in the NIST NVD or through reference links to vendor databases (e.g., Linux Foundation). This manual process is time-consuming, and we're looking for ways to optimize it.

In your database, when querying based on a CVE (e.g., CVE-2024-8088, https://api.osv.dev/v1/vulns/CVE-2024-8088), we retrieve details such as the problem statement and "references" (type=fix and URL where detailed explanations are available). We manually review these URLs and include the information in our reports during vulnerability analysis. This manual work is labor-intensive. If you include the fix explanation directly in the response JSON, it would greatly reduce manual effort and add significant value.

Suggestion: We don't have time to give a complete analysis in our report by browsing each of the URLs mentioned as reference links. My suggestion is to use web scrapping to get related pieces of information and then apply LLM for curated text (which will have an explanation of how the vendor fixed the problem etc)

please let me know if you need more details

Thanks, Arup

On Tue, Sep 3, 2024 at 9:42 AM Andrew Pollock @.***> wrote:

Hi @arupm2007 https://github.com/arupm2007

I'm still unclear about a few things

I can see only reference links landing on different website probably vendor-provided fix descriptions. How can I get it from this DB?

Could you please advise of the specific records you're looking at, and how you are looking at them?

I'll state my assumptions and provide an annotated worked example:

When you say "CVE" you mean OSV records with a CVE- prefix.

I'm not sure which specific records you're looking at in relation to this issue, so I'll provide a worked example with one I just took from the top of https://osv.dev/list, CVE-2020-36830 https://osv.dev/vulnerability/CVE-2020-36830 The web interface view

https://osv.dev/vulnerability/CVE-2020-36830

image.png (view on web) https://github.com/user-attachments/assets/4b3d1774-b928-4e5b-9ab0-b4091b4fe286

The resolution or fix here is to ensure that https://github.com/nescalante/urlregex is upgraded to or past commit e5a085afe6abfaea1d1a78f54c45af9ef43ca1f9 https://github.com/nescalante/urlregex/commit/e5a085afe6abfaea1d1a78f54c45af9ef43ca1f9, or past version v0.5.0. The API JSON output

https://api.osv.dev/v1/vulns/CVE-2020-36830

All of the pertinent information is contained with the OSV record's affected field https://ossf.github.io/osv-schema/#affected-fields

— Reply to this email directly, view it on GitHub https://github.com/google/osv.dev/issues/2522#issuecomment-2325570035, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADVAT4KVOSOOO3ULKA5A4NTZUUZMVAVCNFSM6AAAAABNCGPAJOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMRVGU3TAMBTGU . You are receiving this because you were mentioned.Message ID: <google/osv. @.***>

[andrewpollock]

Hi, thanks for providing an example CVE, let's walk through this one.

We have found that new users often approach the problem of vulnerability management from the perspective of:

• "Am I affected by CVE-2024-8088?" , closely followed by
• "(If) I am, what do I do about it?"

The primary intended use case that OSV aims to address is the broader question of "What known vulnerabilities affect my code (or Linux container image) and how do I remediate them?"

So to reframe things around this example of CVE-2024-8088, one could take this approach:

• Review CVE-2024-8088 and note that it relates to Python (with Alpine package information as well)
• Knowing this, and wishing to answer the question "Does this vulnerability affect me?", scan any Alpine systems, ultimately making OSV.dev API queries like:
  • curl -d '{"package": {"name": "python"}, "version": "3.10.14-r0"}' "https://api.osv.dev/v1/query" (assuming a vulnerable Alpine Linux system with Python 3.10.14-r0 installed). You will note that making this API call returns CVE-2024-8088 (among others)
  • At this point, to remediate this vulnerability, the action is to upgrade the Python package to (or past) the fixed version
  • curl -d '{"package": {"name": "python"}, "version": "3.10.14-r0"}' "https://api.osv.dev/v1/query" | jq '.vulns[].id, .vulns[].aliases, .vulns[].affected[].package, .vulns[].affected[].ranges[].events[].fixed' gives you an idea of how to visually determine the relevant fixed versions for this vulnerable version using the data provided in response to the query
• Additionally, noting there is commit-level information available on the OSV record
• Wishing to answer the question "Am I using a vulnerable version of the Python source code?", scan any Git repositories or submodules at the commit hash they are being used at, making OSV.dev API queries like:
  • curl -d '{"commit": "0fb18b02c8ad56299d6a2910be0bab8ad601ef24"}' "https://api.osv.dev/v1/query" (assuming a Git repo at https://github.com/python/cpython/commit/0fb18b02c8ad56299d6a2910be0bab8ad601ef24). You will note that making this API call returns CVE-2024-8088 (among others)
  • At this point, to remediate this vulnerability, the action is to upgrade the relevant repositories to (or past) the fixed commit
    • curl -d '{"commit": "0fb18b02c8ad56299d6a2910be0bab8ad601ef24"}' "https://api.osv.dev/v1/query" | jq '.vulns[].id, .vulns[].aliases, .vulns[].affected[].ranges[].events[].fixed' gives you an idea of how to visually determine the relevant fixed commits for this vulnerable commit, but I acknowledge the next steps are a little more complex to determine.

In reality, one would use one of the existing scanning tools that integrate with the OSV.dev API (or data) such as OSV-Scanner, to perform the scanning step.

Does this help better answer your question?

[andrewpollock]

Please reopen this with any further questions you have