That seems a bit harsh

https://curl.se/docs/releases.html

I don't know about weekly but the security record seems alright for something as complex as curl: https://curl.se/docs/security.html

Curl is very widely used and has a ton of features which means that it gets a lot of CVEs, but their severity is often significantly overstated for users outside of specific niche configurations - for marketing purposes, it’s nice to be able to say that you found a HIGH in libcurl without mentioning that it only affected Windows domain authentication on ARM. The lead developer has written about this providing a lot of noise without much tangible security benefit:

https://daniel.haxx.se/blog/2023/08/26/cve-2020-19909-is-eve...

Looks like cURL and SQLite have the same woes: https://www.sqlite.org/cves.html

Previously I worked on an open source project that pulled in many third party libraries. Users would run their corpo vulnerability scanners on the project and find dependencies with open CVEs and demand fixes, not understanding that in our usage of the libraries, the vulnerability is not exposed.

I think in 4 years, we had users open roughly 50 issues like this, which corresponded to exactly 0 real world exploitable issues.

A central vuln DB makes sense for sysadmins, but too many make it the end-all-be-all.

I think this ends up devolving to Goodhart’s law: once CVEs became marketing, a ton of people had a huge incentive to game their stats at the expense of everyone else’s time.