Yes your right, but not all products (and the product I was initially referring to) have large web facing footprints for security issues. At the indicated company the web facing portion was tiny part of the code base. I did monitor a few key technologies, and back-port or upgrade those (php, apache, ssl, etc) as needed. OTOH, we let our version of gcc get really long at the tooth, as well as refuse to allow additional technology stacks in certain areas (hence no ruby, python, node.js, etc, all rejected because they fill a similar place as the PHP we were already maintaining).

Amusingly enough, we avoided heartbleed because our version of openssl was too old! That was fun to try explaining to people, yah we backported the _1_ thing we though might cause a security issue a year ago into our ancient version of openssl, and your not affected by heartbleed. Yes, I know all the version checking scripts say its too old, but try to run one of the legitimate exploits against it..

The second part of this, is that an amusing exercise next time you actually have a need to call "support" for something. Find your local full stack/kernel developer and tell them, hey can you find this critical bug before the support guys find it.. and see what happens.

Keeping your toolkits small and lean, with a small set of dependencies does wonders for maintainability.