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.
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.
I'm sitting on a toolkit for this, just need to spend a Sunday polishing it to release quality:
(This doesn't rule out paying a lot of attention to security, of course).
For example, a state-level actor can afford to train and place operatives into an AWS-scale organization with enough access to infiltrate and undermine the system.
Edit: I don't mean to sound negative, I think serverless structure is finally the realization of what "cloud" has promised and not quite delivered for so many years.
What we have been doing is using typescript interfaces to validate our API input data. This really makes the data validation painless for us.
EDIT: Thinking about this a little more, this really only ensures that the provided data is the right "shape", there may still need to me more validation performed.
I think this is critical. The fact that there aren't many battle-tested frameworks out there writing your own functions can introduce security bugs. But from my experience, most of the use of Serverless code are very backend, cronjob type of code, and aren't necessarily tied to any real applications. Remote execution is still possible though. I am not sure how many people out there run their website in API Gateway. I've read about one or two stories, but that's it.
Another thing is not security-related, but more with reliability. Serverless development poses challenge for performance monitoring.