October 29, 2026
This blog is written by Dave Sammut and Craig Pointon, and draws on a recent client engagement they worked on closely with Tom Peck. Dave shared the story at Expert Talks, Munich: AI Security State of Play.
Earlier this year a large enterprise received a vulnerability report covering part of its legacy application estate.
There was a lot of red: old runtimes, legacy applications, vulnerable dependencies and systems that had quietly continued running long after the people who built them had moved on.
The message from the business afterwards was understandable:
We don’t want one of these vulnerabilities to make us headline news. What will it take to make this problem go away?
A technical team analysed the report and produced an action plan based on the vulnerabilities and their severity. The uncomfortable moment came when the estimates were shared. The implied remediation programme was measured in years and millions.
That was when a more useful question emerged:
Was the report actually telling us what mattered?
The report wasn’t wrong.
It accurately surfaced vulnerabilities in the estate. But it represented a single signal about a much larger system. That signal was useful, but incomplete.
Knowing that a vulnerable dependency exists does not automatically tell us whether the vulnerability is exploitable, or if the functionality is even used.
Presence does not necessarily mean exposure.
Exposure does not necessarily mean reachability.
Reachability does not necessarily mean exploitability.
And technical severity does not necessarily tell us the business impact.
Yet when time, cost and access to expertise are constrained, a report like this can become the practical boundary of what an organisation knows. So instead of asking: “How do we remove all the red?” we started asking: “Where should we invest first to reduce meaningful risk?” That opened up a very different conversation.
None of the principles behind that question were new. Before large language models (LLMs), we already had scanners, dependency analysis, threat modelling, architecture reviews, pen testing, infrastructure controls, code inspection and experienced security and engineering people. Those tools still matter. What has changed is that we now have another class of tool available to us.
LLMs gave us new ways to interrogate unfamiliar systems, explore code, reconstruct behaviour, trace dependencies and synthesise signals across a legacy estate. We used them predominantly through prompts, not autonomous agents, and we did not treat their outputs as truth. They were signposts. Engineers and security specialists still had to inspect the code, challenge assumptions and verify what mattered.
But the opportunity wasn’t only in the problem space. The same tools also began to expand the solution space. Once we understood the behaviour around vulnerable code, we could ask different questions.
That does not make changing legacy code risk-free. But it can make options viable that previously looked too expensive or too uncertain.
The toolkit has changed. So both our analysis and our response should change with it.
Once we looked beyond the report, the decision space widened. An upgrade might still be the right answer.
But perhaps an infrastructure control already reduced the exposure. Perhaps containment was more pragmatic than changing a fragile application. Perhaps, with enough stability around the code, remediation was more achievable than we first thought. Perhaps the application was barely used and should simply be switched off.
Suddenly, “fix the vulnerability” was no longer the only option. And equally, “this code is too risky to touch” was no longer automatically the end of the conversation. The report still mattered. But it became the start of the investigation rather than the end of the reasoning.
There was another problem. We now had a lot of information. Too much for a senior stakeholder who simply needed to know:
What are my choices? What happens if I choose each one? Where should I invest?
This became as much a storytelling exercise as a technical one. And storytelling matters.
We moved between different levels of detail: a headline that communicated what mattered, a narrative that explained why, a dashboard that enabled decisions, and deeper evidence for people who wanted to challenge the reasoning.
That translation mattered because security, engineering, infrastructure and business stakeholders were all looking at the same problem through different lenses.
The problem was also organisational. Security and engineering were working from different mental models: Information Security (InfoSec) could see the risk but not always the cost or complexity of remediation, while engineering understood the systems but not always the security implications. The tooling reinforced those silos by giving each side more evidence for its own view.
What changed was not just the analysis, but the creation of a shared language, one that let security, engineering, architecture and infrastructure reason about the same risk together.
AI helped us connect the evidence. But the work also forced the organisation to connect the people.
Vulnerability reports are not going away, nor should they. But it may be time to stop letting a single signal define the limits of what we know.
Historically, time and cost often constrained how deeply we could explore an estate. A vulnerability report could become the practical boundary of the analysis, not because it contained everything we wanted to know, but because gathering much more context was expensive.
That constraint is changing. We now have more ways to explore what sits behind the signal, and more ways to act once we understand it. So the question becomes:
What do all of the tools now available to us tell us about the risk, and what options do they create, both for understanding the problem and changing the system?
The report is still an important signal. But it no longer has to define the edge of our understanding.
We can go deeper into the code, the behaviour, the infrastructure and the business context, then use that insight to make better choices about what to change, contain, replace, retire or accept.
And perhaps the first thing we need to modernise is not the legacy application. It is the way we turn signals into decisions.
Dave Sammut is Head of Architecture EMEA at Equal Experts. A hands-on technical architect, he bridges business and engineering, working with everyone from senior stakeholders to developers to bring clarity and reduce risk. He focuses on using AI responsibly in real-world systems, including complex legacy estates, combining modern engineering practices with close collaboration and rapid iteration to deliver practical, measurable outcomes.
Craig Pointon is a Delivery Engagement Lead at Equal Experts with more than 35 years’ experience across software development, technical leadership, consultancy and delivery. An early adopter of Extreme Programming and Scrum, he has led cross-functional teams of up to 120 people across financial services, retail, the public sector and telecommunications. He holds a PhD based on research carried out for BT Research Laboratories and is a Chartered Electrical Engineer.
In a healthy estate, start by following your vulnerability-management and remediation policies. Our situation was different: years of accumulated legacy risk meant fixing everything was not achievable. Equal Experts treated the report as one signal, then added context around exposure, reachability, exploitability, existing controls and business impact to understand where limited capacity would reduce the most risk.
Where remediation policy can be followed, it should be. In Equal Experts’ case, the scale of legacy risk made that impossible within normal timescales. Adding context to severity showed where the meaningful risks were, and that remediation, containment, additional controls, retirement or explicit risk acceptance could each be the right response.
For Equal Experts, finding a vulnerable component is only the starting point. Present means the vulnerable component or code exists. Exposed means an attacker can plausibly interact with the relevant part of the system. Reachable means that interaction can lead to the vulnerable code. Exploitable means the conditions to trigger it can realistically be met. Each adds context; none automatically establishes the next.
Equal Experts recommends treating the estimate as the start of a risk decision, not just a delivery problem. The question shifts from “How do we fix everything?” to “What risk are we prepared to carry, and where should we invest first?”. Making costs, risk reduction, alternatives and residual risk explicit lets accountable stakeholders decide what to fund, defer or accept.
It depends on the threat model and the application context. Equal Experts security specialists can assess attack paths, existing controls, and residual risk. Options include network controls, stronger authentication, isolation, containment, additional monitoring, remediation, replacement or retirement. For fragile legacy applications, better test coverage and behavioural stability can make remediation safer. The goal is to manage risk consciously, not eradicate it.
Yes. LLMs can help engineers navigate unfamiliar code, reconstruct behaviour, trace dependencies and check whether vulnerable functionality is reachable. They can also explore upgrade paths and help generate tests before a change is made. Equal Experts used LLMs mainly through prompts rather than autonomous agents, treating their outputs as signposts. Engineers and security specialists inspected the code, challenged assumptions and verified what mattered.
Explain it in plain terms: what could go wrong, how likely it is, the impact, and how it compares with other risks the organisation already manages. Equal Experts layers the evidence: a clear headline and the decision required, a short narrative, and dashboards and deeper detail for those who want it. Translate complexity into consequences and options while minimising blind-spots.
All business models have their pros and cons. But, when you consider the type of problems we help our clients to solve at Equal Experts, it’s worth thinking about the level of experience and the best consultancy approach to solve them.
If you’d like to find out more about working with us – get in touch. We’d love to hear from you.
