Sign in

Trivy and ScoutSuite scans triggered by AWS Lambda packaged in a docker container deployed with SAM

An important challenge in working with containers is making them secure and having a reliable scanning tool may become crucial. It actually exists a vulnerability scanner given by default by AWS using Clair, but our security team is feeling adventurous therefore comes Trivy, an open-source vulnerability scanner modern, frequently updated, and proven effective.

Photo by Harlie Raethel on Unsplash

The scenario describes an AWS account with multiple repositories to analyze with the scanner. In this first story, a solution for a single account is defined, in further posts, we’ll talk about multiple accounts with multiple repositories.

Given the requirements and following the last re:Invent innovations, we decided to give it a try to run trivy on a docker container and take advantage to call it from a lambda function.

There will be a monthly scheduled job that will call an endpoint which will trigger the functions to generate and upload the reports to S3. The security team would have keys granting them access to hit that endpoint, and to the S3 in case they need an on-demand updated report.

· Pre-deployment
· Application
Trivy Report
Scout report
· SAM local testing
· SAM deployment
· Conclusions and further work


  • AWS CLI. Installed and credentials set up (AWS keys or profiles)
  • SAM CLI. Installed
  • ECR repository to store the images the lambdas are going to use: After configuring AWS CLI, Run in the terminal:
aws ecr create-repository --repository-name repository_name


All the AWS elements supporting the solution are exposed in a Cloudformation template with SAM support, those are:

  • The destination bucket name where the reports are going to be uploaded:

Given by parameters also received in CloudFormation format.

  • Security policies to be attached to the functions

Minimal permissions providing read-only access to all environments for Scout scan invoke lambda functions and S3 uploads.

  • Function definitions

We’re defining 3 functions: Scout, Trivy, and Asynccall. Async is a necessary procedure because of the processing time taken by the reports (>180s) which will timeout the 30s limit on synchronous calls.

To notice the newish way to define the functions for docker support.

  • Gateway definitions
  • API key definitions


In the same directory of the template, two folders are created which will contain the code for our two main functions: scout_report,trivy_report (naming is important as it’s referenced in the SAM template).

Trivy Report

The function needs as parameters the repository to be analyzed and the bucket name for the upload’s destinations. Requirements.txt for this app is empty but necessary for SAM.

Dockerfile for Trivy

COPY requirements.txt ./
RUN yum -y install tar gzip
RUN curl -sfL | sh -s -- -b /usr/local/bin
CMD ["app.lambda_handler"]

Scout report

Dockerfile for Scout

FROM requirements.txt ./RUN pip3 install -r requirements.txtRUN pip3 uninstall --yes cryptographyRUN pip3 uninstall --yes pyOpenSSLRUN pip3 uninstall --yes humanfriendly#versions of this packages are not compatible with the installed in the base imageRUN pip3 install cryptography==3.2.1RUN pip3 install pyOpenSSL==19.1.0RUN pip3 install humanfriendly==8.2CMD ["app.lambda_handler"]



SAM local testing

With this CLI command, you may test the behavior of your functions. One should be able to check Cloudwatch logs to track the steps then check S3 if the reports are available.

sam build &&  sam local invoke AsyncCallCreateReportsFunction -e events/event.json

SAM deployment

SAM deployment is controlled with samconfig.toml, a file in the same directory of the template where one should define the deployment parameters. An easy way to configure it is by running the following command and filling in all the asked parameters.

sam deploy -g

Conclusions and further work

Defining the application dependencies in a docker file provides major flexibility in application building. At the moment this SAM template should be deployed in every AWS account needing the scans, the focus for future releases would be on making the solution time efficient and provide to it multiple account access through parameters.

Full time dad, automating the world in my free time

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store