Golden paths engineers will actually take
How engineering leaders made the secure path the natural path, and where engineers still routed around it.
In this recap
The room
Around a dozen senior engineering leaders. Platform engineering leads, directors of engineering, principal engineers and an enterprise architect, drawn from two large banks, a building society, a markets and trading business, a savings platform, a pension insurer, a treasury technology provider, a non-bank lender, a policing organisation and a greenfield technology company. Two further participants from the technology supplier side made up the rest of the table.
The session ran under Chatham House convention. Everything below is reported without names or organisations.
Financial services dominated, but deliberately not exclusively. Having a policing organisation and an early-stage company in a room otherwise full of regulated finance is what stopped the conversation collapsing into a single set of assumptions.
From trust to evidence
The facilitator set the frame at the start and it held all morning: securing a software supply chain means moving from trust to evidence. Being able to prove where code came from, who wrote it, what it carries, and where it is running right now.
The reference point everyone reached for was the industry-wide scramble after a critical logging library vulnerability, because it exposed how hard a simple question is to answer.
Is this library running anywhere in my estate, and if so, where?
The question the room kept returning to, reported without attribution.
The corrective offered was that scanning at the boundary is not enough. Knowing what was approved at build time tells you nothing about what is actually running now, and the gap between those two is where the incident lives. Several people were moving towards trusted, curated base images as the practical next step, on the reasoning that provenance is easier to establish at the bottom of the stack than anywhere above it.
The honest assessment in the room was that most organisations are still early in this, despite years of investment in delivery tooling. Nobody presented as finished.
Audit as the forcing function
Audit, internal and external, was named repeatedly as the thing that actually releases budget and attention. Not risk appetite, not strategy. A deadline.
One participant described the familiar cycle: an audit finding exposes gaps in privileged access control, and the organisation sprints to remediate before the next assessment. Another offered a more constructive reading of the same mechanism. Internal audit findings function as a positive forcing function, because a break you identify yourself, with a compensating control already in place, is treated as a pass by most auditors. Self-identification is a strategy rather than a confession.
The most interesting idea of that section was about the format rather than the tooling. Organisations could be segmented by their audit lens: whether the primary stakeholder driving the work is an internal auditor, a regulator, or an engineering mandate. That cuts across industry verticals and groups people by what actually shapes their decisions. The room engaged with it strongly as a way of structuring future sessions.
Golden paths, golden handcuffs
A fixed, opinionated route through the delivery lifecycle with limited parameters for the engineer to configure. Nearly everyone in the room wanted one. Nearly everyone described the same problem getting anyone to use it.
Golden paths are easy to define and hard to adopt. Engineers experience them as golden handcuffs, which is a fair reading if the path is slower than the shortcut. Two organisations described getting past that, and their methods were opposites.
To get engineers onto a golden path, do you prove its value or do you enforce it?
One organisation ran the path in a single small team first, demonstrated the difference, and scaled from there: that team went from quarterly releases to around two thousand releases a month over three years. Another took the opposite route, using pipeline blockers, gamification and application scoring linked to compensation to enforce remediation timelines. Two large institutions, two incompatible theories of change, both reporting results.
The menu is the problem
The room kept arriving at the same conclusion from different directions: the hardest part is not the technology.
Engineers take shortcuts because they are paid to ship features, not because they are careless and certainly not because they are malicious. Any control designed as though the problem is discipline will be routed around by people doing exactly what their objectives tell them to do.
If developers are ordering off the menu, your menu is the problem.
A position argued in the room, reported without attribution.
The work that follows from that reframe is engineering the choice, so the secure path is also the path of least resistance. Not persuasion, not policy, design.
Technical debt sat in the same territory. The difficulty is not identifying it, it is funding work that is invisible right up until the moment something breaks badly. One model raised as having worked in large financial services environments was a deliberate, published ratio between feature development and debt repayment, in the region of seventy to thirty, held with transparency and enough discipline that it survives the first pressured quarter.
Code arriving faster than the tooling
This surfaced late and changed the temperature of the room.
One organisation had already deployed a coding assistant to more than thirty thousand engineers and was evaluating others alongside it. The same organisation was building internal asynchronous agents that could review code and raise pull requests on their own, constrained by a self-hosted source control deployment that limits some cloud-native agent capability.
Then the incident that made it concrete. A product manager used an AI coding agent authenticated with a personal access token, and company data went to an external service. No malice, no sophistication, just a gap between what the tooling could reach and what anyone had thought to constrain. The mitigations discussed were sandboxing, micro-segmentation and network-level controls around AI tooling, with desktop-level sandboxes named as a workable starting point.
The broader worry was one of scale. The volume of code being generated is orders of magnitude beyond historical norms, and supply chain tooling was built for the old rate. Nobody argued otherwise.
What nobody had solved
Six problems were put on the table as active and unresolved, and they were not the same six anyone would have guessed.
Privileged access across heterogeneous platforms, in organisations built through acquisition and carrying dozens of toolchains, where mapping the access surface is itself a major project before any privilege model can be applied, and where not every platform supports it natively.
Secrets management and rotation, still a consistent failure mode at every size of organisation.
Vulnerability management at scale, with tens of thousands of open findings in production and no clear ownership model. Teams are trusted to manage their own, many do not, and centralising it creates political resistance rather than progress.
Securing agent-written code, where no standard yet exists for how code authored by an AI agent should move through a pipeline.
Funding any of it. Security investment succeeds when nothing happens, which is the hardest possible case to take to a board. Boards respond to incidents in the news and rarely fund prevention in advance of one.
And the threat landscape itself, where state-sponsored actors have shifted towards disruption and denial rather than theft, with attack patterns that are subtler and harder to see coming, and adversaries now using AI to amplify and personalise what they do.
Where the room pulled in different directions
Less adversarial than some rooms in this series, but the tensions were real and none of them resolved.
Whether adoption of a golden path comes from proving its value in a small team and letting it spread, or from blockers and incentives that make the alternative unattractive. Both were reported as having worked at scale.
Whether remediation should sit with the teams that own the code or with a central function. Teams are trusted and many do not act; centralising provokes resistance. No one had found the third option.
Whether an opinionated path with few parameters is genuinely safer, or whether it simply relocates the risk into the shortcuts engineers build around it.
Whether the honest answer to AI-generated code volume is better tooling or slower adoption, with nobody prepared to argue seriously for the second.