.Net and Java "faith-based" security

Dinis Cruz, who is one of the major contributors to the OWASP toolset, posts a comparison of the "real world" advantages of the relative security found in the .Net and Java environments. His findings based, again, on the reality of implementations not the capability of the frameworks, are instructive (emphasis added):

The reason I am asking this question is because the way the .Net Framework and the JVM are used in the real world, I don't see any major advantages between them and C++, ASP Classic, PHP, ...(put your favorite language/development platform here)..., etc...

The bottom line, is that in the 'Real Word', most .Net Applications execute with Full Trust and most Java based applications run with the Security Manager disabled. This means that the protections and security advantages provided by the Virtual Machine's Sandboxes (CLR and JVM) are close to useless since malicious code executed in those process can easily bypassed it.

The reality is that 'Real World' .Net and Java applications are insecure by design, insecure by default and insecure in deployment, because their entire security model is based on the fact that no malicious code will be executed in its environment.
...
What frustrates me (as somebody who is asked to protect systems and create secure runtime environments) is that both .Net and Java have a (sort of) workable solution in their architectures (I talking about Sandboxing). The problem is that due to a massive lack of foresight by Microsoft and the Java community, the amount of effort and focus that is currently placed in creating real-world applications that are designed to execute in these secure runtime environments in minimal.

Dinis gives two case studies of .Net and Java in web apps and rich clients. Due to the defaults being set to Full Trust (.Net) and Security manager turned off (Java) the actual security of the systems is seriously crippled, more like "faith-based" security (hoping that no malicious code is executed in its environment) than real security. When assessing designs it is important and hard to look at the capabilities of what will be deployed not necessarily the capability of what could be deployed. An architect may choose to add complexity to the system by selecting .Net or J2EE over C, PHP, Python, et al. in the hopes of gaining other qualities like integration and security. However, selecting a robust framework is, as Richard Thieme says, where it begins not where it ends. If the implementation does not leverage its security capabilities and BuildSecurityIn, then the tradeoff is balanced towards complexity without gaining in quality.

Update: Brian Snow of the NSA points out the hazards in the faith based approach:

We will be in a truly dangerous stance: we will think we are secure (and act accordingly) when in fact we are not secure.

This neatly summarizes why we need assurance.