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.
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
· SAM
· Application
∘ Trivy Report
∘ Scout report
· SAM local testing
· SAM deployment
· Conclusions and further work
Pre-deployment
- 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
SAM
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
Application
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
FROM public.ecr.aws/lambda/python:3.8
COPY app.py requirements.txt ./
RUN yum -y install tar gzip
RUN curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh -s -- -b /usr/local/binCMD ["app.lambda_handler"]
Scout report

Dockerfile for Scout
FROM public.ecr.aws/lambda/python:3.8COPY app.py 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"]
Requirements.txt
scoutsuite
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.