Rebuilds that reduce risk rather than add it
How regulated teams handled a forced rebuild cycle, and the findings backlog AI scanning left behind.
In this recap
The room
Five practitioners, high above the city. An executive director from an investment bank, a CI/CD platform lead from a building society, an enterprise architect from a large public sector body, a senior engineering manager from a finance software firm, and an AI lead from a professional services firm. Two further participants from the technology supplier side completed the table.
The session ran under Chatham House convention. Everything below is reported without names or organisations.
Worth stating up front: the recording came back without speaker separation, so attribution was reconstructed from the attendee list, the introduction round and passages where the speaker was unambiguous. Anything that could not be tied to a person with confidence sits with the themes rather than being given a name.
The facilitator asked everyone to place their own maturity and their organisation's on a scale. Nobody put themselves or their employer near the top. That set the tone for a notably unguarded morning.
Six hundred findings and nobody to tell
The most concrete number of the day, and the one that made the rest of the conversation land.
One participant had run AI-driven scanning across his department's codebase: roughly six hundred findings across around fifty repositories, held by a team of about thirty people. The scanning worked. That was the problem.
The detail that stopped the room was what happened to the output. The findings could not be shared widely for fear of causing panic. So a programme that succeeded at surfacing risk produced a result that had to be handled carefully rather than distributed, which is a strange place to end up and nobody pretended otherwise.
Underneath it sat a cost that gets discussed less than it should. Both finding and fixing consume compute, and the bill scales with the ambition. Set against the value of surfacing vulnerabilities nobody knew about is the operational burden of triaging hundreds of findings, and that burden competes directly with delivering anything to the business. Several people said a version of this. Remediation is not free capacity. It comes out of the same team.
Nothing older than ninety days
A regulatory expectation in financial services, discussed at length: production software rebuilt on a rolling basis so nothing in the estate is older than ninety days, alongside shortened remediation timelines for disclosed vulnerabilities.
Nobody in the room disputed the intent. The argument was about whether it works.
Does a forced ninety-day rebuild cycle reduce risk, or does it manufacture new risk every quarter?
The case for is that a rebuilt artefact picks up patched dependencies automatically, and an estate that rebuilds routinely can respond when something urgent lands. The case against is that every rebuild pulls in fresh dependencies and compiler changes that were not there before, so a known-good artefact is replaced on a schedule by one nobody has run in production yet.
The harder edge of it is legacy. Older banking services can only be patched inside limited windows because patching means customer downtime. A rolling ninety-day expectation and a system that can be touched twice a year are not compatible, and no one at the table had reconciled them. One organisation was tracking the gap on a per-team technical fitness dashboard, which at least makes the exposure visible even where it cannot yet be closed.
When the fix is the risk
The story that everyone reacted to.
An AI-generated fix uncommented code that had been deliberately left commented out and incomplete. The vulnerability was addressed. The system moved from a known state to an unknown one, and nobody noticed at the point of the fix.
The point was pushed further from the other side of the table. An automated fix can convert a known risk into an unknown risk and hand it to a different team, who inherit something they did not create and cannot see. That is worse than the original finding, because the original finding at least had someone's name against it.
A reported vulnerability is not the same as an exploitable one, and the industry is incentivised to blur that distinction.
A position argued in the room, reported without attribution.
This was the closest the morning came to a challenge of the whole scanning premise. If volume is being driven up by tooling, and the tooling is sold by people who benefit from the volume, then triage capacity is the real constraint rather than detection.
Should an AI be allowed to remediate what it finds, or only to report it?
The disagreement was about where the line sits rather than whether there is one. One organisation committed to AI observability across the whole lifecycle on a strictly read-only basis, which is the most conservative position anyone described, and the one with the clearest rationale behind it.
Knowing where a component actually is
Framed by one participant as the question his tooling cannot answer: where does this vulnerable component sit across my estate, including everywhere it is not currently running?
Commercial scanners report what they can see. They do not cover the repository holding code that has not been deployed, or the container build sitting ready for a release that has not happened. For audit and for remediation, that gap is the whole job.
A software bill of materials is only a manifest. It is not magic.
A position argued in the room, reported without attribution.
The same participant was precise about what he wants AI for, and it is not code generation. It is analysis: watching the whole toolchain and flagging what looks strange. Monitoring repositories for unexpected behaviour came up alongside credential theft against source control, with a recent breach at a major code hosting platform cited as the reason it is no longer theoretical.
His committed approach was worth recording. Read-only observability across the lifecycle through standard interfaces, plus a nightly build that confirms he can still stand up a fresh machine or database and have it come back green. That last one is unglamorous and tests something most estates assume rather than verify.
Central platform or roll your own
The tension that ran under everything else, and the one where the organisations at the table were at visibly different points.
One described his firm as an archipelago. Every team its own island, each with its own governance and its own process, contrasted with a single co-ordinated landmass. The CI/CD process was roll-your-own and the tooling function underfunded, in an organisation heavily regulated enough that third-party images and code cannot be brought in without real friction. Both of those things being true at once is the actual problem.
Another was midway through the opposite move: from local practice, where each team owned its own controls, towards central enforcement through a shared factory and pipeline. His framing of how to do that without a revolt was the most quoted line of the morning.
Make it easier for teams to do the right thing, rather than harder to do the wrong one.
A position argued in the room, reported without attribution.
The corollary he added is that these functions have to be productised. A central capability that behaves like an internal project rather than a product will be routed around by the teams that are good enough to route around it, and those are exactly the teams whose adoption makes it credible.
Scale changes the answer. One participant made the point that in a small organisation a lead architect has genuine visibility and control is straightforward. In a large one with many independent lines of business, the difficulty is finding anyone looking horizontally across all of it, which is a leadership problem before it is a tooling problem.
Policy as code, and the patch wave
Where the room got practical.
The controls discussed were specific: express policy as code rather than as documentation, block packages that are too new or known to be malicious, and set an age threshold below which a package will not be accepted, on the reasoning that supply chain compromises tend to surface in the first days after publication.
The argument on shape was that policy should be many small, inspectable policies rather than one monolithic one. A single large policy cannot be reasoned about, cannot be tested in isolation, and becomes something nobody wants to change.
Behind all of it, an expectation the room shared: a sustained wave of patching is coming as AI surfaces more vulnerabilities, and remediation capacity is what will run out first.
Where the room pulled in different directions
Four questions left the room open, and each one is a live decision somewhere.
Whether a forced ninety-day rebuild cycle reduces risk or introduces it, and what to do about the legacy systems that cannot participate either way.
Whether AI should be allowed to remediate what it finds, or confined to observation and reporting. Nobody defended unattended fixing, and nobody drew the line in the same place.
Whether central enforcement or team-owned pipelines produce better outcomes, with organisations at the table moving in opposite directions on it.
Whether the rising volume of findings is signal or noise, given that a reported vulnerability is not necessarily an exploitable one and the tooling that generates the volume is sold by parties who benefit from it.