Comment Re:Since these people still don't get it.... (Score 2) 79
Don't be naive... security is a deep and subtle problem, full of nasty surprises. There is no magic bullet solution... your "safe programming language" has thousands of bugs in its standard API and run-time
I think you should update your knowledge of this field. Then you should also realize that over 90% of security vulnerabilities in programs written in unsafe languages wouldn't have occurred with safe languages. And of the vulnerabilities among safe languages, 90% of those wouldn't have occurred if they were designed to be capability secure (which is just another safety property most languages ignore).
it won't prevent devs from concatenating SQL with user input
You can't do this in, say Haskell, unless you write your own SQL interface library that builds solely on strings.
misusing threading primitives
You can't do this in concurrent safe languages, like Concurrent ML, Rust and Haskell.
bungling up an authentication protocol
Session types, which Haskell can verify too. Of course, all of these safety properties are encodable in even more powerful systems, like Agda or Coq.
you must at minimum use an approach where (1) security is a primary design concern thru the entire product lifecycle, (2) security solutions are deployed in a structured/layered approach using (3) actual expertise, and (4) security is an ongoing program with both proactive and reactive elements.
So basically, safety properties have importance on par with domain requirements, and must be subject to the same rigour that domain features get, ie. testing, verification, etc. So basically, the safer the language, in the sense that the more properties can be assured at compile-time, the more features and safety properties you can verify, and the fewer security vulnerabilities.