Attack through a software vendor: when your perimeter starts elsewhere
Why a compromise of third-party software is a threat to your infrastructure, and how to think about managing this risk.
In March 2019, a large-scale attack came to light in which adversaries had compromised the automatic update mechanism of widely-used software. The result was malicious code delivered to a vast number of machines through a completely legitimate channel that users trusted.
This is not a new class of threat - software supply chain attacks have been known for a long time. But the scale and mechanism of this particular case makes you look differently at the question: where does your security perimeter actually begin?
Why software updates are an attack vector
Most corporate security systems are built to defend against external attacks: close ports, scan email, control access. But a software update is legitimate inbound traffic. It is supposed to get through.
If an attacker gains control over a software vendor's infrastructure - the update server, signing keys, build pipeline - they can deliver malicious code with a signature you trust, through a channel you deliberately left open.
Your perimeter in this scenario does not start at your firewall. It starts at your vendor.
How to assess your dependency
Most companies do not have an inventory of third-party software at sufficient detail. Knowing which antivirus is installed is one thing. Knowing which software across all machines receives automatic updates, from which servers, with what signature verification - that is something else entirely.
The first step toward managing this risk is making a list. What third-party software is installed in the infrastructure? Which of it auto-updates? Who supplies it? How well does that supplier secure its own supply chain?
This is not paranoia. It is dependency inventory - the same thing you do for financial or operational risks.
What can be done practically
Eliminating this risk entirely is impossible: without updates you leave vulnerabilities unpatched, which is worse. But the risk can be managed.
Segmentation limits the blast radius. If compromised software lands on a workstation but that workstation has no access to production systems or sensitive data, the damage is significantly smaller.
Behaviour monitoring, not just traffic monitoring. Compromised software with a legitimate signature will pass hash and signature checks. But its behaviour in the system - network connections, file access, process creation - may be anomalous. That is detectable.
Privilege management. Third-party software should not run with administrator rights where that is not necessary. The principle of least privilege reduces what an attacker can do once they gain control.
Deliberate vendor selection. When evaluating critical software, it is worth asking vendors about their own development and security supply chain: is there code signing, is there an audit process.
Questions to assess your position
- Do you have a list of third-party software in your infrastructure with a note on what updates automatically?
- Do you understand which systems have the largest blast radius in the event of a compromise?
- Does critical software run with the minimum necessary privileges?
- Is there monitoring of anomalous behaviour on endpoints?
- Do you evaluate the security practices of key software vendors - not just their products, but their processes?
A supply chain attack is not an argument for paranoia. It is an argument for inventory and deliberate awareness of dependencies that most companies take for granted.