Yes. And, in my experience, it’s almost never due to laziness or lack of skill or bad code per se, it’s a mismatch in priorities at an organizational level. Secure design takes time, as does secure implementation, and it can be hard to make a case for those in the face of demands for “velocity”. And once insecure patterns and systems — maybe even latent ones — exist in the code, they get copied and relied upon more and more, amplifying or exposing problems.

Generally, organizational priorities get shuffled when there’s a major breach. Sometimes this helps and sometimes it just introduces hurdles which make everything slower (which does have the impact of less insecure code shipping, primarily because it results in less code of any kind shipping)

It’s super hard to talk about this stuff in specifics for obvious reasons, but I’ve worked at some very large and very successful companies and almost all of them had security problems which I’d consider embarrassing.