Makes sense, thanks. I'm not sure how anyone could suggest that vulnerabilities don't exist if you use a memory safe language. That's just demonstrably/factually not true...
I'm reacting to the actual post, not the comment thread. The post sets out to teach software developers about "software security", and its answer to that problem is "use Rust and validate user input". I mean, using Rust will at least actually help. But it's nowhere close to a synopsis of the whole problem.
It's a single course. I think no one, not even the author, expect a single course to cover enough ground to ensure that students can write secure applications moving forward. For instance, the author has a "formal verification" category on their blog: http://www.pl-enthusiast.net/category/formal-verification/
And I'm critiquing the premises of the single course. What's your point?
I've talked to more than one university professor in the last 2 years about what a first and second course in software security should look like, and if there's a theme to my feedback, it's "not like this; this is what people thought it might look like in 1998".
You appear to critique the premise that most security comes from using the right programming language and observing a few patterns, like validating all inputs.
I was saying this is most probably not the premise of the course. That just like you, they don't believe they're teaching a panacea, just something that will help.
That assessment could be wrong, though. Unlike you, I never discussed security with university professors, and I know nothing of their misconceptions. Could you offer a gist of what they teach, and most importantly what they should be teaching instead?
And indeed, most security doesn't come from using the "right" language, nor is "validate all inputs" especially helpful advice (in fact, it's distinctively unhelpful, and is at times actively misleading). You can certainly use the wrong language, and that will harm your security, but for the most part almost nobody writes C anymore.
