It wasn’t long ago that only the most leading-edge technology companies were running cloud native applications. Today, cloud native deployments exist in companies across every sector and every vertical. The biggest benefit from these types of deployments is that they can be deployed anywhere and to any platform without the end user worrying about provisioning resources.
You have probably heard about Kubernetes, Red Hat OpenShift and Docker Swarm which all allow for easy deployment to highly resilient clusters. These technologies are great for applications that require a high level of resilience and scalability, but they require you to keep resources ready and available even when they aren’t being fully utilized. What if you want to run simple tasks? Something like updating a status counter, adding a value to a database, or processing something from an event-driven bus? For a situation like this, a full cluster is probably overkill. This is where serverless architectures can help you.
What is serverless?
Serverless enables devops teams to run stateless functions on demand without managing the underlying resources. For each function you are executing, you don’t have to worry about servers, clusters, resource availability, or any of the other management overhead that typically comes with managing a cloud deployment. The cloud provider’s service, AWS Lambda, Google Functions or Azure Functions, will run your code on a shared resource. This configuration allows for very fast and efficient scalability, while only paying for the resources you use so the cost of unused resources can be saved.
It’s a managed service, what do I need to worry about?
Although serverless functions run on a managed service, they are typically implemented using Java, Node or Python runtime environments. As such, development teams still have to recognize and manage the security of the code. Functions access resources of value, external databases for example, and if the underlying libraries have vulnerabilities or other security issues those resources are put at risk.
Developers, who design and build the serverless application, are ultimately responsible for the security posture of serverless package. They choose the libraries, versions and resources that get included. While developers aren’t always aware of the security implications of their decisions, we want to make vulnerability scanning and remediation easier than ever as part of the build process.
Security teams should screen serverless functions during the build process, as well as monitor existing functions to determine vulnerability posture and decide proper course of action. With vulnerability scanning integrated at build time, developers are presented with new opportunities to fix vulnerabilities before they ever make it out of development — shifting security left and helping developers understand what is vulnerable and how to fix it. Below, you can see an example of a serverless package from Twistlock, which includes Library Type, Version, and known CVEs.
In addition to scanning during the build process, users will also want to keep an eye on the functions that already exist in your serverless library. Here, I highlighted a vulnerability in a Java jar. The screenshot shows information about the vulnerability as well as the Vendor Status which will let the developer know if there is a patch available or if the vendor still needs to provide a fix.
With new vulnerabilities confirmed each day, modern enterprises need a tool that can recognize which of your functions are vulnerable and send alerts to the right person so they can stay on top of the emerging threats. In many cases, users may want to set up Twistlock to automatically publish results to a Slack channel or create a Jira task for the developer who needs to apply a patch.
Serverless Security: A step-by-step walkthrough
In the rest of this blog post, I will show you how to configure Twistlock to perform scanning of an existing AWS Lambda deployment.
- Login to your Twistlock Console and navigate to Defend > Vulnerabilities > Serverless
- Click add serverless account
- Choose the Provider type, Region and Function Name. If you leave this blank we will automatically discover and scan all your functions for this region.
- Enter your credentials. For AWS you can use either the IAM role assigned to the server or an Access/Secret key combination for authentication.
- Click Add
- Twistlock will start the scan in the background
- In the meantime navigate to Monitor > Vulnerabilities > Serverless
- Once the scan is complete, you will see the results which include the total vulnerability count as well as any high risk factors. For example, vulnerabilities that have network attack vectors or are they easily exploitable with a known script.
- Click the row to open further details about the vulnerabilities and function contents
- In this example we can see we have a critical and high vulnerability in our serverless function that affects python.
- We can now let the developers know a patch is required!
Serverless technology is seeing wider adoption because it is a technology that complements existing cloud native applications and deployment pipelines. Some companies are even using serverless to do all their infrastructure and application deployments! As the hosts and clusters are abstracted away, we aren’t responsible for as many security concerns but that doesn’t mean we can leave security up the cloud provider.
Twistlock can ensure that your serverless functions are not exposing critical resources to exploitation. By scanning functions during the build process, we can create a feedback loop to the developer and, by continuously monitoring the existing serverless functions, cover new and emerging threats.
Follow us on Twitter
Follow us on Twitter for real time updates on the cloud native ecosystem, Twistlock product, and cloud native security threats.
Baking Compliance in your CI/CD PipelineRead the Blog
Serverless Security Suggestions: Tips for Keeping Serverless Functions SecureRead the Blog
Why a Common Security Toolset is Essential for DevSecOpsRead the Blog
Putting the “Ops” in DevSecOps: Why It’s Hard and How to Do ItRead the Blog
Why the Point Solution Mindset for IT Security is DeadRead the Blog