You should announce all the vulnerabilities you think exist to your customers, as you release patches for them. You can announce them publicly and issue a CVE to improve transparency and allow auditors to more easily substantiate the need to upgrade software, but you should generally embargo them for a period of time after the patch is issued (to give your customers time to patch).
When you announce them, it's best to do so without including too many details; don't include a PoC (Proof of concept). It's often sufficient to name the general functionality being exploited (such as configuration file parsing, or a particular feature the bug resides with), the class of bug, and what the bug gets an attacker.
You have to keep in mind what you're trying to accomplish by disclosing. You want to show that you are fixing security bugs above-board and notifying your users of their existence, and shift potential liability off of yourself by ensuring any reasonable security professional would be aware of your bugs and the need to patch particular versions. You don't want to give attackers additional ammunition against your clients.
So, chances are you should announce bugs found by your customers and support, as well as ones found by QA, but only after you patch them. It doesn't really matter whether you see that an attacker has the bug; if your software is important, chances are nasty people have lots of bugs you don't know about, as the current mood is to keep at least a few in reserve in case you want to do something (rather than blowing all your bugs as soon as they are found to add to your botnet or whatever).
In short, publish everything, but make sure your patches lead your public announcements by a reasonable period of time, and avoid giving specifics that would enable exploit writers.