[raesene9]

I'm not sure, in practice, how much of a win for serverless reduced patching is, compared to say a containerized environment.

You're still likely to be deploying all the exposed components yourself (i.e. the web application and it's attendant libraries), so the attack surface and possiblity for exploitable vulnerabilities is similar.

There's a win if you're comparing to a setup where you have a load of exposed services that aren't directly related to the application (so management services like SSH) but these days I see a lot fewer of those exposed directly to the Internet from the web server hosts.

What is likely a win is lack of persistence. Attackers need to pull off attacks with limited opportunity for storing something on disk and calling it after the initial compromise, when compared to longer running services.

The thing that becomes totally critical in a serverless architecture is access control and credential management for the underlying cloud platform. Where a load of, for example AWS services are used an attacker who can get access to the console via stolen credentials can do a lot of damage, if IAM profiles haven't been managed properly.

[drvdevd]

Right. You have to authorize to some sort of management layer somewhere. In this case at the cloud API level. It's nice that it's not directly "in band" with the rest of your application code in the same physical address space, like say SSH, but you have no idea of the actual hardware isolation involved, unless you were an engineer building said cloud.

I guess what I'm trying to say is serverless just seems like a way of shifting management layers around, giving the appearance or feeling of less management. I'm not saying thats not valuable - I haven't tried it. This is just my view from the outside.