This list is correct but mostly obsolete and heavily dependent on your technologies of choice (and how well you use them).
For example, half of the first bunch (Insecure Interaction) are automatically covered for if you use (properly) a framework like Rails. The resource management bunch is also pretty much irrelevant if you're using a dynamic language like ruby.
The last bunch is the most relevant today, but those are hardly "programming errors". They are security design shortcomings... i.e. things that a security-minded application architect will be aware of, but that you need to think long before you write any code.
Most of "Insecure Interactions" is still a serious issue with Rails. It's very easy to wind up with XSS, SQL Injection, and XSRF in Rails apps; to avoid them, you not only have to be using Rails, but using Rails right.
The simple cases for all of these are automatically eliminated with Rails; for instance, searching for "O'Malley" in a search box isn't going to trigger SQLi. But somewhere in any large-ish application, someone is going to do a custom join or a complicated conditional, and that brings SQL input validation along to the party.
Same deal with XSS. Rails gets rid of XSS, if you (a) default to h() style filtering and never override it, or (b) rigorously audit your code. But most large applications have code paths where something other than Erb is generating HTML (for instance, some library may use HAML to generate a report), and those code paths often escape output filtering.
I'm not trying to stick up for the CWE 25; I think most of these lists are pretty silly. What they're really intended to do is to help enterprise programmers feel like they have their minds wrapped around the software security problem, so that they have a place to start. Other lists, particularly the (equally outmoded) OWASP Top 10, have succeeded spectacularly at that.
First, this is like saying C takes care of buffer overflows:
1) buffer overflow - programmer - count
Conservatively, that action item cost the industry over 5 billion dollars. So, generally, "bad programming: use good programming" is not an effective answer to security.
Second:
(3) Fails on complex queries and query builders all the time; there are situations where you can't parameterize everthing that varies in a query.
(5) Would have precluded Github, which used `` expansion in its first revs to invoke git.
(8) First, Rails isn't single-threaded anymore, and second, you can end up with race conditions at the database layer if you aren't careful with transactions and isolation levels.
(9) Is only true if you not using any unaudited C extensions; quick, tell me how many of the gems you brought in have an ext/ directory with code in it?
For example, half of the first bunch (Insecure Interaction) are automatically covered for if you use (properly) a framework like Rails. The resource management bunch is also pretty much irrelevant if you're using a dynamic language like ruby.
The last bunch is the most relevant today, but those are hardly "programming errors". They are security design shortcomings... i.e. things that a security-minded application architect will be aware of, but that you need to think long before you write any code.