Security
At Vates, security is not an afterthought: it's a fundamental design principle embedded across our entire stack and organization. From the hypervisor layer to our orchestration tools, every component is built with transparency, control, and long-term resilience in mind.
The foundation of our stack is the Xen hypervisor, a minimalist Type 1 architecture renowned for its isolation capabilities and security track record. It's the technology of choice in some of the most demanding environments, including aerospace, defense, and national cybersecurity infrastructure. On top of this, XCP-ng and Xen Orchestra deliver a fully open and auditable platform — a critical advantage when trust, compliance, and fast reaction times are non-negotiable.
Because we own and maintain the entire stack, we can react swiftly to vulnerabilities, backport patches when needed, and harden the platform without relying on opaque third-party release cycles. Security updates are never gated behind paid support, ensuring that all users benefit from the same level of protection.
Beyond the code itself, our security posture extends to our development processes, CI/CD pipelines, responsible disclosure policy, and organizational workflows. Whether you're running thousands of virtual machines across distributed datacenters or operating in a high-stakes sector where uptime and integrity are critical, the Vates stack is engineered to meet your requirements.
Security philosophy
Our approach to security starts with a simple assumption: you can't protect what you don't fully control. That's why Vates has made the strategic choice to build and maintain every layer of its infrastructure stack, from the hypervisor to orchestration, backups, and even the supporting toolchain.
But control alone isn't enough. We pair it with transparency. By publishing our entire stack as open source, we ensure that our code is auditable not only by our team, but also by the broader ecosystem, including customers, partners, and upstream contributors. This transparency fosters accountability, accelerates the discovery of potential issues, and builds trust in a way closed-source systems simply can't.
We also recognize that resilience must be baked into every layer. That means choosing a minimalist and hardened foundation like Xen, implementing strict separation between control domains, and avoiding unnecessary complexity wherever possible. Complexity is the enemy of security — and our design philosophy reflects that understanding.
Finally, security at Vates isn't confined to code. It's part of our culture: in how we handle updates, how we interact with the community, how we structure our development pipelines, and how we respond to emerging threats. By treating security as an evolving process rather than a static feature, we ensure that our stack can adapt to new challenges — and help our users do the same.
Security process
Security is not a one-time effort: it's a continuous process that spans vulnerability monitoring, risk assessment, patch delivery, and incident response. At Vates, we've built structured, transparent, and responsive workflows that apply across our entire stack — while still respecting the specificities of each component, such as XCP-ng and Xen Orchestra.
🔎 Vulnerability monitoring
We continuously track vulnerabilities across all relevant layers: the Xen hypervisor, Linux kernel, system libraries, packaging tools, JavaScript/Python dependencies, and more. Our team monitors upstream projects, public CVE feeds, and security mailing lists to ensure that we are aware of newly disclosed issues as early as possible.
This process is enhanced by community input: users often report bugs or concerns on our forums or via direct contact, allowing us to benefit from a broad, security-conscious ecosystem. We also use automated scanners to audit dependencies in both XCP-ng and Xen Orchestra, flagging outdated or vulnerable libraries before they become a problem.
As a downstream of the Xen Project, we also are part of the predisclosure list of Xen's security issues, allowing us to prepare integration of fixes during embargos to be able to publish them quickly once an embargo is lifted.
🧪 Risk assessment & prioritization
Not all vulnerabilities are equal, and our assessment process takes into account both severity and relevance to our stack. For example, a critical flaw in an unused component or in a userland tool not exposed to the network may not require the same response as a remote code execution vulnerability in a core service.
Once identified, vulnerabilities are triaged by the Vates team, with special care given to:
-
Whether the component is installed or used by default
-
Whether it's accessible remotely or requires elevated privileges
-
Whether a proof-of-concept or active exploit exists
🛠️ Patch management & updates
When a vulnerability requires action, we move quickly. Our patch process includes:
-
Applying or backporting upstream fixes, or developing our own patches if none are available
-
Validating the fix through automated tests and internal QA
-
Releasing the fix via regular update channels or via out-of-band patches when urgency requires it
On the XCP-ng side, patched RPM packages are pushed to the official update repositories and announced on the XCP-ng blog, with the "security" tag. For Xen Orchestra, updates are released through our rolling release model and announced in our changelog, blog (under the "release" tag) and GitHub.
XCP-ng packages are signed and verifiable, and we encourage users to subscribe to relevant channels to stay informed.
📣 Coordinated disclosure & communication
If a vulnerability is reported privately to us, we follow a responsible disclosure process: coordinate with upstream projects if needed, develop and validate a fix, and only then publish an advisory. We're also open to collaboration with researchers, and we do not delay publication for commercial reasons: our priority is always user protection.
🚨 Incident Response
When critical security events happen (whether internal or reported externally) we activate a structured incident response plan:
- Triage and reproduce the issue
- Assess scope and impact across the stack
- Patch and release with clear documentation
- Notify users via all relevant channels (forum, blog, changelogs, newsletter if necessary)
- Review internally to refine the process and avoid recurrence
We treat any serious incident as an opportunity to improve, whether it's in code, process, or communication.
🔗 Separate but integrated processes
Both Xen, XCP-ng and Xen Orchestra have their own published security processes:
These processes operate independently but are part of a larger, unified security culture at Vates. By centralizing our development and coordinating between all teams, we ensure rapid and consistent handling of vulnerabilities across the entire stack, including cross-layer issues that would otherwise fall between the cracks in more fragmented solutions.
Security from the development
Building a secure platform starts long before deployment, it begins at the first line of code. At Vates, we work in a manner that ensures our software is designed, written, reviewed, and released with security in mind at every stage.
This process applies across our stack: from low-level system components in XCP-ng, to orchestration and API logic in Xen Orchestra, and to the tools and services that connect them.
🧱 Architecture with Security in Mind
Security starts with design. Our architecture is deliberately minimalist and modular to reduce the attack surface. In XCP-ng, for example, dom0 is tightly controlled, with limited userland or irrelevant software. Isolation between virtual machines and management domains leverages the strong security model of the Xen hypervisor.
In Xen Orchestra, features are designed with clear access boundaries and privilege separation, with role-based permissions and API scoping playing a key role in reducing the blast radius of potential bugs.
🔍 Code reviews & peer validation
All changes to all components go through a mandatory code review process, even internal contributions. Pull requests must be approved by at least one reviewer (often more), and discussion of security-sensitive logic is encouraged directly in the code review itself. This applies to everything from backup logic to XAPI interactions and frontend authentication flows.
When possible, we upstream improvements (e.g., to the Xen Project or other dependencies), benefiting from even broader peer review.
🔐 Dependency management
Modern infrastructure stacks include hundreds of third-party packages. That's why we maintain a close watch on dependencies, whether RPM-based packages in XCP-ng, or NodeJS modules used in Xen Orchestra.
-
We use automated tools to scan for known CVEs in dependencies.
-
Updates are reviewed for security impact, not just functionality.
-
Whenever feasible, we remove or avoid dependencies entirely if they introduce unnecessary risk.
We also package and sign many of our own dependencies (e.g., in XCP-ng), ensuring better control than relying solely on upstream binaries.
🧬 Continuous improvements
We have various projects showing the direction of "what's next" regarding security at Vates:
- Where appropriate, we favor memory-safe languages like Rust — particularly for agents and tools running in privileged domains or interacting with guest VMs. Our Rust-based guest agent for Linux is one example, and more internal tools will follow the same path to reduce the risk of memory corruption and undefined behavior.
- Fuzzing and test coverage is a planned in a near future to harden both XCP-ng and Xen Orchestra
- CI/CD with security gates: we are adding more and more tooling around the CI/CD pipeline to improve the security right in the development process (linting, static analysis, automated tests, build reproducibility checks via Koji etc.)
Hardening guide
We have a white-paper about hardening the stack and best-practices when deploying our solutions. More to come in this section soon!
Contact & disclosure
Found a vulnerability? Please report it responsibly at: security@vates.tech
Coordinated disclosure encouraged: we commit to transparency and fast response.