Counting the number of CVEs to measure the security of a piece of software makes as much sense as counting lines of code to measure a developer’s performance.
And frankly I think they’re being generous to you; writing a frame buffer is even more complicated than their estimation.
The complexity is not the same. My grandfather is not questionning my ability to fix his computer that “breaks” once in a while just because I already fixed it the last time.
I don't care how complex the vulnerability is. The consequences I do.
Pretty much every operating system has some fun places near its core that are a steady stream of problems.
Also the software in question is a complicated subsystem to write on a platform that’s guaranteed to get many eyeballs on. So the fact that those CVEs span roughly once per year might also be a demonstration that there are relatively few bugs (if we knew the number of people and time spent researching vs CVEs published then maybe we’d have a more meaningful statistic).
CVEs do also demonstrate that active research is happening. There are plenty of common libraries out there that never get audited. Does fewer CVEs mean they’re more secure? Or does it just mean that nobody has checked?
Thus on its own, that data is pretty meaningless in terms of deriving a trend.
The reason the LoC comparison was made is because measuring lines of code doesn’t tell you how long a developer has spent debugging, reading documentation, or doing other research required. It doesn’t tell you how secure, performant, or even buggy the code is. All it tells you is the number of lines written and literally nothing more can be derived from that figure. Likewise with CVEs submitted.
However I have written a more in-depth reply about why counting CVEs is meaningless here: