As a software producer, your goal is to deliver a high quality product to your customers. As you approach your release date, you want your product to have a known quality level. The released product will contain bugs. Your team's goal is to find as many bugs as possible, fixing the most important ones before the release date, listing the less important ones in the product documentation and fixing them later.
That last step is bug triage. You need to classify the known bugs into two categories: the ones that are important to fix, and the ones you can live with. Every bug fix is a code change, and every code change can introduce a new bug, so you want to limit the number of bug fixes. You don't want to accidentally introduce new bugs that you don't have time to find and fix before the release date.
Here is a quick survey of articles and literature on the topics of bug triage, code churn, and defect density:
The politics of bug fixing discusses bug triage and the political games that take place as people lobby to get their favorite bugs fixed.
My life as a Code Economist is a great overview on the subject. It gives bug triage advice and includes the quote, "Every time you fix a bug, you risk introducing another one.".
Use of Relative Code Churn Measures to Preduct System Defect Density (avalaible to ACM Digital Library subscribers) reaches these conclusions:
Increase in relative code churn measures is accompanied by an increase in system defect density;
Using relative values of code churn predictors is better than using absolute values to explain the system defect density;
Relative code churn measures can be used as efficient predictors of system defect density; and
Relative code churn measures can be used to discriminate between fault and not fault-prone binaries.
Where the Bugs Are (ACM) starts with the assumption that being able to preduct which modules contains bugs is an important contributor to the efficiency of the test team.