An old line with a new interpretation

There is a line in the security industry that has been true for as long as most of us have been writing software: security through obscurity does not work. The Register has now put a rather more interesting interpretation on it. Jessica Lyons, writing on 13 September, argues that security through obscurity is dead, and AI delivered the fatal blow, on the fairly obvious grounds that AI has changed the economics of finding vulnerabilities. The amount of software that can be examined, the speed at which it can be examined and the ability to turn a discovered weakness into something actionable have all changed at once.

I think there is a bigger lesson sitting underneath it. AI has not just made it easier to find bad software. It has made it much harder to pretend that we can get away with shipping it.

That matters because the software industry has spent thirty years optimising for one thing above almost everything else, which is time-to-market. We talk about delivery velocity, deployment frequency, lead time, sprint commitments and release cadence, and we have built entire engineering disciplines around reducing the time between an idea and something running in production. That is good work and I would not undo any of it. The problem is that we have never really built an equivalent measure for the quality of what arrives at the other end.

Last Tuesday was a useful demonstration

On 8 September Microsoft released its September security updates, and the numbers are difficult to ignore.

There is an understandable temptation to look at a number like that and conclude that Microsoft has a security problem. I do not think that is the useful conclusion. The useful conclusion is that the industry now has an industrial-scale problem discovery mechanism.

Microsoft is not uniquely incapable of writing secure software. It is one of the largest and most heavily scrutinised software producers on the planet, with enormous engineering resources, dedicated security teams, automated testing, threat intelligence and increasingly sophisticated AI-assisted vulnerability discovery of its own. And it still had the better part of a thousand vulnerabilities to fix in a single monthly release. That should make all of us slightly uncomfortable, not because Microsoft is failing, but because the old model of software quality is being exposed.

AI can now search software for weaknesses at a scale and speed that humans simply cannot match, and The Register's argument about obscurity follows naturally from that. The hidden corner of the codebase is becoming considerably less hidden. The consequence is that the period between something being wrong and somebody knowing something is wrong is getting much shorter.

We have optimised the wrong side of the equation

This takes me back to something we wrote recently in Who Watches the Watcher? The DevSecOps Dirty Little Secret. The uncomfortable observation in that piece was that controls are not controls simply because somebody wrote them down, and we used our own example rather than somebody else's. We had a security gate that existed, had been tested, and would have caught the class of problem it was designed to catch. It just was not initially wired into every pipeline. Written, tested, and enforcing nothing.

That is not a theoretical problem. It is what happens when delivery pressure wins, and it is the part of DevSecOps I think we still do not discuss honestly enough. Time-to-market has always had a number attached to it and quality has not. A release that goes out on Tuesday rather than Wednesday is trivially easy to measure. A release that contains fourteen fewer defects, has better traceability, carries fewer undocumented exceptions and has stronger evidence behind its security controls is considerably harder to express in the same language. So when the two come into conflict, the same one tends to win. The deadline has a date. Quality has a discussion.

AI attacks that imbalance from both directions

The genuinely interesting thing about AI here is that it does not simply sit on one side of the problem. The good news is that AI can help us write software faster. The bad news is that AI can also examine software faster. The very capability that increases our ability to produce code increases somebody else's ability to inspect it, and that is not a temporary security problem. It is a permanent change in the economics of software.

If the cost of finding a vulnerability keeps falling, then relying on the fact that nobody has found yours yet becomes a progressively worse strategy. Security through obscurity was always a weak defence. AI makes it an increasingly ridiculous one.

There is a second consequence that gets less attention. If we can find defects faster than we can fix them, the bottleneck moves. It moves from discovery to decision. Which problems matter, which ones block the release, which ones can be accepted temporarily, who made that call, what evidence supported it, and what has changed since. And underneath all of those, the question that actually matters: did we know the quality of the thing we shipped?

That is the discovery-to-decision problem rendered in numbers. Almost none of it was an attack, most of it never reached a human, and the volume grew nearly sevenfold in five months. You can read that as a triage success story, and in fairness it partly is: nobody wants analysts hand-sorting sixteen million alerts. You can also read it as a system quietly making a very large number of risk decisions on the organisation's behalf, at a rate and volume that nobody is in a position to audit afterwards. The number I would want is not how much got suppressed. It is whether anyone could reconstruct why.

This is where compliance gets interesting

It is also why I am increasingly sceptical of the way we traditionally think about compliance. Compliance has become associated with paperwork, auditors, spreadsheets and somebody turning up six weeks before an assessment asking whether we have evidence that something happened. That is the wrong model. The useful part of a compliance framework was never the document. It is the accumulated organisational knowledge about what a good system should look like, what needs to be controlled, what evidence should exist, and what ought to happen when reality does not meet the requirement.

That is why we built the AppGenie Compliance MCP. The point was never to produce another compliance document search engine. The point was to make the rules part of the delivery environment. It exposes a controlled standards catalogue to AI assistants and returns rather more than an answer: a delivery question can produce the applicable profile, the required controls, the evidence that should exist, the registers that need updating and an enforcement decision, with the underlying sources identified. That changes the role of compliance from something that arrives afterwards to inspect engineering into something that can participate in it.

Quality needs to move left, but not in the way we usually mean it

Shift left has become one of those phrases that everybody uses and almost nobody defines. Usually it means test earlier, which is useful but nowhere near enough. The bigger shift is to move the quality decisions into the delivery process.

If a vulnerability is discovered, the pipeline should not simply produce a red dashboard. The system should be able to establish what the vulnerability is, which version is affected, whether the affected artefact is actually being released, what remediation exists, whether an exception has been approved, what risk remains and what evidence supports the decision. If the answer is that we are releasing anyway, that can be a perfectly legitimate business decision. But it should be a decision, not an accident.

The compliance overlay we use internally reflects that. The evidence expected around controlled delivery includes change traceability, artefact version traceability, integrity evidence, change-control evidence and vulnerability remediation evidence, and where remediation is delayed or excepted that becomes an explicit risk record rather than disappearing into somebody's inbox. It is a much more useful definition of compliance than asking whether the form was filled in. The question is whether we can demonstrate why this thing was allowed to ship.

The real race is changing

For years software companies competed on who could get a feature into production first. Then we discovered that deployment frequency mattered, then that automated testing mattered, and then DevSecOps taught us that security needed to be part of the pipeline rather than a gate at the end of it. I think the next step is different again. We need to compete on quality-to-market: not quality instead of speed, but quality at speed.

That means the delivery system itself needs to understand enough about the organisation's engineering standards, security requirements, compliance obligations and accumulated experience to make quality part of the delivery decision. This is the same argument we made in What Does Your Organisation Know?, which is that the knowledge only becomes useful at the point where it can act on something.

The alternative is increasingly uncomfortable. AI will continue making us faster at producing software, and it will continue making everyone else faster at finding what is wrong with it. Organisations that respond by adding another security scanner, another dashboard and another spreadsheet will eventually discover that they have automated the discovery of problems without automating any of the decisions around them.

The better response is to make quality executable. Put the standards where the engineering happens and the evidence where the decision happens. Make exceptions explicit and controls enforceable. Make the release carry its own evidence. And make the organisation's accumulated knowledge available to the machines that are now doing a good deal of the work.

The question is not whether you can ship faster

We already know the answer to that one. AI is going to make us dramatically faster. The real question is whether we can make good decisions at the same speed.

Microsoft's September release is a useful warning precisely because the numbers are so large. Nearly a thousand vulnerabilities in a single release is not simply a story about Microsoft fixing software. It is a glimpse of the environment every software producer is moving into. The machines looking for defects are getting faster, the machines writing software are getting faster, and the window in which something can remain hidden is getting smaller. The old advantage of shipping quickly and fixing things later is becoming progressively more expensive.

We spent decades building DevOps around a single question: how quickly can we get this into production? The next generation needs to ask a second question with exactly the same seriousness. How do we know this is good enough to go there?

That is not compliance after delivery. That is quality-to-market.

• Who Watches the Watcher?
• What Does Your Organisation Know?