4: Overprivileged Function Permissions and Roles
A serverless function should have only privileges essential to performing its intended logic—a principle known as “least privilege.” Since serverless functions usually follow microservices concepts, many serverless applications contain dozens, hundreds, or even thousands of functions. Resultantly, managing function permissions and roles quickly becomes a tedious task. In such scenarios, organizations may be forced to use a single permission model or security role for all functions—essentially granting each function full access to all other system components. When all functions share the same set of overprivileged permissions, a vulnerability in a single function can eventually escalate into a system-wide security catastrophe.
5: Inadequate Function Monitoring and Logging
One of the key aspects of serverless architectures is the fact that they reside in a cloud environment, outside of the organizational data center perimeter. As such, “on-premise,” or host-based, security controls become irrelevant as a viable protection solution. This, in turn, means that any processes, tools, and procedures developed for security event monitoring and logging become obsolete. While many serverless architecture vendors provide extremely capable logging facilities, these logs in their basic/out-of-the-box configuration, are not always suitable for the purpose of providing a full security event audit trail. In order to achieve adequate real-time security event monitoring with the proper audit trail, serverless developers and their DevOps teams are required to stitch together logging logic that will fit their organizational needs. For example, they must collect real-time logs from different serverless functions and cloud services. Push these logs to a remote security information and event management (SIEM) system. This will oftentimes require organizations to first store the logs in an intermediary cloud storage service.
6: Insecure Third-Party Dependencies
Generally, a serverless function should be a small piece of code that performs a single discrete task. Functions often depend on third-party software packages, open-source libraries and even the consumption of third-party remote web services through API calls to perform tasks. However, even the most secure serverless function can become vulnerable when importing code from a vulnerable third-party dependency.
7: Insecure application secrets storage
One of the most frequently recurring mistakes related to application secrets storage, is to simply store these secrets in a plain text configuration file that is a part of the software project. In such cases, any user with “read” permissions on the project can get access to these secrets. The situation gets much worse if the project is stored on a public repository. Another common mistake is to store these secrets in plain text, as environment variables. While environment variables are a useful way to persist data across serverless function executions, in some cases, such environment variables can leak and reach the wrong hands.