Serverless is great, but what about the security of my AWS Lambda functions and their dependencies?

Function as a Service (FaaS) platforms patch your operating system dependencies for you, but do nothing to secure your application dependencies, such as those pulled from npm, PyPI, Maven and the likes. These libraries are just as prevalent and just as vulnerable as operating system dependencies, and you—the application owner—are responsible for upgrading or patching them when a vulnerability in them is disclosed.

Furthermore, since attackers know that server dependencies at the operating system level, which are the responsibility of the cloud provider, are patched quickly, they will focus their attention on application code and application dependencies.

To emphasize the complexity of tracking a function’s dependencies, in a recent State of Open Source Security report 2019 Snyk showed that security vulnerabilities in indirect dependencies account for 78% of overall vulnerabilities.

This means that in the majority of the time security vulnerabilities will be found in indirect dependencies that are installed by your top level dependencies. In the npm ecosystem, an average dependency nesting is more than 4 levels deep, making it a tough job to track your dependencies and their security.

Just like developing non-serverless applications, you should seek to protect functions throughout your development lifecycle, starting with the integrated development environment (IDE) using a plugin that can alert you to vulnerabilities in dependencies you require during development-time, such as with VSCode or IntelliJ, and moving on to testing for security in your CI at build-time and before you deploy.

What if there was a tool to help you with security testing in a way that would open automatic pull requests to fix security vulnerabilities as they are discovered, or to break continuous integration (CI) builds in order to avoid deployments when security vulnerabilities are newly introduced?

I shared more insights about Serverless security in a previous post 10 Serverless Security Best Practices that you might be interested in reading later, but for now let’s continue with my own Serverless project story:

How my Serverless functions on AWS are security tested?

With a Serverless platform, it might prove tricky to monitor for security dependencies in those functions that you have deployed. I want to take you on a short tour of I’m doing that with Snyk for my own Serverless side project that I developed with Node.js and deployed to AWS Lambda.

To find and automatically remediate vulnerabilities in your function’s dependencies start by connecting Snyk to a Git repository of your choice.

I tried it out with my own personal repo. I browsed my GitHub repositories to locate bazz, my serverless project and once my project was scanned I too became aware of security vulnerabilities in dependencies that are in use by my lambda functions:

Oh my! Quite a few vulnerabilities I have for both my frontend project, and for the serverless functions API service! It’s time to make them disappear. I can mitigate them either manually by opening a fix PR from the Snyk UI in each project page, or the Snyk bot can pick them up and open an automatic PR in my repository on my behalf. All I have to do is watch the tests pass, and merge the PR in! Take a look:

Enforce secure deployments for Serverless functions

In addition to CI and source code repository monitoring and proactive patching for security vulnerabilities, the deployment workflow for a function should also be subject to security review and deployments should be ceased when vulnerabilities are found in functions as they are deployed.

Enforcing open source security monitoring on serverless deployments adds another layer of defense to ensure that functions aren’t being deployed to their target environments while carrying known open source vulnerabilities in dependencies with which the functions are bundled.

The Serverless framework is a common toolkit used to develop and deploy serverless functions. Its plugin architecture enables integrating custom workflows as part of the function lifecycle. Snyk offers an open source Serverless plugin that seamlessly integrates with the framework.

Following is a picture that demonstrates the plugin actively protecting a function from being deployed because security vulnerabilities are detected in the open source dependencies:

It is further advised to set up the Serverless framework plugin to take the project’s dependency snapshots for each deployment so that they can be monitored in order to identify new vulnerabilities when discovered. A solution like Snyk can alert and automatically remediate the issue by automatically opening Pull Requests that fix the insecure dependencies.

Sometimes more customization and control is required for the serverless CI/CD workflow. This is where the open source Snyk command line utility comes in handy and allows a flexible security tool for developers and DevOps engineers to adopt within their workflows.

One can choose to install Snyk in a local environment or in a CI job where the serverless project is being built, and execute snyk test to find vulnerabilities, just like this:

$ npm install -g snyk
$ snyk test

Fixing security vulnerabilities as soon as you can is a good practice to follow, however there is still potential for discrepancies between dependency versions in the source code repository and their versions in the actual deployed function. This mostly happens due to delays introduced when promoting the code to a staging or production environment, because of which the deployed function is at risk of being bundled with outdated dependencies that may have known vulnerabilities.

Finally, don’t forget to check-out this list I compiled of thorough 10 Serverless Security Best Practices!