I think Thomas is coming at this from a different place from many folks here, so let me explain what is animating this comment: many of you may have "monorails" apps, where everything you company does is one single Rails application. Most Rails shops eventually outgrow this architecture choice. (It's cool, I used it for ~4 years, I'm on your side.)

After you break the one app barrier, you tend to break it by a lot. Many of them will not be customer facing. For example, churn.example.com might be a simple dashboard coded up by an intern which sits behind HTTP Basic auth and just shows a dashboard with customer LTV broken down by plan. The churn app is really easy to forget: no customer ever sees it, the intern is back in college, and your team might not care about it. But e.g. the January Rails bugs were Pre-auth so you could give up code execution on churn.example.com with them. And churn.example.com sits in your datacenter and talks directly to the main database... uh oh.

If I ask you how many instances of Rails apps you have running in your company, and you can't immediately get that number from somewhere (say, an up-to-date list on an internal wiki), you should be terrified.

As you said above, "Rails Winter of Security Madness, it is be ready to patch at all times" -- sounds a lot less fun than the five minute blog or scaffolded apps that drew a lot of the Rails developers into the fold in the first place, not realizing that a short while down the road they would be spending all their time patching, monkey patching and crossing-fingers each time someone lifts the hood on the framework and discovers yet another parser-in-a-parser ready to exploit.