Why ASP.NET MVC is 'insecure by design' , just like Spring MVC (and why SAST can help)

In the recent Secure coding (and Application Security) must be invisible to developers post Joshbw posted this great comment on the reasons why we end up with 'insecure by default Frameworks'

'...On top of that the frameworks are being developed with the same mindset of all of the other products out there - "What makes the customer happy first, and then maybe if security doesn't interfere with that". A great example is that MVCs really should employ declaritive binding rather than auto binding; it really is a marginal hit to development and ensures that the only fields that can be set are those explicitely exposed by the dev. Despite this problem being known for years even MS has taken the stance that devs should opt into declaritive binding despite the fact that MVCs are default allow....'

In a way Microsoft's (and Spring's) decision to chose the insecure default (see Spring MVC Autobinding Vulnerability) is probably the correct business decision. 

Choosing the secure alternative, would introduce a hit to development (Joshbw thinks this would be marginal, but I'm not so sure), which these Framework developers felt could create a bad user experience (their users are the developers) and could potentially drive away users into other frameworks that had such 'by default' AutoBinding features.

This is why I say that We need Security-focused SAST/Static-Analysis rules so that we can deal with the cases where AutoBinding creates vulnerabilities.

In fact, a good example of security adding value to developers would be if those SAST rules (via an security engine) would actually automatically introduce those 'Declarative Bindings' without requiring a developer's intervention (this could happen behind the scenes , 'invisible' to a developer, unless that was creating business impact (i.e. side-effect).

To see an example of what this could look like, take a look at The future of secure code? Fixing/Encoding .NET code in real time (in this case Response.Write) 

On the commercial SAST front, as far as I know, only Armorize ventures into this 'code fixing territory'