Six months after a network monitoring vendor shipped signed malware to thousands of customers, the software supply chain problem has stopped being an incident and become a permanent feature of the landscape. The intervening period has been instructive. In March, organisations worldwide raced to patch mail servers being exploited faster than the updates could be applied. In April, a code coverage tool embedded inside software build pipelines was found to have been tampered with for two months. The same month, the original intrusion was formally attributed to Russia's foreign intelligence service, with sanctions and expulsions following. In late May, that same actor was reported to be running a phishing campaign through a compromised email marketing platform. And in the last five weeks, criminal ransomware crews have stopped a fuel pipeline and a meat processor, with the G7 issuing a statement about it this weekend and a presidential summit on the subject days away. Different actors, different motives, the same structural insight: it is more efficient to compromise the thing that distributes software than the organisations that run it.
Three problems wearing one name
Most supply chain security programmes fail because they treat one phrase as one problem. There are at least three, with different owners and different controls. The software you install and it updates itself. Commercial products with agents, management tools, security software, anything with an automatic update channel. The risk is build and distribution integrity, and the control surface is procurement, update management and network egress. Services with standing access into your environment. Managed service providers, integrators, support tunnels, outsourced administration. The risk is credential and privilege abuse, and the control surface is identity. Components inside software you build yourself. Open source libraries, container base images, build tooling. The risk is inherited vulnerability and dependency tampering, and the control surface is engineering practice. An organisation that buys a single product and declares supply chain risk addressed has almost certainly bought something that touches one of these three.
| Exposure | Review focus | Control area |
|---|---|---|
| Installed self-updating products | Who can change the build and distribution? | Procurement, rollout and egress. |
| Services with standing access | Which credentials and privileges remain active? | Identity and access ownership. |
| Components in your own software | Which dependencies and build tools are inherited? | Engineering practice. |
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
The bill of materials is necessary and insufficient
The policy response has converged quickly on the software bill of materials — a machine-readable list of what is inside a product. The United States executive order issued last month requires it of federal suppliers, and the minimum elements are due to be defined within weeks. It is a genuine advance, and it will do real good for the third problem above. It would not have detected this particular compromise. The malicious code was inserted during the build, in a legitimate build environment, and shipped inside a legitimately signed artefact. A perfect ingredients list would have listed the ingredients and said nothing about the fact that somebody else had been in the kitchen. The question that matters for commercial software is therefore narrower and harder: who can change what I run, and what would stop them? Concretely, that means asking a supplier how many individuals can push an artefact to customers, how that access is authenticated, whether signing keys are held in hardware with separated duties, whether builds are reproducible from source, whether unauthorised artefacts would be detected, and whether the release process requires a human approval that cannot be automated away. Very few suppliers can answer all six today. The answers you get — including the evasions — are more informative than any certificate.
Count your remote execution paths
Here is an uncomfortable exercise. List every piece of software in your estate that runs with administrative privilege and updates itself automatically from the internet. Endpoint agents, backup clients, monitoring agents, remote support tools, patch management, network appliances, the browser, the virtualisation tooling. In a mid-sized organisation the list usually runs to thirty or forty agents from fifteen or twenty vendors. Every one of them is an authorised remote code execution path into privileged context, granted deliberately, reviewed never. That is the actual exposure, and it is not reduced by an ingredients list. The mitigations are unfashionable but effective. Stage deployments in rings, so that no update reaches the whole estate on day one. Delay non-security updates for management software by a short, defined period. Restrict outbound network access from management agents to the destinations they genuinely require, so an implant has somewhere to be noticed. Alert on management servers making unexpected outbound connections. And extend log retention: in this incident, the organisations that could answer questions were the ones with several months of egress and authentication logs, and the ones that could not were the ones retaining thirty days.
Assume you will be told
The intrusion was discovered because a security company noticed the theft of its own tooling and investigated. No customer found it independently. That is the realistic model: you will learn about the next one from a vendor advisory, a government notification, or the news. So rehearse the twenty-four hours after the call. Can you enumerate, within an hour, every installation of a named product and its version? Do you know what credentials that software holds and what it can reach? Do you have logs covering the relevant period, and are they searchable? Who decides to disconnect the product, and what breaks when you do? What is the credential rotation plan for everything that agent could have touched, and how long does it take? A supply chain programme that produces good answers to those five questions is worth more than one that produces a library of supplier attestations.
Practical Guidance for Supply Chain Security Assessment
- Separate the three problems — installed software, standing access, and code dependencies — and assign each a named owner.
- Inventory every self-updating privileged agent and remove the ones nobody can justify. Each removal deletes an execution path.
- Ask suppliers the build integrity questions, not the questionnaire questions. Who can ship, how is it approved, how would tampering be detected.
- Stage updates in rings and delay non-urgent updates to management software, accepting a small patch latency in exchange for blast radius control.
- Constrain and monitor outbound traffic from management infrastructure, because that is where implants become visible.
- Extend retention of authentication and egress logs to at least six months, and confirm they are searchable under pressure.
- Rehearse the vendor-compromise notification as a tabletop exercise with a real product name and a real clock.
- Require notification of build environment compromise, not only of confirmed customer impact.
The Regional Angle
Three things are different here, and one of them is an outright opportunity. The opportunity is to free-ride on somebody else's regulator. The new American requirements oblige major vendors to produce artefacts they did not produce before: bills of materials, secure development attestations, provenance records, vulnerability disclosure processes. Those artefacts will exist regardless of whether a Gulf buyer asks for them, and the marginal cost of handing them to one more customer is approximately zero. Regional procurement teams should therefore write a single clause requiring the vendor to provide, on request, whatever software supply chain documentation it produces for any government customer anywhere. It costs nothing, it sidesteps a bespoke negotiation the buyer would lose, and it upgrades your assurance position to that of a far larger customer. Very few organisations in this market have thought to ask, and the vendors will not volunteer it. The second is a genuine tension between sovereignty requirements and supply chain integrity, and it deserves to be stated plainly rather than resolved by slogan. Approved product lists, national certification schemes and local hosting mandates push buyers towards vendors with a regional presence, which frequently means smaller vendors and locally developed products. A smaller vendor is not less trustworthy, but it is materially less likely to have hardware-backed signing keys, reproducible builds, separated release duties or a vulnerability disclosure programme. Buying locally for sovereignty reasons and then applying no build integrity scrutiny simply moves the risk from a foreign intelligence service to an under-resourced development team. The workable answer is proportionality: apply the build integrity questions to every supplier, accept different answers at different scales, and compensate for the gaps with the ring deployment, egress control and log retention measures that are entirely within your own hands. The third is the local tier that most regional estates actually depend on and no framework mentions. In this market, a great deal of infrastructure is built and maintained by a system integrator that prepares the standard image, holds the software repository, repackages installers for deployment, and pushes updates through its own management tooling. That integrator is a link in your software supply chain, usually with fewer security resources than either you or the vendors whose software it distributes. Three questions are worth asking this month: where did the installer in your repository come from, was its hash verified against the vendor's published value, and who inside the integrator can modify the deployment packages you consume. In my experience the first question produces a long pause and the second has never been answered with a yes.
The objection worth taking seriously
The strongest objection is that none of this defends against the adversary that caused the problem. A foreign intelligence service that compromises a trusted vendor's build environment, waits months, stages carefully and uses infrastructure inside your own country is not going to be stopped by procurement clauses or an ingredients list. For the overwhelming majority of organisations, supplier interrogation is an expensive performance, and the money would be better spent on resilience, backups and insurance. Most of that is right, and it is worth saying out loud so that boards stop expecting prevention. You cannot buy immunity from a state actor with a questionnaire. The response is that prevention was never the realistic goal, and the controls worth funding do not depend on it. Ring deployment, constrained egress from management systems, privilege reduction for agents, long log retention and a rehearsed notification playbook all reduce dwell time and blast radius, and they work identically against an intelligence service, a criminal crew with a stolen signing token, and a vendor with a sloppy release process — which, statistically, is the one most likely to affect you. The supplier questions matter for a different reason: they discriminate. A vendor that can describe its release controls in detail is a different risk from one that sends a certificate, and that difference is visible in about fifteen minutes of conversation. Prevention is out of reach. Selection, containment and speed of response are not.
Common Questions
Should we require a software bill of materials from every supplier?
Require it where you build or integrate, and ask for it everywhere else — particularly from vendors already producing one for a government customer. Just do not mistake the list for assurance about build integrity.
How far down the chain should we look?
One tier properly beats four tiers superficially. Know your direct suppliers, the standing access each has, and which of them can push code or configuration into your environment. That set is small and unmanaged in most organisations.
Is open source riskier than commercial software?
Differently risky. Open source exposes you to inherited vulnerabilities you must find yourself; commercial software concentrates trust in a build process you cannot inspect. The last six months have supplied vivid examples of both.
What should we expect over the next twelve months?
Expect the minimum elements of a software bill of materials to be published within weeks and to become a commercial expectation far beyond government buyers within a year. Expect another compromise of a widely deployed management or deployment tool — the class of software that reaches thousands of estates through one vendor is now the most valuable target in the market, and the attackers have not exhausted it. Expect diplomacy to produce communiqués rather than measurable reductions; this week's statements and the coming summit will not change the economics for criminal groups. Expect insurers and enterprise customers to start asking for build integrity evidence alongside the usual certifications. And expect at least one organisation to discover, publicly, that its log retention was thirty days when the question it needed to answer covered nine months.
Supply Chain Security Assessment — we inventory the software and services that can execute code inside your environment, test how quickly you could answer a vendor compromise notification, and fix the containment gaps that determine how bad the next one gets.