I haven't ran metrics but this is what it feels like:
the number of bugs getting fixed has massively increased. this is positive, very positive of course.
especially old bugs in well maintained, highly used software that weren't publicly known, this is a really good outcome because it means the playing field is leveled a bit, i.e. nationstate sponsored groups have less advantage over defenders this way because finding the bugs costs significantly less and thus more people can do it.
there's a lot of culture change needed though. Especially cases where something not being a bug because the maintainer says so still happen, especially with slop reports. I'm tracking 2 libraries and 1 end user software, each for over 2 months now, for when they fix real bugs they dismissed only because they didn't agree with the reporting format / report content, not because they disprove the bug or the peripherals of it. This is really, really dangerous right now and I've switched off what I could to not run these things.
the number of bugs publicized before a fix is atrociously growing and this is retarded.
The only reason I can think of why this happens is because the reporters are greedy noobs that wanna get magic internet credits. Oh and BTC. Preferably 100s of bitcoins for feeding a 3-line prompt to Claude and then c&p-ing it into a Github issue (in public). This is extremely negative and the only way to defend against these retards is by running your own harnesses and being proactive. Which, fwiw, is expensive, time consuming and hard.
the number of new bugs introduced has grown significantly too, due to half the world vibing their way to dying while trying to get rich. This is no bueno but we'd have this without the adversarial bot reviews too of course.
about 20% of all bugfix releases introduce new bugs, sometimes worse than the one they fixed. This used to be way lower when everything was meathooked. It happened back then too, but since shipping releases wasn't as rushed, it just happened less often.
also bad: devs are getting more lazy and thus maintaining backports is done less often, which in turn makes you as a consumer often having to upgrade into major refactors that aren't ready, but it's the only way you can get rid of a vuln. These are the really nasty cases.
In the end, every old bug we fix now, and then deeply review the fix, and let the bots look at the fixes deeply while we're at it, helps a lot. The way to deal with this is to remove 3rd party code that isn't worth the review and management pressure. If I can write 5 lines of code to remove 3 poorly maintained or vibed dependencies then that is the preferred way. I think there are a lot of lines of code, as long as you write them cleanly, audit them, and so on, that you can write before it is more effort than truly maintaining the increase in supply chain. However, most teams even today do not maintain their supply chain and have no idea what code they are running.
I haven't ran metrics but this is what it feels like:
In the end, every old bug we fix now, and then deeply review the fix, and let the bots look at the fixes deeply while we're at it, helps a lot. The way to deal with this is to remove 3rd party code that isn't worth the review and management pressure. If I can write 5 lines of code to remove 3 poorly maintained or vibed dependencies then that is the preferred way. I think there are a lot of lines of code, as long as you write them cleanly, audit them, and so on, that you can write before it is more effort than truly maintaining the increase in supply chain. However, most teams even today do not maintain their supply chain and have no idea what code they are running.