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.
I'm curious about how people do security SLAs or whatever.