What Is Serverless Security?

Serverless removes the server as something you patch, harden or monitor, which genuinely eliminates a category of work. It does not reduce the attack surface so much as redistribute it — into permissions, dependencies, event sources and the sheer number of small components involved.

The controls you are used to mostly do not apply. There is no host to install an agent on, no long-running process to observe, and frequently no network boundary in the conventional sense.

Permissions are the primary control

Each function runs with an identity, and that identity's permissions bound what a compromise achieves. The pattern that causes real damage is uniform: one broad role shared across many functions because scoping each one individually was tedious.

The consequence is that a vulnerability in the least important function — the one that resizes images, or forwards a notification — yields the permissions of the most important one. Per-function roles are more work and they are the difference between an incident confined to one component and an incident across the account.

Event sources are inputs, and inputs are untrusted

Functions are triggered by events: an object uploaded, a message queued, a schedule firing, an API call. Every one of those is input from somewhere, and developers frequently treat internal event sources as trustworthy because they originate inside the account.

They should not be. A queue message, a file dropped into storage or a database change stream can all carry attacker-controlled content, and validating only the ones that arrive over HTTP leaves the rest unchecked.

What changes operationally

Dependencies matter more than usual, because a function is mostly library code around a small amount of your own. A vulnerable package in a function is the function's main risk surface, which makes composition analysis more important here than almost anywhere else.

Observability is also harder. A request may traverse a dozen functions, each logging separately, with no single trace unless one was deliberately instrumented. Investigating an incident across that estate without distributed tracing is extremely difficult, and the time to arrange it is before the incident.

Sprawl is a security problem, not just an operational one

Functions are trivial to create, which means they accumulate. A mature serverless estate contains functions nobody owns, deployed for a project that ended, still holding permissions and still reachable by whatever triggers them.

Each one is an unmaintained dependency surface with live credentials. Nobody is patching its libraries, nobody reviews its permissions, and it will not appear in any conversation about risk because nobody remembers it exists.

Periodic review of functions by last-invocation date is a cheap and effective control. Anything not invoked in months is a candidate for removal, and removing it eliminates both the dependency risk and the permissions in a single action.

Where to start

Count how many distinct roles your functions use. If the number is far smaller than the function count, you have a shared-permission problem, and narrowing it is the highest-value change available.

See cloud security best practices. GuardsArm runs cloud security assessments.