But that was because no one told them. Now they are told and taught. A lot of systems Warn even for opening something publicly... And yet.

I check all CVE's of the software my clients use because we need to figure out why things are broken and often this is a start -> unpatched CVE's. Most (by far) CVE's are not 'honest mistakes' or missed corner cases because rocket-science; they are just sloppy programming. Something that should never pass review. We DO know better but people ship things and hope for the best (including the case in this post etc).

> But that was because no one told them. Now they are told and taught.

That's precisely my point.

> Most (by far) CVE's are not 'honest mistakes' or missed corner cases because rocket-science; they are just sloppy programming.

This is actually true, but it's true because we have way better tooling and safer languages, which means we don't see nearly as many buffer overflows or memory management issues.

It's not that you didn't have negligent programmers back then.

> Something that should never pass review. We DO know better but people ship things and hope for the best (including the case in this post etc).

That's not new though. We've seen similar things happen in the past multiple times.

20 years ago code review was literally a bunch of meetings in a room or talk with another developer in person. Having something like github where you make a pull request, passes the automated test suite and requires a code review, etc. simply wasn't done. If in 2005 that already existed it was extremely bleeding edge.

I do have concerns about the code quality issues introduced by the abuse of LLMs, but until right before that was a thing, definitely the code quality in general has improved a lot.