@hazelweakly
Ah, yeah — security governance and compliance absolutely have those mindsets. They're obviously not exactly separate from security engineering in practice, but if security engineering isn't what's driving security practice the result will not be a secure system but a compliant one. This doesn't mean that governance, compliance, and regulation are bad, but they have to be engineering tools more than management tools — a way to drive specific engineering outcomes. If they're serving two masters, they don't really work.

From an eng management perspective, there really is not yet any substitute for experienced security engineers being deeply involved in system design and development from day one. If you have enough time and money, you can build up tooling and guardrails and rebuild your way out of it, but that's exponentially more expensive for a given degree of (unmeasurable until you're at the top of the chart) security quality. This applies equally to non-dev security practices.

@hazelweakly
In the more general case, I think the only answer is a combination of liability and public funding. If companies start to be liable for direct customer damages, the incentive structure for building systems changes a lot. Then, public funding that treats open source software as a public good and pays for maintenance and audits of critical tools, along with specific funding of tooling to make it easier to build secure systems, including, as stuff reaches some level of community acceptance, funding to move existing systems over to the new tooling.

We see little baby efforts from the EU for this, but relatively little on the ops-ish side. The hyperscalers have shaped the way we think about operating systems, but the public products they provide are designed with making money as a higher priority than making it easier to operate secure systems — and they've starved the options for folks not operating in their clouds, because raising the bar to going on prem is a core part of their business model. There's a huge opportunity for public funding to change that, especially in the light of the digital sovereignty conversation.

In the end though, there's no way to do this without companies accepting that they're not going to be able to write as much code. But if your business model only works because you're polluting the world with negative security outcomes that you treat as an externality, then your business model shouldn't work.

@hazelweakly
The national security thing is I think different. The core goal of the state is to survive, and the primary survival tool of the state is control, so states always want to control everything they can control that could impact their survival. So the driver for universal surveillance isn't that it's going to improve state security, it's that universal surveillance is now possible. If in thirty years we end up with brain implants becoming common, then in forty years we're going to be having a debate about whether freedom of thought is compatible with state security, and the answer of the state, sooner or later, is going to be no.

This calculus means that it doesn't really matter if new surveillance is going to work, let alone be efficient. Just as many companies try to do quantitative security tracking when they don't and likely never will have quantitatively meaningful data, because governance is supposed to be about risk and that means we have to have numbers, so by god numbers we will have, the state does the same. Better yet, the state gets to never actually tell you what the numbers are. "Critical for national security" is a magical formula, not an analytic outcome.