The other day me and @gregkh shot down a draft proposal to add a new role in the CVE ecosystem (SADP: "supplier ADP") that would append data to CVEs with details about dependencies and how they are or are not vulnerable to each particular CVE.

Imagine the amount of dependencies that use curl or the Linux kernel etc. These sweet innocent proposal makers thought in the terms of 5-10 dependencies per CVE. Not tens or hundreds of thousands which is far from unthinkable.

@bagder @gregkh 🤦‍♂️

@bagder @gregkh easier to list the software that doesn't depend on curl.

@bagder @gregkh isn’t this what VEX is meant for?

@jacques @gregkh possibly sure, but that's not info inserted into the CVE records like this proposal does.

@bagder @gregkh got it. Sounds like some is trying to create the Universal Asset Graph by accident rather than on purpose.

(Relevant self-post: https://theoryof.predictable.software/articles/some-requirements-for-a-universal-asset-graph/ )

@jacques @gregkh yeah, I think some of us realized that which also made us immediately realize the scale it would have to support to work - and how that alone would make the proposal not work.

@bagder @gregkh where was that proposal circulating?

@msw @gregkh it was presented and discussed during our most recent OSS CNA user group meeting

@bagder @msw @gregkh Ha! They weren't asking for much were they!?

@sjvn @msw @gregkh to be honest, it felt almost a little cute and innocent!

@bagder @sjvn @gregkh that’s been my experience for a lot of these things. Well intentioned ideas, but they don’t withstand contact with the realities of wide-scale reuse.

@mlieberman @jacques @gregkh we as producers of CVEs for a component cannot tell which users that are vulnerable nor how sever their problems are if they are vulnerable

@jacques @bagder @gregkh btw… how is it going, making the Universal Asset Graph on purpose?

@msw @bagder @gregkh I haven’t seen anything that fits the criteria, but there are partial things like Mercator, GUAC (the DB) and osv.dev (the data).

In fairness I’ve been out of this space for quite a while.

@jacques do you miss it? 😅

@msw yes and no. It was nice to have a sense of mission and doing good. Now my work focuses on making a rich guy even richer.

On the other hand: https://mastodon.chester.id.au/@jacques/113682317639998354

@jacques yes, maybe dealing with the realized capital expenses of infrastructure within the context of a firm are a little easier to wrangle in one's head compared to the abundant world of digital public goods such as FOSS.

To me, there are risks introduced through widely reused public-goods software that are, in theory, limitless, not just millions of dollars. Good things the benefits outweigh them.

And of course, making FOSS better makes those with the most resource excess richer too. 😅

@msw @bagder @sjvn @gregkh The lack of understanding around open source is one of the biggest threats open source has I suspect

@jacques @bagder @gregkh I'd really love to have some public database that would help us all collectively make more efficient resource allocation decisions.

Let's take CVE-2025-38352 for example. CISA added it to the KEV because Google said that there is evidence of exploitation in the context of Android.

If you use CONFIG_POSIX_CPU_TIMERS_TASK_WORK=y the fix is not needed.

Linux distros aren't affected but release "fixes" anyway. https://forums.rockylinux.org/t/rocky-8-10-cve-2025-38352/19590/3

#PatchAllTheThings! #InfoSec

@msw @jacques @bagder I have no problem adding additional data like "This config option means you will not be vulnerable" to our records today, if people want to submit that information to us. We take patches and additions to the kernel cve.org records on a weekly basis from vendors that work to narrow down affected kernel ranges and add additional references.

So we could do what you want today, no changes to anything that cve.org does right now would be needed, just send us a patch! But that was not what was being proposed at all, unfortunately.