That's totally correct, and I can't disagree with you.. If you architect things properly, then rebooting any one component shouldn't be a problem.. In such a c

That's totally correct, and I can't disagree with you.. If you architect things properly, then rebooting any one component shouldn't be a problem.. In such a case though, there is no need for this tool.. In practice, though, things really don't happen all nice like that. I've got loads of internal boxes with holes. Terrible? Yeah, absolutely. We're all ashamed. These aren't a real problem security wise though, if you take a second to think about it... Say I have a box I can't bounce (or rather, won't bounce) to get a patch for some bug -- probably it'll be some DB server in a legacy env, or something so fragile that there's a massive risk in bouncing it, vs the risk of some DOS attack which could only happen from inside the network then usually, we just won't do it... Sure, that's terrible practice and not something anyone should admit, but it's the reality... Environments like this, the attack surface is the JVM and OpenSSH.. Assuming an attacker can get through our CDN, then through our rproxies (which we do seriously patch), after that blindly break out of a JVM on an ASLR'd linux box, THEN look to pwn a kernel hole on the DB server we've not patched, then do you really think patching is going to save you? It's a trade off; and it's all tech debt many teams are working to completely replace -- this stuff is horrible, but sometimes you have to put up with it until you can replace it.. To me it seems the attack surface isn't really the OS anymore -- it's the app. More likely whoever is hitting you is going to rip your DB off via some dodgy post sanitation bug than remotely pwning your internal boxes with kernel exploits -- so this does little to protect anyone..