ProjectMetrics

Project delivery in a constantly changing World

We Didn’t Write the Code, But We Own the Blast Radius

by · Published · Updated

Last month, government agencies in the Netherlands and Finland, among others, took websites offline to protect them from software flaws that had been buried in widely used code for 14 years. It is a vivid and expensive example of something project managers deal with every day without naming it: technical debt.

Ask a room of project managers who owns technical debt and you will get an awkward pause. Engineers think the business created it by squeezing the schedule. Sponsors think it is housekeeping that engineers should sort out in their own time. Meanwhile, almost every delivery plan quietly borrows against it.

PM’s Managing technical debt

We need to reframe how we talk about technical debt and third-party dependencies. Right now, leadership treats technical debt like an engineering confession—a backlog item for developers to clean up. This is no longer an engineering problem.

In reality, technical debt is a delivery and security risk, and every risk requires a named owner. Consider vulnerabilities that originate deep in our vendor or open-source stack (like a foundational language or library flaw). Our organization didn’t code that flaw, but we inherited the risk. This raises an uncomfortable question: Do we actually know the full ledger of what we owe?

Just like recent events demonstrated, critical flaws are lurking in our vendor stack that we haven’t mapped yet. We can no longer treat debt as an IT problem. We need enterprise visibility and preparedness for inherited risk across every piece of technology we deploy.

What technical debt means in plain English

Technical debt is what builds up when a team takes a shortcut to deliver sooner, or puts off a repair because something else is more urgent. Think of postponing a roof repair to pay for a new kitchen. It works for a while, the repair bill grows quietly, and then a storm arrives.

Martin Fowler’s Technical Debt Quadrant summarises it eloquently

The interest rate changed, not the debt

Martin Fowler’s technical debt quadrant is still the most useful thinking on this, seventeen years on. He separates prudent debt, taken deliberately to hit a date, from reckless debt accumulated by people who did not know better. He also argues prudent debt need not be repaid if the interest is small: if the code is rarely touched, the interest is theoretical.

That was the bargain most organisations made with old code: defer, accept the risk, and rely on it staying theoretical, because finding an exploitable flaw in a mature codebase took a rare and expensive person months of patience.

AI removed that condition. As security experts note, frontier models used across discovery, exploit development and patch validation: “Frontier models helped work through complex exploit chains and adapt them across different deployments.”

Cloudflare’s Matthew Prince, said AI agents “can now be deployed as a cheap and near-infinite hacker army”, against a “decades-long backlog of bugs in software written without much review or scrutiny.”

Read those together and the metaphor breaks. Debt was modelled as a loan whose interest you could service indefinitely. What changed in 2026 is the interest rate — not because the debt got worse, but because the cost of discovering what it conceals collapsed. Your deferred risk did not become larger. It became searchable.

What happened with PHP last month

PHP is a programming language that runs a huge share of the web, including WordPress, which powers roughly 40% of websites according to Reuters. On 21 October the PHP Foundation issued an emergency patch for two critical flaws, nicknamed php2shell, which let an attacker take remote control of an unpatched server. Security firm Wiz said about 70% of the internet was affected (Fortune, 21 October 2026).

The part that matters most to project managers is how long the weakness was tolerated. The vulnerable code dated back 14 years. A security researcher flagged the underlying class of problem years prior; subsequent audits found similar issues. Each time it was left alone because nobody had shown it could actually be exploited.

The pattern is familiar: a weakness was seen, ranked as not worth the effort, and left in place. The bill did not stay small. Once automated discovery tools found the flaws, thousands of attack attempts materialized within minutes.

Furthermore, the clean-up revealed another familiar form of technical debt: software running on end-of-life versions with no official patch, which nobody budgeted to replace.

AI has added a new kind of debt

AI isn’t just accelerating how debt is found; it is actively creating new forms of debt:

For a project manager, cognitive debt is the dangerous one, because it undermines what we rely on. Estimates, handovers, and go-live decisions all assume that somebody understands the system. If nobody does, the plan is built on sand.

What I would ask project managers to do

Not all debt deserves paying down—rewrites are expensive, and much end-of-life code is internal and unexposed. However, the case for deferral expires fast once discovery gets cheap. Delivery leads should take five concrete actions:

  1. Treat deferred debt as a risk line, not a backlog line. Every known-but-unfixed defect needs an owner, a decision date and a recorded acceptance. “We chose not to fix this, on this date, because the cost outweighed the exposure” is defensible. Silence is not. Any risk acceptance in the past needs to be reviewed in the light of new information such as AI capability to exploit.
  2. Fund an inventory before you fund a fix. You cannot patch what you cannot see. Only 82% of PHP hosts advertise themselves; the rest are found through the applications above them. A listener described to Security Now discovering “about 25 PHP handlers” on a server whose site needed one: “software you no longer need is not merely clutter. It’s an attack surface you may eventually forget you even have.”
  3. Budget engineering judgement, not just licences. The scarce resource is people who can choose between bad options under pressure. If your AI plan assumes those decisions can be automated, it is wrong. What are the fail safes and human in the loop decision making that mitigates the risk. As we discussed in the safety history blog post in lessons learned from the nuclear and aviation history we need to have an understanding of the systems and know how to fix them from first principles.
  4. Make the outage a rehearsed option. When the flaws landed, cyber agencies in Europe, Australia and Japan told users to patch or go offline. The Netherlands’ NCSC set that example: the Port of Rotterdam, the government portal, all five largest political parties and several hospitals followed. “No one can attack an attack surface that’s offline.” A pre-authorised decision to go dark, with a named decision-maker and a communications plan, beats an improvised one at 3am.
  5. Measure the debt your AI creates. Track refactoring share and duplication alongside velocity. If delivery metrics improve while your clone rate rises, you are buying speed with tomorrow’s incident.

Conclusion: Two Questions to Ask Your Team Today

To close the loop on delivery governance, ask your organization these two questions:

  1. Which single system in your portfolio would you be most afraid to see named in a security breach—and who, right now, has the authority to take it offline?
  2. Do you know the debt you actually owe—including the stuff our vendors brought with them?

We didn’t write every line of code we deploy, but we own 100% of the blast radius.

Sources and confidence

  • Fortune, PHP flaw, 14-year age, 2024 limited discovery, Wiz comment, early attack attempts.
  • Security Now! #1102 show notes — Steve Gibson, GRC, 27 October 2026, source of the 2004, 2020 and 2024 timeline, the VulnCheck figures, Prince’s warning and the plug-pull idea. The vulnerable code dates back 14 years, to PHP 5.4 in March 2012. A security researcher, Stefan Esser, flagged the underlying class of problem in 2004; a related bug was reported to the PHP project in 2020; and a 2024 audit by OSTIF and Quarkslab found the same issue again. Each time it was left alone because nobody had shown it could actually be exploited. Fortune, citing OpenAI’s Greg Brockman, likewise says a limited version was spotted in 2024 and judged not significant at the time.
  • watchTowr PHP FAQ, CISA listing on 26 October
  • InfoQ, Joy Ebertz at QCon London.
  • Thoughtworks Radar vol. 34 coverage: https://itbrief.co.uk/story/ai-coding-boom-deepens-cognitive-debt-says-thoughtworks and https://heise.de/-11259127 (secondary; confirm at thoughtworks.com/radar)
  • Sonar survey figures: (secondary; confirm in Sonar’s own report)
  • Gartner prioritisation advice: (vendor summary of Gartner, not Gartner itself)

The incident

Technical debt and AI’s effect on code

Delivery research

Tags: