By Ron Perris, Developer Advocate

The rise of the Serverless Application Architecture allows organizations to focus on building valuable features while offloading the work of provisioning and scaling hardware to their cloud computing providers.

Serverless applications often use technologies like AWS Lambda for compute and Amazon API Gateway for accessing that compute functionality. As you are building these serverless applications you can and should automatically test for security issues during development. Catching security issues early makes it much easier and cheaper to fix them.

As you add more functionality to an application the attack surface increases. Just like with other automated tests, it is important to keep your test coverage high. Every API path and corresponding compute function could potentially expose a security related mistake. Modern security testing tools can be used to assess the application for security related bugs during development and before production traffic is sent to new features and functionality.

Common API Security Tests

There are a few common types of security tests you can run on your serverless applications.

The first being a static application security test (SAST), this test will look at your source code and find vulnerabilities related to insecure coding patterns and mistakes. The next type of testing is software composition analysis (SCA), this type of test will look at your project manifest files and detect the use of any dependencies with known security vulnerabilities. The last type is dynamic application testing (DAST), with DAST you are testing all or part of the running application, like a functional integration test would. The DAST scanner will send various predefined inputs to your application and look for evidence of a security bug in the response.

Its a good idea to add a tool that implements each of these test types in your application codebase, ideally in an automated fashion that runs during development and before you release code.

Static Application Security Testing

The most lightweight and popular SAST tools are language specific linters and simple pattern matching scripts that leverage regular expressions.

For linters many JavaScript projects use the ESLint project and its ecosystem of plugins to automatically test for security best practices and common mistakes. Some teams write simple regular expressions and scan the code using grep during development and before release.

There some open source tools that take the idea of linters and pattern matching to the next level like Semgrep, a fast static analysis tool that enforces coding standards and detects common security bugs.

Scanning your Lambda functions with tools like ESLint, grep or Semgrep will allow you to detect all types of security vulnerabilities, such as: Cross-site Script, SQL Injection, Server-side Request Forgery, and many other common security bugs.

You can automate these types of test by adding a GitHub Action that runs on each pull request.

```yaml

name: Semgrep

on: [pull_request]

jobs:

  semgrep:

    runs-on: ubuntu-latest

    name: Check

    steps:

      - uses: actions/checkout@v1

      - name: Semgrep

        id: semgrep

        uses: returntocorp/semgrep-action@v1

        with:

          config: p/r2c

```

Software Composition Analysis

If you are using third-party libraries in your application, you probably are, then you should run a software composition analysis tool to make sure that you're not bringing in any security bugs via your dependencies. The JavaScript ecosystem has `npm audit` which is open source and uses a database of known vulnerabilities to check for issues in the libraries you are using in your code base.

You can scan the dependencies of your serverless application by running individual tools like `npm audit` and OWASP Dependency-Check.

It is easy to automate software composition analysis tests with GitHub Actions. You can run this type of test on interval, pull request, or every branch push.

```yaml
name: npm audit

on:

  pull_request:

  push:

    branches:

      - master

      - 'releases/*'

# on:

#   schedule:

#     - cron: '0 10 * * *'

jobs:

  scan:

    name: npm audit

    runs-on: ubuntu-latest

    steps:

      - uses: actions/checkout@v2

      - name: install dependencies

        run: npm ci

      - uses: oke-py/npm-audit-action@v1.7.1

        with:

          audit_level: moderate

          github_token: ${{ secrets.GITHUB_TOKEN }}

          issue_assignees: oke-py

          issue_labels: vulnerability,test

          dedupe_issues: true

```

Dynamic Application Security Testing

This type of testing finds bugs that attackers are likely to exploit. The tools in this category basically send exploit payloads at a running application and measure the response to determine if the exploit was successful or not. Historically these types of tests were run on production servers, but for obvious reasons it is better to do these exploits in development where they won't do any harm to your applications.

You can setup automated dynamic application security tests using a GitHub Action and the OWASP Zap tool.

```yaml
on: [push]

jobs:

  zap_scan:

    runs-on: ubuntu-latest

    name: Scan the webapplication

    steps:

      - name: Checkout

        uses: actions/checkout@v2

        with:

          ref: master

      - name: ZAP Scan

        uses: zaproxy/action-full-scan@v0.2.0

        with:

          token: ${{ secrets.GITHUB_TOKEN }}

          docker_name: 'owasp/zap2docker-stable'

          target: 'https://www.zaproxy.org/'

          rules_file_name: '.zap/rules.tsv'

          cmd_options: '-a'

```

Automating API Security Testing for Serverless

One of the challenges when running scans against any API is tuning the scan to increase coverage. A major advantage of serverless applications that use Amazon's API Gateway is that it is possible to export the entire API path documentation as an OpenAPI specification.

```sh
aws apigatewayv2 export-api \

            --api-id api-id  \

            --output-type YAML  \

            --specification OAS30 \

            --stage-name prod \

            Stage-definition.yaml

```

You can use the OpenAPI specification file to configure dynamic applications security scanners, such as OWASP Zap or a more developer focused tool like HawkScan.

The results generated by scanners like OWASP Zap and StackHawk's HawkScan can be used to break builds or alert developers to issues that should be fixed before a release is made.

Wrap Up

After you configure these automatic security tests to run along with all your codes other tests, you will have a new level of assurance about the code you are shipping to production. In the future and as new developers join the team the best practices for secure coding will be built into the applications tests and any regressions will be caught quickly and automatically.

##

To learn more about cloud native technology innovation, join us at KubeCon + CloudNativeCon Europe 2021 - Virtual, which will take place from May 4-7.  

ABOUT THE AUTHOR