If team principals are mostly young and don't have exposure to very specific kind of experiences dealing with threat modelling, then the security work will always take a backseat to feature-building. It's how humans work - it's hard to cut time from nice visible things and dedicate it to a hypothetical (at that point) abstract goal like security. Everyone agrees that the latter is important, but it just never ends up getting any oxygen. What's worse, if the team does not know what tightening systems feels like, they don't even know where to start. No "muscle memory" for it.
Maybe at some point we'll get more baseline collective wisdom about it throughout the industry, but it will also take the people signing the cheques (CEO, investors) having a bit more (justified) paranoia and respect for these priorities, and consequently requiring them from the outset. And DevOps has little to do with it - security has to be established as a priority from the leadership levels on down anyway because it necessarily means reducing time spent on more immediately-visible things.
We are not talking about some complex interactions between multiple components which lead to a security vulnerability. This is some trivial stuff like "don't give your passwords to anybody" or "don't run everything as root".
The most complex vulnerability mentioned in the article is with proxying. If you have opened /etc/squid/squid.conf at least once you should have noticed the to_localhost ACL and the comments which explain why it is important. So is the Pocket team building a multi-million user service which has a proxying component without trying to configure squid once? Absolutely!
Also I consider too optimistic hoping for the situation to improve - it's moving in the opposite direction for now with steady speed.
If team principals are mostly young and don't have exposure to very specific kind of experiences dealing with threat modelling, then the security work will always take a backseat to feature-building. It's how humans work - it's hard to cut time from nice visible things and dedicate it to a hypothetical (at that point) abstract goal like security. Everyone agrees that the latter is important, but it just never ends up getting any oxygen. What's worse, if the team does not know what tightening systems feels like, they don't even know where to start. No "muscle memory" for it.
Maybe at some point we'll get more baseline collective wisdom about it throughout the industry, but it will also take the people signing the cheques (CEO, investors) having a bit more (justified) paranoia and respect for these priorities, and consequently requiring them from the outset. And DevOps has little to do with it - security has to be established as a priority from the leadership levels on down anyway because it necessarily means reducing time spent on more immediately-visible things.