@jgreco is right that staying patched is not a magic fix, but it is a necessary minimum.
Well, no, that's not what I said. If you do system hardening, patching without downtime becomes effectively impossible. But it's also unnecessary for most vulnerabilities.
The vast majority of vulnerabilities require that an attacker gain some form of access to a system. You can't exploit something like FreeBSD-SA-19:23-midi from remote. You have to gain a local non-root shell and then you might be able to wrangle root out of it.
Other attacks such as FreeBSD-SA-19:18-bzip2 can be externally influenced (i.e. by providing corrupted data on an external patch archive) but require that the local administrator trigger that process. There's a bunch of irony that it's actually patching your system that allows susceptibility to that vulnerability, sigh.
FreeBSD-SA-19:04-ntp could be problematic but in general you shouldn't be configuring your system to allow mode 6 from most other hosts. This and other network-based attacks is by far the most problematic class of attacks which may require patching. 19:04-ntp *shouldn't* require patching if you configure your hosts with a firewall that only lets your hosts talk to your site NTP servers, though. (Yes, I realize most people don't bother to set up site DNS recursers or site NTP servers these days, shame on them.)
So the real question is what's actually a risk. SA-19:23-midi isn't an issue if you don't have a local account. On most systems running conventional FreeBSD, where people drink the ports kool-aid, you do your happy ports-based install of Apache and PHP and you install any of the routinely-probed-for PHP crapware with every-other-week vulnerability, and, yes, sooner or later (hint: sooner), a bad guy will find his way to a /bin/sh-exposing vulnerability in your web app, and then use 19:23-midi because your Apache install was never secure.
What's *better* is to run an Apache install that's jailed. And I don't mean installing a full FreeBSD image in a jail and then installing Apache in *that* - that's approximately just as insecure and problematic as running it in the base. I mean literally running a jail that doesn't contain a /bin/sh, and where the only things running in it are Apache, PHP, and other necessary support files. This is strong protection against the skript kiddiez.
The other thing is compartmentalization. If you run a single host with ten services on it, that's ten points of entry, and a vulnerability in any one of those means that an attacker who can get in via one of them can then rummage around as root and subvert some of the other nine, or exfil some of the data from those other services. When you run a single host with your web site and your blog and your customer data in MySQL and your e-mail all on that one host, you're asking for a world of hurt. Run each thing as a separate VM.
Patching plays a role. Any service that's actually exposed to the public should of course be patched to the gills. But there's a lot of things you can do with design and architecture that are a lot more effective at controlling the attack surface and risk factors. It's just a shame that these aren't commonly applied.
