In January 2018, PureSec, the leader in serverless security released the Serverless Security Top 10 Risks Guide, which was well-received by key players in the serverless industry and was covered by top news outlets. The report was based on preliminary data and feedback from serverless evangelists and thought leaders from leading companies.
Download the CSA “12 Most Critical Risks for Serverless Applications 2019” Guide.
puresec.io
Since then, serverless adoption has seen tremendous growth, providing access to more data on how organizations harness serverless, their approach to serverless development, and the most common recurring mistakes related to security and privacy of serverless applications.
In addition, in the year that passed, new mitigation approaches have surfaced and became standardized, such as serverless security platforms, as well as new features offered by cloud providers, which can help with improving serverless security posture.
Download 12 Most Critical Risks for Serverless Applications 2019
In February 2019, the Cloud Security Alliance (CSA) collaborated with PureSec to release a new guide titled “The 12 Most Critical Risks for Serverless Applications,” which includes additional input and feedback from several dozens of serverless industry thought leaders, and is the most comprehensive effort to classify the potential risks for applications built on serverless architectures to date. The report was written for both security and development audiences dealing with serverless applications, and goes well beyond pointing out the risks. It provides mitigations, best practices and a comparison between traditional applications to their serverless counterparts.
The top 12 Risks listed in the document are listed below, with a short description for each of them:
1: Function Event-Data Injection
Serverless functions can consume input from each type of event source (AWS offers 47 different event sources that can trigger an AWS Lambda function), and such event input might include different message formats (depending on the type of event and its source). Various parts of these event messages can contain attacker-controlled or otherwise dangerous inputs. This rich set of event sources increases the potential attack surface and introduces complexities when attempting to protect serverless functions against event-data injections. This is especially true because serverless architectures are not nearly as well-understood as web environments where developers know which message parts shouldn’t be trusted (e.g., GET/POST parameters, HTTP headers, etc.). More information on event-data injection can be found in the following blog post, as well as in this post by Jeremy Daly.