If you can drop everything you're doing and patch your system the moment a patch is available, that's great! Do that. For most of us, it'll probably be the next morning or next workday when you would take care of a security patch.
Doesn't seem like that solves the fundamental problem though. You could have django issues or whatever just down the pipe.
Or issues lower down the stack.
Given the axiom, "public facing applications that accept user input and execute code based on that input can sometimes be made to execute code that is not desired" and such a system serves some business function perhaps including storing customer data.
If you are responsible for such a system, how do you manage that risk in a realistic way?
Minimising it by choosing a particular technology is only one dimension of security.
Incident response strategies, legal mitigation etc are important here also.
It seems that you either require a person with computer & internet access available at all times to patch at a moments notice or you need to devise a strategy so that having a web server compromised is not an apocalyptic event.
The philosophy and nature of the features Rails provides are what causes these security vulnerabilities. Auto-magic features are prone to this sort of exploitation.
