Interesting 🤔 how #CVE are leveraged as resume items, putting #programmers #developers & project leads under pressure by #bogus CVE reports or unnecessary high CVE ratings.
Popular and obscure programs are affected in the #OpenSource #POSIX world e.g #Linux #freeBSD #netBSD #openBSD
#Curl âž° by #Daniel #Stenberg #IP by #Fedor #Indutny & #nodeIP are popular programs hit by this #phenomena which can lead to unwarranted #panic in the users space
https://www.bleepingcomputer.com/news/security/dev-rejects-cve-severity-makes-his-github-repo-read-only/
Dev rejects CVE severity, makes his GitHub repo read-only
The popular open source project, 'ip' had its GitHub repository archived, or made "read-only" by its developer as a result of a dubious CVE report filed for his project. Unfortunately, open-source developers have recently been met with an uptick in debatable or outright bogus CVEs filed for their projects.
There is something that have been bothering me for past few months, and resulted in me archiving node-ip repo on github: https://github.com/advisories/GHSA-78xj-cgh5-2h22
Someone filed a dubious CVE about my npm package, and then I started getting messages from all people getting warnings from `npm audit`.
I just posted a comment on the advisory issue https://github.com/github/advisory-database/pull/3504#issuecomment-2189530624 asking to remove it, but looking at dicer's advisory https://github.com/advisories/GHSA-wm7h-9275-46v2 I see that there might be a larger pattern in place?
/1
It looks like there are entities that in theory should fill the void in OSS community and provide resources for managing security reports for overloaded maintainers. (I'm looking at you SNYK)
However, the verification process of vulnerability reports doesn't involve maintainer at all, and it sounds like the commercial interest of advisory repositories is aligned with creating more vulnerabilities and proving themselves “useful" to companies that utilize them.
/2
For that dicer bug in particular, I don't think it is reproducible as described in the advisory's PoC: https://gist.github.com/indutny-signal/9602403f5b0a946d139398e9bad8222c
Furthermore the PoC doesn't seem to involve dicer at all: https://security.snyk.io/vuln/SNYK-JS-DICER-2311764
What's funny is that I found no way to dispute the advisory on SNYK. The closest thing that I found was to write a message to support, but I'm not entirely sure whether this results in a vulnerability takedown...
/fin
Radio Azureus