[tptacek]

If you are seriously on top of Rails security, you're ready to deploy workarounds if you have to, instead of waiting for the "tested" fix to percolate into Ruby gems. So, start by making an innocuous but testable patch. Add a class to ActiveSupport or something.

Also, when you drill this stuff (I think you should do it quarterly as soon as you have customers), spend as much time drilling how you'll profile your environment as you do in ensuring that your patch deployment is flawless. I worry more about hidden stale deployments than I do about production app servers.

[patio11]

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.

[static_typed]

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.

[tptacek]

I don't know what the heck one has to do with the other. Reliably, scalably, securely deploying production applications is never going to be part of the intro screencast for a platform.

Frankly, all your comments on this thread have shared a kind of language-war tone; I'm talking about what people should be doing to secure production Rails deployments, and you tack on a dig about a screencast from 2008. In other parts of this thread, you leave wisdom like "Rails is for posers, Python for pros". On the presumption that you are a good faith commenter writing this stuff to evangelize for what you believe to be better platforms: the tactics you're using are backfiring. Your comments are going light grey, and they're discrediting the idea of evaluating platforms based on security by giving Rails partisans an easy straw man to beat down.