Let me rephrase. Yes, you can incorporate security into a language as features. For example, buffer overflows are impossible to do in Perl. But, integrated memory management wasn't incorporated into Perl for security reasons - it was added for programmer productivity. As a side benefit, an class of security issues is now avoided.

Many security issues, such as SQL injection and cross-site scripting, have to do with the interfaces between components. SQL injection occurs when a legitimate SQL statement is hijacked to do something that is legal and often useful SQL, but disastrous for the application depending on that SQL. The bug isn't in the database, SQL, or the application. The bug is in how the application constructs SQL based on user input. The same goes for cross-site scripting for how the application constructs URLs based on user input.

I would put forward that 90% of all security issues are in how one deals with outside input. SQL injection, XSS, and buffer overflows all fall into that category. Dealing with outside input isn't a language issue, it's a design (or process) issue. Language features can help (tainting, automated memory management, placeholders, HTML escaping, etc), but not only can every safety feature be disabled, but they have to be used to be of benefit.

Or, put another way, a computer language cannot be designed to safely deal with all outside input, in large part due to the Halting problem. I would love to see an argument against that statement, but I don't think one can be made.