> ... go into the official statistics.

There are no "official" statistics. None of this matters. If we judged projects by the number of security holes they had, then no one would be using ffmpeg, which had hundreds of serious vulns.

Vulnerability research is useful insofar that the bad guys are using the same techniques (e.g., the same fuzzing tools), so any bugs you squash make it harder for others to attack you. If your enemy is a nation state, they might still pack your laptop / phone / pager with explosives, but the bar for that is higher than popping your phone with a 0-day.

Vulnerability research is demonstrably not useful for improving the security of the ecosystem in the long haul. That's where sandboxing, hardening, and good engineering hygiene come into play. If you're writing a browser or a video decoder in C/C++, you're going to have exploitable bugs.

I am honestly a bit puzzled by this description and I wish they had named the publisher. I'm fairly familiar with this space and the usual experience with tech publishers is that they don't get all that invested in what they publish because 99% of technical books sell somewhere between 500-5,000 copies. That's barely enough to pay the copyeditor to do the bare minimum (often paying attention only for the first couple of chapters), then pay the layout guy, then the proofreader.

The usual accounts I've heard from my friends who published with Wiley, Addison-Wesley, or O'Reilly is that they sign up, get some in-depth feedback on the first couple of chapters, and then are on their own. I've never heard of a tech publisher exercising this level of creative control. I don't doubt that this happened, but it just sounds out of the ordinary.