June 12, 2026
Picture the scene: a few weeks ago, one of your vendors was compromised. You didn’t find out from your monitoring. You didn’t find out from the vendor. A third party told you.
For many security and tech leaders, this is now the reality of their job.
For many years, software chain risks have been gathering momentum. The balance between attackers and defenders has shifted towards increasingly automated attacks. Two things have caused this change:
1. The patching window has collapsed
The time between a CVE being published and a working exploit landing in the wild used to be measured in weeks. Then days. Now it’s hours. Threat actors have automated the reverse-engineering of CVEs and vendor patches; they weaponise the fix faster than most enterprises can even schedule a change window. AI-assisted reverse engineering is accelerating the speed at which vulnerabilities are operationalised. You can be fully compliant with your patching SLA and still be months behind. This is the sharper edge of a long-running tension between delivery velocity and security posture. Compliance and safety stopped being the same thing some time ago.
2. CI/CD is the new front line
Attackers have moved upstream. Recent campaigns have hijacked popular developer tools such as security scanners, HTTP clients. These are widely trusted dependencies embedded deep within enterprise development workflows, and they’re being used to quietly siphon cloud credentials, IAM keys, and source code out of build pipelines. Continuous integration runners are high-privilege compute that almost nobody watches, and AI coding assistants now operate inside the same environments with broad permissions, which adds a new dimension to how platform teams need to think about AI integration. Attackers worked that out before most defenders did.
Confidentiality, Integrity, Availability, otherwise known as CIA. It’s the first thing anyone learns in Infosec, and it rests on an assumption that no longer holds: that we can keep data inside the building. Once your data has walked out the door (and you should assume it has), restoring confidentiality isn’t viable. You can’t un-leak personal data. You can’t un-exfiltrate a source code. Confidentiality, integrity and availability remain essential principles, but they are no longer enough on their own to guide modern defensive strategy.
We need a different frame. And there’s one the engineering community already understands, even if security hasn’t fully caught up to it yet.
The DIE Triad was created by Sounil Yu (also the creator of the Cyber Defense Matrix). DIE framework is highly regarded in the cybersecurity industry and a necessary paradigm shift, particularly for organizations adopting cloud-native architectures, DevSecOps, and modern infrastructure practices. The goal stops being to block every attack. The goal becomes making attacks irrelevant.
Ransomware, wipers and supply chain poisonings are an operational reality. The question is not whether a component will fail, but what the blast radius looks like when it does. If a single supplier compromise can flatten your operation, that is not a security problem. It is an architectural one.
Many organisations still manage infrastructure as persistent assets that require ongoing, manual intervention. We’ve spent 20 years lovingly tending to servers – patching them, SSHing in, “investigating” anomalies at 2am. That model is dead. Your CI runners and build environments should not be pets. They should be disposable, reproducible environments. If a runner makes a strange outbound connection, you don’t debug it. You replace it automatically, and a pristine replacement comes up from a known-good image in minutes, not hours.
Assume the attacker is already in your pipeline. Under that assumption, the safest credentials are short-lived credentials that expire before they’re useful. If someone scrapes an API key out of a build log, it should be blocked and expired before they can be reused.
None of this requires new vendors or a new security function. The primitives are already on the shelf: Terraform, image builders, short-lived tokens, federated identity. Most platform teams are using them every day as part of routine modernisation and platform work, often for unrelated reasons. Our Secure Delivery Playbook is essentially this argument applied across the SDLC.
We have spent a decade trying to save our systems. The better move is to design systems that don’t need so much saving.
If the capability exists, why is this so hard to land? The gap is rarely technical. Most engineering teams already understand DIE. Most CTOs have known for years which architectural moves are required. What is missing is the executive permission to retire a posture designed for a different decade, and the shared language between practitioners, CTOs and the boardroom to make the case credible.
For practitioners, this is the work you have probably been trying to get prioritised for some time. For executives, it is the difference between an incident being a board-level crisis and a Tuesday.
If you’re a CTO or CEO reading this and your security conversations still revolve entirely around blocking, detecting, and patching – that’s a gap. Prevention still matters, of course it does. But the posture that carries a business through the next few years is the one that can absorb a breach without everything falling over.
The question it’s not ‘if?’ but ‘when?’ breach happens. It is the conversation worth having with your team before the next supplier incident has it for you.
If you want to take this to the next level and learn more about how we can support you on this Secure Delivery journey – contact us today.
Michal Czerwinski is a security specialist and technology consultant at Equal Experts, helping organisations identify and mitigate cyber risks across modern data and software platforms. With experience spanning security, engineering and architecture, he focuses on building resilient systems, uncovering vulnerabilities and enabling teams to deliver secure digital products at scale.
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.
