We should not be discussing about languages here, nor should we discuss about frameworks.There are several "camps" out there. Each of those believes, their approach is the true way, and as such is inherently secure, scalable, easy to write easy to maintain and so on. While, of course, ASP.NET, Java/JBoss, RoR, Grails, .... is an outright plain idiotic thing to do.
At the start of an successful undertaking, in most of all cases there is either one or both of the following:
- a group of people knowing each other. They share a common mindset, and when they are developers, they all belong to one "camp" and know hot to get things done. If you start this way, then learn to deal with the weaknesses of the given technology stack, but stick to it.
- otherwise, someone proceeding in a knowingly and mature fashion, keeping out quarrels and power play, setting a clear direction for the work, systematically addressing each of the relevant concerns, but doing so in a level-headed fashion, not overdoing anything.
1. Open source
2. Proven
3. Scalable
4. Availability of developers
Collocated on dedicated hardened secure servers and maintained by competent devs and sysadmins and you've got a robust and secure system.
Any one would shocked to know the true extent that the legacy financial system is hacked on all their proprietary commercial grade hardware and software.
So it's not necessarily the system / language that matters but the quality of the work of the individuals who implement your system
(And still your gonna get hacked if your system has any real value)
Can't agree more!
Especially for security, when we're entering a realm of "serious business", the key point is not to build counter measures against every conceivable thread, but rather to be
able to prove that you've done your due diligence regarding security. For a business, its important to be able to offload the liability for some aspects of security to other persons and institutions.
To create a somewhat stylized and hypothetical example:
An entrepreneur hires two developers to build (or rebuild) a site. But he tells them right away, that security is a concern, and thus
- that he will conduct regular code reviews with them, where they have to explain security-relevant topics and decisions to him.
- that there will be an external security audit prior to launch, and that they will be doing excess hours to fix any serious uncovered issues
So now its in the developers own interest to come up with clever and creative solutions to get a grip onto security. This, and the fact that they will regularly be forced to explain what they've done to an outsider will create a push in the direction of a more structured, architecture centric approach. Building this way will slow them down considerably for sure, so that is the price to pay. But in the end,
both sides will benefit. The developers are relieved from those mind bogging discussions about the right level of carefulness and trickery, since there is a clear externally set goal to work against. Also, they've gotten a good argument to defeat pressure to move faster. And the entrepreneur, by conducting and moderating the code reviews, got a more thorough understanding of the technology and system to be built plus an external audit and testate, which is a building block for legal defence in case a real security breach happens later on.
While such an approach has proven his virtue in practice, unfortunately it's not a guaranteed recipe for success. It still pretty much depends on the personality of the people involved. Team up the "right" people in such a scheme, and it becomes a recipe for disaster