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 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/ )
Of course. Upstream has no way of knowing how downstream is using their tools/libraries. Do you think though that there should be a bigger push on downstream consumers to declare how they might/might not be vulnerable to a CVE?
I think of things like the Takata airbag recall from years ago. Manufacturers had to declare they were using the airbags.
@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
I’m less stressed now about my work, which involves the distribution of billions of dollars of capex, than I was when I was in security-land and fretted about risks in the millions of dollars.
@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. 😅
@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
OK, I’m busy waiting. Regarding Rocky 9: We also use a machine with kernel 5.14.0-570.37.1.el9. On this machine, the kernel parameter CONFIG_POSIX_CPU_TIMERS_TASK_WORK=y is effective. If I understand correctly, this means that the problem does not occur. Regards
ICYMI, here's a paper that was trying to answer this research question in the context of #OpenSource #Java projects on GitHub: "What do open-source maintainers think about integrating #VEX into their existing SBOMs?"
TL;DR: "In most cases, our augmented SBOMs were not directly accepted because developers required a continuous SBOM update."
daniel:// stenberg://
Ivo Limmen
Joe Cooper 🇺🇦 🍉
Jacques Chester
Michael Lieberman
Matt "msw" Wilson
Greg K-H
sjvn
Josh Bressers