Defending Against the OWASP Top 10 with Unikernels

The OWASP vision is "no more insecure software" - admittedly this is a hard thing to do but awareness is always good and welcome.

It mainly deals with web application security which powers a substantial amount of software today - think every single saas company out there -- any company's website.

Even though nanos is a kernel, since it creates virtual machines out of individual applications, and most of the payloads are web applications, the OWASP top ten actually is highly relevant.

The latest released version is OWASP 2021 but the new release candidate is OWASP 2025.

The OWASP Top 10 was originally released around 2003 and there is a question of whether it is relevant anymore. The original ideas behind the OWASP Top 10 was the thought that if enough developers knew about the most important security flaws that happen specifically in web development perhaps they might stop happening so much. However, each year the number of CVEs grows by quite a lot and XSS is still the number one security flaw out there.

Why Isn't Web Application Security Solved in 2025?

A lot of developers are focused on product development. It's very common for security to be treated like 'scalability' or 'clean code' or 'testing' or any number of other factors in software development that are not directly related to closing out feature issues. Product managers and developers managers routinely ignore these critical points to "make things happen", like closing a new customer, and are many times simply ignorant of their importance.

However, that does not explain it all. There is a meme that all developers are the same and everything is just "CRUD" but there is a very very wide spectrum of skill, industry knowledge, and domain expertise. Developers most definitely are not homogeneous and not everything is CRUD.

Furthermore, despite what the thought leaders state - the software development lifecycle is not just the CI/CD system. It also, for example, contains the aspect of when someone leaves a company with knowledge of a complex system, and someone else has to pick it up to maintain it. This is further complicated by the fact that many language ecosystems today are heavily dependency based. This is to say that developers nowadays are utilizing vast quantities of software they did not write themselves and we're not talking about the database or webserver - we're talking about core pieces of software that go right into the core of the application itself. Just the other day we saw the expr-eval security issue, CVE-2025-12753, that allows code injection for a package that gets 800,000 downloads a week and has not had any updates in six years. The old maintainers can not even be found so it sits there unfixed.

Some folks will start talking about SBOMs at this point but very few companies keep this information and if they do it is only to check the box on a compliance list. Many times developers won't even know that they have a dependency because it's been nested in other dependencies. It is not as simple as looking at a lockfile.

Finally, a lot of developers might know about certain security issues but they don't know of fast/easy ways to fix them and so they don't. A prime example of this is when someone chooses to shell out to run a command versus using an existing native library or using a library linked in a different language. This is clearly bad but the difference between 2 minutes of work versus trying to export some functions in a language they don't know is obviously a quick choice that gets made.

We believe web application security is more relevant than ever. The single largest cohort of developers today are firmly in the web application space. The most popular language is javascript. With the explosion of vibe coding over the past year this will only become much more important.

So unfortunately, even though the OWASP had noble goals, web application security has gotten far far worse in the past twenty some odd years. Education is not enough - you need to avail yourselves of stricter runtime environments that prevent some of these issues from occurring.

Let us take a look at how unikernels fit into the 2025 list.

A01_2025 Broken Access Control

Broken access control is a big one. A very simple example of this of which is being routinely broken today is by putting auth into the front-end where it definitely does not belong.

However auth transcends not just application level users but also system level users because system users by definition are application owners. The application itself has to run under a user. In unikenels we don't have the concept of a user as we only assume one application is being ran to begin with.

This means that you can never ssh into the underlying system and you can't run other programs other than the one that is running.

Just cause there are no system users doesn't mean you want to carelessly expose sensitive data though. You should still ensure that you aren't able to list things like backups or .git folders in a webroot.

There are a lot of attacks that happen through insecure symlink creation or insecure tmp file creation and a lot of that is largely defeated because of the 'no user' system architecture. Containers are routinely broken out of because of these types of bugs.

A02_2025 Security Misconfiguration

This is a rather encompassing group. One example calls out for a segmented appliction architecture. For example if you are building a multi-tenant hosting solution (eg: many custommers) these should all be isolated from one another via virtual machines - not containers. We see far too many people assuming the lie that containers contain which they do not. We just saw THREE new container escapes the other week.

It's very common for unikernel users to deploy their applications with a simple 'ops instance create -t aws' and that creates a new ec2 instance of your application but in multi-tenant situations like the one above you can also use Inception which allows you to create unikernels on top of existing ec2 instances without the performance drop.

A03_2025 Software Supply Chain Failures

The software supply chain is becoming an increasingly large and untenable thing to control.

Some people think that if you scan for vulnerabilities and you scan for malware you can control it, however, this is severely misguided. First off, malware is typically removed once found on package repositories. If it's not found than you can't scan for it. While CVEs can track vulnerabilities they can't track software flaws that have not been discovered and publicly advertised.

While unikernels can't defend against all malware and all vulnerabilities (and don't let anyone tell you so and so technology can) what they can provide is exploit payload mititgation. That is most malware and many exploit payloads wish to run numerous commands on a given system once infected or abused. Unikernels prevent this out of the gate and instead force the attacker to work within the environment that they have attacked. So for instance if someone hacked your node.js webapp with a piece of malware from npm that malware, if callable can run normal javascript code but there is never a situation where it can simply download a cryptominer written in c++ or rust and start running it. The main goal of an attacker is to run *their* software on your system and this gets progressively harder when you are using compiled languages as then you have to have both writeable and executable primitives in the executable itself.

A04_2025 Cryptographic Failures

This category talks a lot about various crypto failures but also includes problems such as incorrectly storing keys.

A great example of this is by doing a simple google dork such as loooking for openapi keys or .env files. Like we mentioned earlier, it seems that some of the "basics" are getting worse, not better.

You can store your secrets in something like Vault but you can also use things like the user-data klib to store secrets in the IMDS. You need to know that a misconfigured application could potentially leak this via a SSRF and we'd recommend only provisioning with IMDSv2 to help guard against this.

A05_2025 Injection

Injection is a huge problem for a lot of legacy linux systems as they are inherently built to run many different programs by many different users. Unikernels out right prevent this as they can only run one program.

CWEs listed in this category such as CWE-77 and CWE-78 command injection are completely eliminated by unikernel architecture. Some attacks in CWE-89 that include running other commands are also defeated.

A06_2025 Insecure Design

The insecure design category specifically calls out the need for a secure development lifecycle which unikernels are a firm building block of.

At the system level some of the mapped CWEs include CWE-266, CWE-269 for incorrect or improper privilege assignment can be thrown out since unikernels have no system users to begin with. If it's a user at the application layer these would still be something to note.

It also includes CWE-1125 - Excessive Attack Surface which unikernels confront head-on with a drastic reduction in attack surface.

Unikernels also by default segregate tenants and tier layers by only allowing a single application per vm.

Some weaknesses such as CWE-76 - Use of Potentially Dangerous Function become less of a concern. For instance you still might not want to use strcpy but if it exists it becomes way less of an issue than the same application on linux.

A07_2025 Authentication Failures

While unikernels don't directly address auth related issues with regards to web applications they do address auth issues for the underlying operating system that the application runs on. Every single web application, whether its self hosted on a ubuntu instance in amazon or using lambda or perhaps is using an even higher level provider such as Vercel or Netlify will stil be using linux as it's underlying operating system and that system will still have authentication issues.

Just a few days ago we saw multiple CVEs in the newer "safer" sudo-rs tool that replaces the 45 year old sudo tool.

Once again you'll want to take care at the application level but at the system level many of these issues are not as severe or completely absent when running unikernels. You can't brute force ssh for instance as there is no ssh to begin with. There are no system passwords as there are no system users. Just to be clear here - just cause OWASP is web oriented doesn't mean you can ignore the underlying operating system. You need to look at it holisticly.

A08_2025 Software or Data Integrity Failures

This is becoming a larger issue as many CI/CD pipelines now download large amounts of dependencies from repos such as maven, npm. We've seen quite a few npm worms and other related attacks on npm this past year. Similarily, java deserialization issues continue to be a widespread problem.

While both of these remain an issue on unikernel systems, once again we find that the blow is softened. If you accidently deploy a node application with malware from npm it may or may not be a problem. If it is all self-contained code in javascript the malware still might work but if it tries to shell out and start running a bunch of other programs that will not work.

The same similar issue with deserialization attacks are present. If an attacker can upload a new class file and conduct all their work inside of that using only java then there would still be a problem. However, we find in practice most attackers will call out to something like ProcessBuilder or Runtime.Exec to continue their attack. Both of these are not viable in unikernels.

A09_2025 Logging and Alerting Failures

Like many of the other categories this is a mixed bag. For instance it still remains important to redact sensitive data from log files as much as you can but encoding data properly becomes less of an issue.

Similarily, the need to audit certain events such as logins, failed logins goes away because unikernels do not have the notion of users and thus logging for suspicious commands also goes away.

A10_2025 Mishandling of Exceptional Conditions

This is a new category for 2025. A common example for this category is that you trigger something like a sql error server-side and instead of returning a more human-friendly error message you return the actual sql error itself which can expose sensitive data about how the data is stored. (CWE-550).

This category also seems to "catch" a bunch of other stuff too. For instance null pointer derefs and CWE-280 - Improper Handling of Insufficient Permissions are listed here. Again the lack of having distinct system users along with their permissions makes a few categories here less intense.

The OWASP Top 10 Remains Relevant

Unikernels can prevent some of these issues entirely while softening the blow from others.

As we've discussed the OWASP Top 10 not only remains highly relevant but since things have not gotten better and have only gotten worse it seems to be even more relevant today. You can't rely on education alone -- you must use the full toolbelt at your disposal, and unikernel runtime isolation and exploit mitigation is an excellent tool to defend against the OWASP Top 10.