As someone who visits companies to tell them how to fix their software before releasing it, I can tell you categorically that this is not true.
Companies that produce code in dynamic languages like PHP, Ruby, Python compared with languages like C#, Java or even C++ tend to have lower quality formalized testing and lower quality overall software.
Then we clearly don't work for the same companies. The outfits I'm familiar use Groovy and Ruby based frameworks for front/back end testing and are dab hands with all kinds of mocking frameworks. They also use continuous integration and are pretty formal in much of the stuff they do. Bad practice is bad practice and has nothing to do whether the language is dynamic or not.
For me, it's a question of discipline.
Even worse is the fact that languages where the distinction between code and data becomes blurry (such as whoever thought you should upload files and put source code to be executed both on the filesystem should be shot - as should the person who thought SQL ever being a string that you can glue together at runtime, or the guy who thought HTML should be uncompressed, unencrypted, human readable and have badly defined parsing rules) are vastly more likely to have critical security bugs.
Not sure what any of that has to do with the price of bottled air to be honest.
Again, bad practice and nothing to do with the language itself. There's nothing to stop anyone doing the same sort of nonsense in statically typed languages. No one I know builds SQL strings on the fly; we've had ORM frameworks to do that kind of lifting for quite some time.
I hate to say it, but when I review sites by equally crappy developers written in C#/.NET versus PHP, the ones written in dynamic languages tend to fall faster and harder with less effort on my part.
Well that's where our experiences differ. Most website crashes I see are .NET related, usually database errors that haven't been caught.