[phillc]

Your philosophies are sound for banking software.

There are cases where startups, social impact organizations, or any fast moving team would pick rails for its fast movement, accessibility, and support, even if they thought that there were even more security issues than that have happened.

[PommeDeTerre]

That's a very dangerous attitude to have.

Security is not something that should be traded off just to reduce development time or effort slightly.

Regardless of the situation, it's much more responsible to focus on doing security properly, while cutting corners on the UI, documentation or other less-critical areas of the application. Those are generally the kind of updates that can wait a little while. Implementing proper security should not be done via updates or patches "later on" in the project.

[cglee]

There's always a tradeoff between security and other variables. There's no such thing as 100% secure, so where you make your stake in the spectrum of security depends on your business domain. Just as you have different engineering requirements when building a spaceship vs a prius, you have different software practices for different types of projects.

[slurgfest]

Consider physical security against terrorist attacks. You can spend unlimited resources trying to prevent these. But this is subject to diminishing returns, and has other costs.In software projects, too, there IS a point at which it is more rational to trade off security against something else.

I would argue that the situation with Rails is analogous to the (historical) situation with Windows. There have been some design mistakes which have opened up more surface area for attacks. But the number of exploits has a lot more to do with market share.