TL;DR
If you want to release fewer potential bugs, redefine your development, testing, and deployment pipelines to provide comprehensive test coverage and integration testing. That's largely an engineering matter, though. The real answer to your posted question is for the business to do a better job of capturing the impact of bugs discovered in production, and then identifying process controls that mitigate the impact.
Measure Defect Impact
One way to measure defects is to capture their effects, and to sum the attendant costs associated with those effects. In other words, bugs that cause problems in production can be toted up by tracking the number of problems users experience in production, by how much time or money it costs to remediate them, or some other measure of actual business impact. A "bug" that doesn't destroy data, bothers no one, and largely goes unnoticed would make it hard to justify a heavy-weight process to prevent or track it.
In your case, there is certainly an implicit problem, but it's not primarily in the way that bugs are making their way into production or the lack of metrics around how they're patched. The core gap appears to be that the business is neither monitoring its production infrastructure, nor tracking customer/user issues. Without tracking the effects that might then be tied back to the development or maintenance process, any purely development-based metrics you devise are essentially worthless from a business point of view.
Business & User Repsonsibilities
In comments, you mention that you think it's the developers' responsibility to track bugs. Aside from the fact that modern source code management systems are certainly able to report when patches are applied, and to differentiate between development and maintenance branches when tags, branches, or other useful engineering practices are consistently applied, ultimately the sources for identifying "unprevented" bugs are:
- system monitoring
- user-generated problem reports
- post-mortem log/dump analysis
It is the responsibility of the business to ensure that adequate resources are expended on monitoring, ticketing, log aggregation, and so forth. It is also the business' responsibility to allocate resources for developing more mature development practices that can avoid certain classes of defect, but that will never guarantee a complete lack of bugs.
Users also share some responsibility. If a user experiences a bug, the user should open a bug within whatever tracking system you use. If bug tracking isn't important enough to bother users about, why would you imagine it's important for the developers?
The implicit bias in your question is that the developers are responsible for both the lack of rigor in your process and at fault for releasing buggy code. It would be more accurate to say that the entire business process shares ownership of the bugs and lack of tracking metrics. You need to ensure that management and users participate appropriately in crafting whatever processes and controls may be missing, because a great deal of the responsibility is theirs, too.
