&gt; <i>The distributed nature just means that if attackers find one exploit, they can apply it repeatedly to the distributed application, to give themselves an entire botnet</i><p>That may or may not be true... In any case it&#x27;s completely orthogonal to unikernels. Distributed applications, and any security advantages&#x2F;disadvantages, are a fact of life.<p>&gt; <i>All code is privileged, so any remote execution exploit in any piece of code makes you own the whole machine (physical or virtual, as the case may be). A buffer overflow in some HTML-template-stuffing code is as good as one in an ethernet interrupt routine. Wee!</i><p>I&#x27;m afraid you&#x27;re parroting what you learned about security without really understanding it. Yes, an exploit will give you access to the individual machine. But what does that mean if the machine is a single trust domain to begin with, with no privileged access to anything other than the application that is already compromised? In traditional shared systems, running code in ring0 is a big deal because the machine hosts multiple trust domains and privileged code can hop between them. That doesn&#x27;t exist with unikernels.<p>Add to that the tactical advantages of unikernels: vastly reduced attack surface, a tendency to use unikernels for &quot;immutable infrastructure&quot; which means you&#x27;re less likely to find an opportunity to plant a rootkit before the machine is wiped, and the fact that unikernels are vastly less homogeneous in their layout (because more happens at build time), making each attack more labor-intensive. The result is that the security story of unikernels, in practice and in theory, is very strong.