and the problem there (as I see it) is that they don't care about security, they care about passing their audit.
"Passing our audit" has been presented with measurable consequences (cannot sell to customers) and finite, well-defined actions (this is what the audit list looks like).
What I'd like (the goal of the follow up article, coming soon) is to present the value of security in a way that makes the justification of the effort viable and palatable.
Those are great points. And what you're saying is why I used the "nobody cares about backups" analogy.
It's NOT that nobody cares about the results of security. It's that those results ("not losing our sales database")are often not presented clearly or coherently enough for the decision makers to recognize the value of the activity ("doing regular backups, paying for offsite storage, etc.")
I don't think this is true. The opposite, really. I think that we continue to present security as a "shift left" ("SHIT left") strategy, dumping the responsibility on devs without any framework for why they should care.
But if we built a culture and practice that low-security code is low-quality code, and made security issues a software defect like any other, it would get handled. Plenty of developers (and leads, and PMs) are fine with shipping low-security code, but would fight to the death if accused of shipping low-quality code.
"more on this" got pushed to the follow-up piece, which is coming soon. Sorry to keep you in suspence. I had to balance people's time to read with the length of the information I was sharing.