While I'm all about the Microsoft hate, in this scenario, it's not exactly unique, nor does a count tell the whole story.
Famously the kernel had a handful of high profile security issues discovered, so Microsoft has company. If you are floored by the number of security 'flaws', well, many projects are dealing with those and while higher than usual (largely due to AI findings), a lot of 'security' findings have long been dubious and the AI findings are no exception.
For example, a parser for a comprehensive script engine that is explicitly designed to allow arbitrary code execution had a handful of flaws where malicious scripting could overflow and run arbitrary code. The script just had to have binary data in it, be over 4 gigs in size, stuff like that. None of the flaws were subtle, and would be *obvious* on review. A malicious script could have just instead included precisely the malicious stuff. Nonetheless, there were several CVEs granted and the project released fixes for a CVE that let a script do exactly what the engine was designed to do, but in a weird way that's even more obvious than just putting the malicious code in directly.
The thing is, once you have a "security" finding that you know how to fix, it is far easier just to fix the bug and not argue the security facet. The curl developer has, historically, pointed out a few of the crazy CVEs that have been inflicted on him, but most developers shrug and move on, fearing the perception of 'arguing with a vulnerability'.
Practically speaking, stay up to date, pay special attention to the "famous" vulnerabilities but otherwise, it's not really that informative to think about the quantity of "vulnerabilities" published.