Software supply chain attacks: when the vulnerability arrives with an update
An attack delivered through a trusted software vendor is one of the hardest threat vectors to defend against. I look at how it works and what businesses can actually do.
In March and April 2023 it emerged that 3CX - a widely used enterprise telephony platform - had been compromised. Attackers embedded malicious code into a legitimate update that the company distributed to its customers. Users installed an update from a trusted vendor and received a malicious payload along with it.
This is not the first incident of this kind - software supply chain attacks have been increasing in frequency. But each new case is a reminder of how practically difficult this threat is to address.
Why this is a particularly awkward type of attack
Traditional security is built around a perimeter: control what comes in from outside. A supply chain attack bypasses that perimeter, because the malicious software arrives from a trusted source.
You installed an update from a vendor you have worked with for years. The vendor has a digital signature, a track record, and a support contract. From the perspective of most defensive systems, this is legitimate activity.
That is exactly what makes attacks of this type difficult to detect and expensive in their consequences. By the time the attack is identified, the compromised software may have been running in the infrastructure for weeks.
What this means in terms of risk
For most companies, direct protection against attacks of this kind is not fully possible - you do not have access to the development and build processes of your vendor. But that does not mean nothing can be done.
The risk has several components: what software is installed and how much privileged access it has; how quickly you will detect anomalous behaviour; and how you will respond and limit the damage.
All three components need to be worked on.
Practical steps for business
The first step is an inventory of critical software. What programs are installed on workstations and servers that have access to critical systems? This should be a concrete list, not a general understanding.
The second step is least privilege for software. A telephony application should not have privileged access to the file system or network resources it does not need. Application isolation reduces the potential damage from a compromise.
The third step is behavioural monitoring, not just perimeter monitoring. If an application starts sending data outbound or accessing resources it has never accessed before - that should be visible.
The fourth step is a response plan. What do you do in the first hours after detecting a potential compromise? Who makes decisions, who isolates systems, who communicates with customers?
What this means for vendor relationships
Supply chain attacks change how you should think about relationships with IT vendors. The question "how reliable is this vendor" now includes not only their business stability but their secure development practices.
For critical software it makes sense to include questions about secure development processes in commercial negotiations. Not because you will conduct an audit - you most likely will not. But because it is a signal about how the vendor thinks about this topic.