@Ray7:

I don't particularly want to get into a game of ideologues. I understand that it is possible to write insecure code in both. What I'm saying is that in my experience of working a security professional, companies that write dynamic code write code that is worse.

I don't even really care why they write worse code. The simple fact is just that they do.

Seriously - find me a pentester who will argue that websites written in PHP are generally more secure than those written in C#/.NET and I'll eat my hat. Or find me an industry leader who thinks that their next big product will be written in Python instead of Java.

If your company does use PHP and other dynamic languages and is very proud of their record of "no bugs - everything is safe", I would strongly encourage you to get an independent security test done. You have seriously no idea how many PHP programmers with "secure" and "thoroughly tested" websites I upset in any given week by showing them their client's data sitting in my database rather than theirs.

Let me put it this way. If SQL were precompiled, nobody would even think to glue attacker controlled strings and pass them to SQL and so SQLi wouldn't exist (when was the last time you wanted to glue LINQ expressions with a "+"?). If HTML wasn't a string, XSSes would be hard to introduce, not easy (when was the last time an XSS-type bug was found in a Silverlight pre-compiled app or a WinForms program?).

If eval() wasn't there, code injections in PHP would take really really dumb code to produce (like how it's deliberately hard to write an eval in C# - and it's pretty obvious your Doing It Wrong when you do), not just a half-assed attempt at a filter and a prayer next to that code injection bug. And if people didn't put their code on the filesystem next to their upload directory, they probably would have fewer code execution bugs on their website.

So anyway, I think the answer is just that it "just being a matter of discipline" is just wishful thinking. Developers don't have discipline, they have deadlines. And languages that make it easy to write critical bugs (say, by allowing you to glue strings together and call them SQL statements, or by including an eval function in your language) makes it easy to turned stressed out developers into critical bugs.

That's probably why languages where writing bad code takes longer than writing good code tend to do better in security reviews.