Lambda makes it easy to run code without managing the underlying infrastructure. The same convenience that draws developers to serverless can paper over security considerations that would be obvious in a traditional deployment. Functions accumulate, permissions sprawl, dependencies age and the surface that nobody is actively defending grows quietly in the background. The platform is sound. The discipline around it is where most issues appear.
Function Permissions Drift Quickly
A new function is created to handle a specific task. The execution role gets configured with the permissions the task requires. Two months later the function gets reused for a related task that needs slightly more access, the role is updated and the original scope expands. Six months later the function is doing things its original designer never imagined, with permissions that the security team would never have approved if asked. Periodic review is the only remedy. A focused AWS pen testing engagement should enumerate every function execution role and evaluate whether the granted permissions match the work the function is doing.
Dependencies Are Still A Supply Chain Concern
Functions tend to ship with their dependencies bundled in the deployment package. Those dependencies often do not get refreshed when new versions are released, which means functions in production may be running against years old library versions with known vulnerabilities. The fact that the function only runs for a few hundred milliseconds at a time does not change the security posture of the code involved.
Expert Commentary
William Fieldhouse, Director of Aardwolf Security Ltd
The most consequential Lambda finding I reported last year involved a function that processed user-supplied images. The function used an image library with a known vulnerability that allowed remote code execution through a crafted file. The function had been in production for two years. The library was three majors behind. The customer found out from us, not from their continuous integration pipeline.
Cold Start Concerns Have Security Implications
Lambda cold starts encourage developers to keep functions warm through periodic invocation. The warming traffic creates an attack surface of its own if not authenticated properly. Treat warmer endpoints as production interfaces with proper authentication and rate limiting, not as internal infrastructure that nobody else will discover. Worth considering whether the warming is genuinely necessary. Sometimes the cold start cost is acceptable for the workload and the additional surface area created by a warming mechanism is not worth the marginal performance gain.
Logging Earns Its Keep In Incident Response
CloudWatch logs from Lambda functions are inexpensive and invaluable during an incident. Log enough context to understand the request path, the identity of the caller and any errors that occurred. Avoid logging sensitive data such as authentication tokens or personal information directly, because the logs themselves become a target. Combine sensible logging with a best pen testing company approach that includes serverless function review explicitly and the response story improves dramatically.
Serverless does not mean securityless. The discipline that you applied to your servers still applies to the functions that replaced them. Serverless security comes down to the same disciplines as everything else. Less infrastructure to manage does not mean less security to consider. Cloud security is a shared responsibility model in name and a fully owned responsibility model in practice. The configuration choices that matter live on your side of the line, regardless of how the provider markets the platform.
