What is serverless computing and what changes for security?

Serverless computing runs your code in short lived functions that a provider starts when an event arrives, such as a web request or a file upload, and bills by use. You stop managing servers, so the provider handles patching the host. You still own your code, dependencies, permissions and the data those functions touch.

What does serverless mean in practice?

You upload a function. The provider decides where and when to run copies of it, scales them up and down, and may run none at all when idle. A function is triggered by an event: an HTTP call, a queue message, a schedule, a database change. It runs, returns and disappears.

In the vocabulary of NIST's cloud computing definition, it sits at the far end of the move from infrastructure toward the provider managing more of the stack, a step beyond platform services.

What does the provider secure, and what do you?

The OWASP Serverless Top 10 project puts it well: adopting serverless removes the need to develop a server, so some threats pass to the infrastructure provider, but the functions still execute code, and if that code is written insecurely it remains vulnerable to application level attacks.

• Provider: physical hosts, operating system patching, isolation between customers, the runtime platform.
• You: function code, third party libraries, event data handling, secrets, permissions, logging and configuration.

How does the attack surface change?

• More entry points. Every trigger is an input: queues, storage events, email hooks, not just HTTP. Each needs validation, because developers often assume internal events are trusted.
• Injection through events. A file name in an upload event or a field in a message can carry hostile content into a command or a query.
• Permissions sprawl. Each function has a role. With dozens of functions, it is easy to give them all the same broad role, so one flaw reaches everything.
• Dependencies. Functions are small but often pull in many packages. Vulnerable or malicious libraries run with the function's role.
• Fewer places to watch. Traditional host agents do not fit, so you rely on logs, traces and code level checks.
• Secrets. Environment variables are convenient and often over exposed. A secrets manager with short lived access is safer.
• Denial of wallet. Because you pay per invocation, a flood of requests can raise costs. Use throttling and budgets.
• Short life helps and hurts. Instances vanish, which limits persistence, but also removes evidence unless you log well.

Constructed example: a function resizes images when a file lands in a storage bucket. It builds a shell command from the uploaded file name. An attacker uploads a file named to include shell syntax, and the command runs with the function's role, which also allows reading every bucket in the account. Two fixes follow: call the image library directly without a shell, and shrink the role to one bucket, read only for input and write only for output.

How to check or apply this

1. Inventory functions, triggers and the role each one uses.
2. Give every function its own minimal role. No shared administrator roles.
3. Validate every event field as untrusted input, whatever the source.
4. Avoid building shell commands or queries from event data. Use parameterized calls.
5. Scan dependencies on each build and remove packages you do not use. Safeguard's dependency scanning and reachability analysis help here by showing which vulnerable code your function actually calls.
6. Move secrets to a secrets manager and rotate them.
7. Set timeouts, memory limits, concurrency caps and spending alerts.
8. Log each invocation with enough context to investigate, and send logs off the function platform.
9. Test locally and in staging with hostile sample events.

Quick check

Sources

• OWASP Serverless Top 10
• NIST SP 800-145, The NIST Definition of Cloud Computing

Last reviewed: 18 October 2026.