Ask HN: Why do you think vulnerable code is still being released today?

I think you over-estimate the impact of universities. Many (perhaps most?) CS professors think of themselves as Applied Mathematicians. It's unrealistic to expect your linear algebra teacher to worry about style.

Negligence is the first. Sometimes it's even willful. "Get this out in 3 weeks under budget, I don't care how." That leads to human error, which is more likely when you have underqualified people working on unrealistic deadlines.

No one can (or should) write totally secure code. But there are a lot of simple mistakes leading to XSS and SQLi that can easily be avoided by having some standards.

Some thoughts. In my experience, the lack of vulnerable code in a secure application is not the product of savvy developers who never make mistakes. A hardened web app usually gets that way because someone took the time to find and fix some of the exploitable vulnerabilities that could be found. Unfortunately, that usually doesn't happen until they get hacked pretty hard and come to see the business value of investing in the people, process, and tools required to create a robust security program which is augmented by quarterly $10,000 PenTests.

First off, there is a never-ending tension between security and convenience. gnupg has been around forever, but any effort to get your non-computer-programming friends to use it will come up against a pretty terminal useability wall. Setting autocomplete to off on a forms login will get complaints from almost everybody. (And then MS in IE11 now ignores that setting in the password field. Bah.)

Similarly, when building applications, the goal is to make an operation more convenient or possible than it was before. And speed of deployment is an imperative as well.

The main challenge in most of today's applications is that they are highly complex and they involve browsers. Browsers are extraordinarily complex programs working to a set of conflicting, evolving standards. For illustration, I suggest reading The Tangled Web by Zalewski. (But read it early in the day--reading late at night might lead to nervous or disturbed sleep.) Or his blog post "Postcards from the post-XSS world": http://lcamtuf.coredump.cx/postxss/. Did you notice that both Chrome and IE had recently-identified remote-code execution vulnerabilities that affected all known versions?

Beyond that, applications and frameworks these days are very complex and are under that feature/security tension. There are some nice-to-have features that themselves increase the attack surface. Complex programs are hard to get right. Remember the quote from Tony Hoare: "There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult."

And what you say is true about developers not having enough knowledge to write secure code. Without consulting Tangled Web, how many of us knew that the format of a fully-qualified absolute URL is of the following form:

  scheme://login.password@address:port/path/to/resource?query_string#fragment

Did you know that the login.password@address:port section ended with a semicolon is accepted by some browsers? And that the query_string format is not specified at all?

And the advice about always using prepared statements in SQL queries breaks down if user input is needed to influence column names or table names or even database names. One of the factors pushing SQLi to #1 is that it has massive risk. One tiny error off in one tiny corner of a little-used feature of the application can lead to exfiltration of the entire database.

When Structured Programming was first talked about, a few of us real-time programmers began to think that it would be a nice idea to prove programs correct. This proved to be way to expensive. So we resigned ourselves to writing programs that we thought might be proveable.

The care/knowledge factor you mention is important at all levels of an organization. So if the founder or CEO or CTO or marketing is not buying into a security mindset, it can be tough.

(Disclaimer: I help software companies with this sort of technical/cultural problem.)

As a PHP developer, I've definitely seen a massive decrease in the number of people who are just passing queried values directly into the construction of their SQL string as people have started emphasizing using prepared statements.

But this has done nothing towards stopping people from passing column/table selections directly into those strings. It seems as though everyone is using prepared statements now because they were told to not because of any kind of understanding of why.