The Trivy breach shows why infrastructure design and operational control still matter
What just happened
In March 2026, security teams disclosed a supply-chain compromise involving Trivy, the widely used open source security scanner. Attackers used compromised credentials to publish malicious Trivy artifacts and tamper with related release channels, turning a trusted security tool into a mechanism for stealing secrets from downstream environments. Public reporting later indicated that more than 1,000 SaaS environments were already dealing with the fallout, with investigators warning that the total could rise significantly.
The incident did not stop with Trivy. As the investigation developed, other projects were linked to the wider campaign, including LiteLLM, where malicious PyPI packages were published and later removed. In LiteLLM’s case, the project’s own incident update said the affected versions were limited to specific package releases, while official Docker-based deployments and source installs were not affected.
The bigger lesson is not just that one tool was compromised. It is that modern environments often depend on long chains of upstream software, build systems, package registries, automation, and release pipelines. When one trusted component is poisoned, the impact can spread quickly into customer environments that never realised they were exposed.
The supply-chain problem
Most cloud platforms rely on layers of third-party software and automation: open source libraries, images, scanners, CI/CD components, orchestration tooling, and middleware. Every additional dependency increases complexity, and every layer introduces another trust relationship that has to be secured.
That does not mean public cloud is inherently unsafe, or that every shared platform creates the same level of risk. But it does mean customers should understand how much of the stack they can see, who controls it, and how quickly a compromise in an upstream component could affect their environment.
The Trivy incident is a good example of that risk. Organisations trusted a widely used security tool and, in some cases, consumed it through automated processes. Once that trust chain was broken, the compromise moved downstream through normal operational workflows.
A different approach: infrastructure with tighter operational control
Our CloudDESKTOP service is designed around a more controlled infrastructure model.
Customer workloads run as guest virtual machines on Microsoft Hyper-V hosts that we own and operate in UK data centres. We are not layering customer workloads onto a large container-orchestrated platform, and we are not depending on a broad chain of upstream runtime tooling to deliver day-to-day hosting.
That does not remove supply-chain risk entirely. No serious provider should claim that. But it does reduce complexity in the infrastructure layer and gives us tighter control over what is running underneath customer workloads, how it is managed, and when changes are introduced.
Here is what that means in practice:
We control the hardware
Your workloads run on physical servers we own and operate in UK data centres. We are not reselling capacity from a hyperscale public cloud platform.
We control the hypervisor layer
We use Microsoft Hyper-V, a mature and well-understood virtualisation platform, and we manage the host environment directly.
Customer environments are isolated, even where hosts are shared
Different customers’ guest servers can reside on the same physical Hyper-V hosts, but they do not share a common application runtime or flat internal network. We disable IPv6 and use layer 2 network isolation controls through Acronis Cloud Security so that if one guest is compromised, it cannot directly communicate with other customers’ guest environments.
We control changes to the underlying platform
We are not automatically inheriting infrastructure changes from a large upstream cloud stack. Updates and platform changes are planned, tested, and implemented by our team.
The trade-off
This model has trade-offs. We are not trying to replicate the near-limitless elasticity of a hyperscaler, and we are not chasing every container-native feature that appears in the market.
What we offer instead is a more straightforward hosting model with tighter operational control, clearer boundaries, and less architectural sprawl. For many businesses, especially those handling sensitive data or operating in regulated environments, that is a worthwhile trade.
Questions to ask any cloud provider
If you are evaluating cloud hosting options, incidents like Trivy should prompt a few direct questions:
- What third-party components are involved in running my workloads?
- How do you vet and monitor upstream dependencies?
- If a release channel or dependency is compromised, how quickly would you know?
- Do I share hosts, networks, management tooling, or runtimes with other customers?
- What technical controls stop one customer environment communicating with another?
- Who decides when updates and changes are applied to the systems underneath my workloads?
The answers will tell you a lot about how much control you are really handing over, and how much exposure you may have when the next supply-chain attack arrives.
Need help with private cloud hosting?
Give our friendly experts a call on 020 3327 0310.
Last updated: 31 March 2026