alt Hacker News> Not really, no. If you're running an application server, then your entire app can get compromised if there's a security exploit in any of your app code, your web server, your kernel, your hypervisor.
That's really not how it works. You reach the compromise part if all layers are compromised. You don't reach the inner layers if you can't go past an outer layer. You're saying that if there is only one layer that is compromised, or all layers are compromised, your app can be compromised. But you're leaving out when you can't go through every single layer. That's the whole premise of defense in depth.
Replies
Sure, if you're only worried about local exploits in your stack then keeping your top level application secure means the rest of your stack isn't exploitable. The rest of your stack still exists though and inputs go through all of it before they get to your application so if there is a remote exploit in some part of the stack it doesn't matter how secure your application is. For examples see php2shell, broccoli2Shell, the use-after-free in the IP layer in the kernel (exploitable via MPTCP), and some more that I'm probably forgetting that have happened recently.
You’re both right. If your application is strictly and perfectly layered then you need a vuln through each level in the stack. But in reality apps aren’t strictly layered so you just need “a path” through with the vulns you have. And in most non-trivial apps there are many distinct available paths.
It is how it works, though not all exploits are the same severity of course.
Say I find a vulnerability in OpenAI's API layer. That might allow me to run requests without paying for the actual token counts, or allow me to read prompts sent by other users hitting the same instance.
Now say I find a vulnerability in the web server that OpenAI's API uses, that gives me remote code execution in the web server process - I can do all of the above, but for any API that they expose, not just the Responses API. I might even be able to serve malicious JS to other users who hit the same server, if JS were also served from it.
Now say I find a vulnerability in the Linux kernel on which this webserver is running. Not only can I do everything above, but I can probably access a lot of secret data stored on this machine, and maybe even infect other machines that connect to it, such as when a dev SSHs into it.
Now say I find a vulnerability for the hypervisor running the VM where that kernel was running. Now I can not only do everything above, but also infect multiple instances, including perhaps access to like a KV cache or model weights if they happen to be stored on VMs in the same hypervisor.
In all of these cases, I am hacking a single layer, but that allows me to gain access to all of the layers above it. Defense in depth makes sure that finding an API-level bug doesn't allow me to break out of the process or the VM, so it limits the damage I can do, but my app is still compromised, overall.