Serverless security
Serverless security covers securing functions and managed services where the provider operates the runtime and the customer supplies only code and configuration. Patching the host stops being the customer’s problem, and identity, event input and dependencies become the whole of it.
What changes is the boundary described by the shared responsibility model. There is no operating system to harden, no agent to install and no long-running process to inspect, which removes a class of work and a class of visibility at the same time. What is left is code, its dependencies, the permissions attached to it and the events that invoke it.
Two things account for most findings. Permissions that should be granted per function are often granted per application instead, so a function that writes to one queue holds the rights of everything in the deployment, and each function is a non-human identity that deserves its own. And input arrives from many more places than an HTTP request: a queue message, an object upload, a database change, a scheduled event, a notification from another service. Code written to trust an internal event source is code that validates nothing, and internal sources can often be written to by someone who should not be able to.
Three consequences are worth stating when scoping an engagement. Secrets placed in environment variables are readable by anything that can invoke or describe the function. Execution is short, so memory resident persistence is impractical, but modifying the deployment package or a shared layer is quiet and durable. And with no host, the evidence trail is entirely in provider logs, which have to be enabled before an incident, not after. Examining that is part of the cloud testing where each function’s own identity and triggers are examined.