At work we have a lot of customers now, many of them with large security orgs. Their approaches vary a lot, presumably because of their experiences and security maturity.
Beyond a certain level, there is always a security org and quite typically it has veto powers that override any local manager's budgetary concerns. Whether that veto is applied well is quite distinct from the way it creates a ceiling over potential spending on features.
That all said, I agree that there are fundamental properties of security that will cause it to be consistently under-attended relative to what a more actuarial or financial model would suggest is rational. It is only observable in its absence, but most feedback systems -- formal or informal -- rely on observable signals. Market releases may lead to a juicy bonus at many companies. Invisible improvements won't.
I've thought about this a lot in the past few months and published a bunch about it internally at Pivotal. I'm not alone, of course. We're streets ahead of many vendors, but I also feel we're only getting started on the deeper and more difficult process of blending it deeply into our cultural DNA. It's a culture which believes in doing the right thing, but also a culture which detects vetoes as faults and routes around them.
Interesting times.
There are many vendors attacking this exact problem from many directions, including my employers[0], but pretty much every platform vendor has something here.
I do agree that automation and risk are at the root of the tension between security and stability. It's a feedback loop that can run in two directions. If you embrace stability, the loop becomes "no changes ever" and security becomes much more difficult to achieve in practice. If you embrace security, then at first you face instability -- but embracing rapidity and building out tooling for it makes you both more secure and more stable in the long run.
> But its not like actuaries have a lot of data to model to the point of accurately imposing a cost per day of unpatched CVE.
I'd be interested to know if this is actually true.
I recently got interested in the FAIR risk modelling approach. It requires a bunch of legwork, so in practice it won't catch on without determination to use it or something like it.
Usefully it breaks risk down into more easily-estimated, easily-tracked subcomponents[1]. "Probability" becomes "Loss Event Frequency", which further breaks down into Threat Event Frequency and Vulnerability, these break down further in turn. Similarly, the usually-vague "Impact" becomes Primary Loss and Secondary Loss, each of which has 6 specific types that can be estimated. Those estimates can be based on available data, whether your own or industry statistics.
> Worse, many places have competitors, and if they're choosing to take on risks in the name of lower prices and higher market share, the customers of your secured app walk out the door.
[0] I work for Pivotal. We've been building towards the vision of "Rotate, Repair, Repave" in Cloud Foundry: https://builttoadapt.io/the-three-r-s-of-enterprise-security...
[1] https://cdn2.hubspot.net/hubfs/1616664/The%20FAIR%20Model_FI...