Getting a vuln's source URL

[nchelluri]

Discussed in #3045

^{Originally posted by nchelluri January 8, 2025}
Hi, I am querying the osv.dev API and had a question about the affected[].database_specific field: https://ossf.github.io/osv-schema/#affecteddatabase_specific-field . What I really want is a single source field, for the vuln like I see in the affected[0].database_specific.source field here: https://api.osv.dev/v1/vulns/CVE-2024-38372 . The small handful of other vulns I have queried - from different databases and ecosystems - seem to all have this field present; as far as I can tell, it is a URL for the source of the vuln (and I think/hope it is the same value for all elements in affected).

I wanted to know if I could depend on this behavior.

An alternative I thought of was that described here https://ossf.github.io/osv-schema/#id-modified-fields is a way to assemble the source URL. This is likely workable and I can do that. However, it would require me to maintain a list of the prefixes and databases and URL formats. I am using osv-scanner to query the API. I thought: maybe osv-scanner would have a tool to do that in-built, so that the maintainers could keep such a prefix, DB, and URL list up-to-date. But I don't see that facility in the code, unless I am missing it.

Can anyone advise me on how to proceed? I think if I might just copy whatever way the OSV website calculates the "Import Source" field (I think this is found in source.yaml) then I would likely be okay. But, the schema does say about affected[].database_specific:

The meaning of the values within the object is entirely defined by the database and beyond the scope of this document.

So I don't want to do the wrong thing and have my code break later.

Does anyone have any suggestions? Thank you!

[hogo6002]

Hi @nchelluri, sorry for missing that post!

It looks like we do pull the database_specific source from the source link if it's there, but we haven't actually documented that anywhere.

@oliverchang, what do you think? Do you think user can rely on this, and we document this somewhere? I also feel it will make more sense to place this source into top level's database_specific rather than package level.

[oliverchang]

This is indeed undocumented behaviour, but I don't think it's safe to continue to rely on this without any changes in the future unfortunately.

This is because database_specific technically owned by the home database, and OSV.dev adding its own values here is not strictly correct. As such, this behaviour might change in the future.

Relying on source.yaml to extract this information seems reasonable to me.

[nchelluri]

Ok, thank you; do you think it might be possible for osv.dev to publish the source as extracted by source.yaml somewhere that API consumers can rely on and is documented?

[hogo6002]

Unfortunately, we don't have any plans for this unless we see more demand. I will close this issue for now, but feel free to reopen it if you still have any other questions. Thanks!