The First “Serverless Architectures Security Top 10” Guide Released

Download the “Serverless Architectures Security Top 10” Guide

Today, we are launching the “Serverless Architectures Security Top 10” project – this project is meant to provide assistance and education for organizations looking to adopt serverless architectures. This document is not a secure coding best practices, but rather a list of the top most common weaknesses that are found in serverless applications. The research for the list was done by a strong group of security experts, industry practitioners and top notch serverless aficionados.

Serverless architectures enable organizations to build and deploy software and services without having to own or provision any physical or virtual servers. Applications built using serverless architectures are suitable for a wide range of services, and can scale elastically as cloud workloads grow.


In essence, when you develop applications using serverless architectures, you relieve yourself from the daunting task of having to constantly apply security patches for the underlying operating system and application servers – these tasks are now the responsibility of the serverless architecture provider.

If you are a developer – this sounds like heaven, right? Hold on…there’s a fly in the ointment. You are still responsible for designing robust applications and making sure that your code doesn’t introduce application layer vulnerabilities. Moreover, any configuration related to the application itself or to cloud services it interacts with would still need to be secure – again, that’s your responsibility. In the serverless world, the cloud vendor and you share security responsibilities.

The following image, demonstrates the shared security responsibilities model, adapted to serverless architectures:

Shared_Model_Of_Responsibility.png

The comfort and elegance of serverless architectures is not without its drawbacks – serverless architectures introduce a new set of issues that must be taken into consideration when securing such applications:

  • Increased attack surface: serverless functions consume data from a wide range of event sources such as HTTP APIs, message queues, cloud storage, IoT device communications and so forth. This increases the attack surface dramatically, especially when such messages use protocols and complex message structures – many of which cannot be inspected by standard application layer protections such as Web application firewalls
  • Attack surface complexity: the attack surface in serverless architectures can be difficult for some to understand given that such architectures are still rather new. Many software developers and architects have yet to gain enough experience with the security risks and appropriate security protections required to secure such applications
  • Overall system complexity: visualizing and monitoring serverless architectures is still more complex than standard software environments
  • Inadequate security testing: performing security testing for serverless architectures is more complex than testing standard applications, especially when such applications interact with remote 3rd party services or with back-end cloud services such as NoSQL databases, cloud storage, or stream processing services. In addition, automated scanning tools are currently not adapted to scanning serverless applications:
    • DAST (dynamic application security testing) tools will only provide testing coverage for HTTP interfaces. This poses a problem when testing serverless applications that consume input from non-HTTP sources, or interact with back-end cloud services. In addition, many DAST tools have issues to effectively test web services (e.g. RESTful services) which don’t follow the classic HTML/HTTP request/response model and request format.
    • SAST (static application security testing) tools rely on data flow analysis, control flow and semantic analysis to detect vulnerabilities in software. Since serverless applications contain multiple distinct functions that are stitched together using event triggers and cloud services (e.g. message queues, cloud storage or NoSQL databases), statically analyzing data flow in such scenarios is highly prone to false positives. In addition, SAST tools will also suffer from false negatives, since source/sink rules in many tools do not take into account FaaS constructs. These rule sets will need to evolve in order to provide proper support for serverless applications.
    • IAST (interactive application security testing) tools have better odds at accurately detecting vulnerabilities in serverless applications when compared to both DAST and SAST, however, similarly to DAST tools, their security coverage is impaired when serverless applications use non-HTTP interfaces to consume input. In addition, some IAST solutions require that the tester will deploy an instrumentation agent on the local machine, which is not an option in serverless environments  
  • Traditional security protections (Firewall, WAF, IPS/IDS): since organizations that use serverless architectures do not have access to the physical (or virtual) server or its operating system, they are not at liberty to deploy traditional security layers such as endpoint protection, host-based intrusion prevention, web application firewalls and so forth. In addition, existing detection logic and rules have yet to be “translated” to support serverless environments    

Today, we are launching the “Serverless Architectures Security Top 10” project – this project is meant to provide assistance and education for organizations looking to adopt serverless architectures. This document is not a secure coding best practices, but rather a list of the top most common weaknesses that are found in serverless applications. The research for the list was done by a strong group of security experts, industry practitioners and top notch serverless aficionados.

For ease of reference, we marked each category of the Top 10 list with a unique identifier in the form of SAS-[NUM]. The list is organized in order of criticality from SAS-1…10, where SAS-1 indicates the most critical risk, and SAS-10 the least critical risk. Keep in mind that the list is not exhaustive in any way, in fact, we are aware of additional common weaknesses (stay tuned for additional blog posts), but in order to make the data actionable and effective, we decided to concentrate on a short list of the top issues.

So, enough with the opening statements, here is the short list for 2018:

Serverless_Security_Top_10_List.pngThe Top 10 list ( Link ) covers the research in great detail, providing explanations, real world examples, code snippets and recommendations for mitigation. We hope you will find it helpful and make good use of it – and hope to receive your comments or feedback.



This is a Security Bloggers Network syndicated blog post authored by Ory Segal, PureSec CTO. Read the original post at: PureSec Blog (Launch)