In serverless, the provider secures and patches the platform underneath your function. You remain responsible for your code, the packages you bundle, the permissions you grant, your secrets, your configuration and your data. Serverless removes server patching from your list. It does not remove security work.
What the providers say they handle
The three platform documents we read describe the provider side like this:
- AWS Lambda. AWS describes a shared responsibility model: AWS protects the global infrastructure that runs its cloud, and you control your content hosted on it and the security configuration and management tasks for the services you use. Lambda also terminates execution environments every few hours to allow runtime updates and maintenance.
- Azure App Service, which hosts Azure Functions. Microsoft states the platform segregates apps from each other, updates VMs and runtime software to address newly discovered vulnerabilities, encrypts stored secrets, and runs continuous threat management at the infrastructure level.
- Cloudflare Workers. Cloudflare describes isolating tenants with V8 isolates and layered defenses, and says that when a V8 patch is published it builds a new runtime release and pushes it to production with a patch gap under 24 hours.
In each case the provider describes platform isolation, runtime and OS patching and infrastructure level protections.
What stays with you
The same documents point at the customer side:
- Permissions. The role or identity your function runs with, and who can invoke it.
- Secrets. Where credentials live, who can read them and how they rotate.
- Code and input handling. Microsoft says outright that triggers and bindings do not provide extra data validation, so your code must validate what it receives.
- Dependencies. Libraries you package run with your function's permissions. The platform patches its own runtime, not your node_modules or site packages directory.
- Configuration. Public endpoints, open CORS lists, anonymous access, leftover debug settings.
- Logging and monitoring. Providers offer tools such as Application Insights or CloudTrail. You decide what to collect and who reviews it.
- Data. What you store and under which keys.
Where teams get surprised
- Runtime versions. The platform patches within a runtime, but when a language runtime reaches end of support, moving to a new one is your task.
- Third party layers and extensions. They share permissions, credentials and environment variables with your function, as the AWS lifecycle page notes for extensions.
- Default settings. A default of public or of broad scope is a configuration you inherited, not a platform guarantee.
A one page responsibility map
Make a table for each function with three columns: item, owner, evidence. Rows: runtime patching (provider, link to doc), role permissions (you, link to policy), secrets location (you, link to config), dependency review (you, link to scan), input validation (you, link to tests), public exposure (you, link to endpoint config), logging (you, link to dashboard). Auditors and customers who ask about your serverless posture usually want exactly this.
Quick check
If the provider patches the runtime, do I still need to scan dependencies?
Yes. The platform patches its own runtime. The packages you bundle are yours and run with your function's permissions.
Does serverless mean no one patches servers?
The provider does. That removes one task. The rest of the security work remains.
Safeguard covers the customer side items on this map that involve code and packages: SBOM and dependency scanning, with a free scan.
Sources
- Data protection in AWS Lambda, AWS documentation
- Understanding the Lambda execution environment lifecycle, AWS documentation
- Securing Azure Functions, Microsoft Learn
- Security model, Cloudflare Workers documentation
Last reviewed: 19 October 2026.
