With "Unikernels are reasonably secure", but then nobody would have read it., you might also take into account whether the audience, having read it, are happy t

With "Unikernels are reasonably secure", but then nobody would have read it., you might also take into account whether the audience, having read it, are happy that they did. The title sounded pretty absolute. So you do have a noble goal. When I am asked to assess software, to gain a first order approximation, I often look at the culture of the organization that produced it. On the high end, that often translates to some sort of formal process involving un-fun letters like 'ISO' and 'SOC'. For smaller organizations, or OSS software, I try to get a feel for how the developers seem to be thinking about security. Some of the cultural things I see in your writeup are encouraging--Smaller Codebase, Removing hardware emulation, Cutting off access to ring 0--all bode well for how you are thinking about producing secure software. But there are some things that are missing from your description. What is your development process? In particular how and when do you attack your assumptions about how the code actually works? What flaws have you found in your testing? Zero findings could mean 1) it wasn't tested 2) it wasn't tested very hard 3) the testers were not very good at security testing. And as OpenBSD's history has illustrated, some things are totally secure until they aren't.