In addition to user246's suggestions, I'd also recommend looking at these areas:
- presence/absence of unit tests
- effectiveness of unit tests (that is, do the unit tests cover more than the code paths - they should be covering all the potential logical boundaries as well)
- presence/absence of higher-level automated tests (including system, API, GUI, integration...)
- effectiveness and coverage of higher-level automated tests - as with unit tests this is more than simply how much of the code base the higher-level automated tests cover
- areas of the application where customer-reported bugs cluster - this won't be found by a code analyzer, but it's usually a good pointer to areas of the application that have a high level of technical debt.
I also second user246 about the importance of talking to your manager/lead to find out more about what they want to see in the report. You've got a very broad task here: your manager could want a detailed analysis, or they could be looking for a thumbnail guide to where they need to focus improvement efforts.
Regardless, I strongly suggest talking to the developers and testers - anyone who has worked with the application for any length of time will have a good idea where the problem areas are. In my experience, the problem areas in an application are the areas with the greatest technical debt.