If you’re developing serverless infrastructure on AWS, the Serverless Framework needs no introduction. It offers simple automation for serverless developers building event-driven serverless architecture and has become the de-facto standard for developing and deploying AWS Lambda functions.
The Serverless Framework also deploys the underlying AWS infrastructure components your events and functions depend upon, with support for everything that can be defined in CloudFormation. For that reason, it’s also exposed to all the same misconfigurations that developers can potentially encounter when developing CloudFormation stacks.
When developing on top of the Serverless Framework for AWS, you’re building ephemeral AWS building blocks used by our events and triggers. Securing the underlying infrastructure that Serverless runs on isn’t very different from standard cloud infrastructure security, but it does require its own policy governance.
We’re excited to announce that Bridgecrew now extends the Serverless Framework’s existing security and compliance policies to secure configured AWS resources. ⚡️
By continuously scanning changes to Serverless YAML files and analyzing the running infrastructure in run-time, Bridgecrew ensures that resource configuration always meets industry best practices and compliance requirements.
In this post, you’ll learn how to use Bridgecrew CLI to identify Serverless misconfigurations such as publicly accessible resources, overprivileged IAM, unencrypted resources, secrets in plain text, and more.
Scanning a single Serverless YAML File
Let’s start by installing Bridgecrew CLI then scanning a Serverless Framework YAML file to identify security configuration issues within the code. First, you’ll need to sign up for a free Bridgecrew account to retrieve your API Token. Head to the Integrations tab and select API Token under the Continuous Integration category. Copy your unique token, and you are ready to install Bridgecrew and scan your first Serverless YAML file.
The simplest way to start scanning is by deploying the Bridgecrew CLI using pip (to install on Linux, Windows, or other setups, check out our CLI documentation).
In your terminal, run:
pip install bridgecrew
Verify Bridgecrew CLI is running:
bridgecrew -v
This should return a version, such as 1.0.463.
Next, we need to point Bridgecrew to a directory containing the serverless.yml we want to scan. Simply paste the directory path after the -d argument and use your API key:
bridgecrew -d . --bc-api-key <key> /serverless --framework serverless
Your output should look something like this:
_ _ _ | |__ _ __(_) __| | __ _ ___ ___ _ __ _____ __ | '_ \| '__| |/ _` |/ _` |/ _ \/ __| '__/ _ \ \ /\ / / | |_) | | | | (_| | (_| | __/ (__| | | __/\ V V / |_.__/|_| |_|\__,_|\__, |\___|\___|_| \___| \_/\_/ |___/ version: 1.0.463 serverless scan results: Passed checks: 5, Failed checks: 7, Skipped checks: 0 Check: CKV_AWS_20: "Ensure the S3 bucket does not allow READ permissions to everyone" PASSED for resource: AWS::S3::Bucket.S3BucketOutputs File: /serverless.yml:35-37 Guide: https://docs.bridgecrew.io/docs/s3_1-acl-read-permissions-everyone Check: CKV_AWS_57: "Ensure the S3 bucket does not allow WRITE permissions to everyone" PASSED for resource: AWS::S3::Bucket.S3BucketOutputs File: /serverless.yml:35-37 Guide: https://docs.bridgecrew.io/docs/s3_2-acl-write-permissions-everyone Check: CKV_AWS_49: "Ensure no IAM policies documents allow "*" as a statement's actions" PASSED for resource: replicate File: /serverless.yml:25-31 Guide: https://docs.bridgecrew.io/docs/bc_aws_iam_43 Check: CKV_AWS_41: "Ensure no hard coded AWS access key and and secret key exists in provider" PASSED for resource: replicate File: /serverless.yml:25-31 Guide: https://docs.bridgecrew.io/docs/bc_aws_secrets_5 Check: CKV_AWS_1: "Ensure IAM policies that allow full "*-*" administrative privileges are not created" PASSED for resource: replicate File: /serverless.yml:25-31 Guide: https://docs.bridgecrew.io/docs/iam_23 Check: CKV_AWS_19: "Ensure the S3 bucket has server-side-encryption enabled" FAILED for resource: AWS::S3::Bucket.S3BucketOutputs File: /serverless.yml:35-37 Guide: https://docs.bridgecrew.io/docs/s3_14-data-encrypted-at-rest 35 | Type: AWS::S3::Bucket 36 | Properties: 37 | BucketName: ${self:custom.outputBucket} Check: CKV_AWS_18: "Ensure the S3 bucket has access logging enabled" FAILED for resource: AWS::S3::Bucket.S3BucketOutputs File: /serverless.yml:35-37 Guide: https://docs.bridgecrew.io/docs/s3_13-enable-logging 35 | Type: AWS::S3::Bucket 36 | Properties: 37 | BucketName: ${self:custom.outputBucket} Check: CKV_AWS_53: "Ensure S3 bucket has block public ACLS enabled" FAILED for resource: AWS::S3::Bucket.S3BucketOutputs File: /serverless.yml:35-37 Guide: https://docs.bridgecrew.io/docs/bc_aws_s3_19 35 | Type: AWS::S3::Bucket 36 | Properties: 37 | BucketName: ${self:custom.outputBucket} Check: CKV_AWS_54: "Ensure S3 bucket has block public policy enabled" FAILED for resource: AWS::S3::Bucket.S3BucketOutputs File: /serverless.yml:35-37 Guide: https://docs.bridgecrew.io/docs/bc_aws_s3_20 35 | Type: AWS::S3::Bucket 36 | Properties: 37 | BucketName: ${self:custom.outputBucket} Check: CKV_AWS_21: "Ensure the S3 bucket has versioning enabled" FAILED for resource: AWS::S3::Bucket.S3BucketOutputs File: /serverless.yml:35-37 Guide: https://docs.bridgecrew.io/docs/s3_16-enable-versioning 35 | Type: AWS::S3::Bucket 36 | Properties: 37 | BucketName: ${self:custom.outputBucket} Check: CKV_AWS_55: "Ensure S3 bucket has ignore public ACLs enabled" FAILED for resource: AWS::S3::Bucket.S3BucketOutputs File: /serverless.yml:35-37 Guide: https://docs.bridgecrew.io/docs/bc_aws_s3_21 35 | Type: AWS::S3::Bucket 36 | Properties: 37 | BucketName: ${self:custom.outputBucket} Check: CKV_AWS_56: "Ensure S3 bucket has 'restrict_public_bucket' enabled" FAILED for resource: AWS::S3::Bucket.S3BucketOutputs File: /serverless.yml:35-37 Guide: https://docs.bridgecrew.io/docs/bc_aws_s3_22 35 | Type: AWS::S3::Bucket 36 | Properties: 37 | BucketName: ${self:custom.outputBucket}Woohoo! You scanned your first serverless.yml file against known misconfigurations! ⚡️
Analyzing scan results
You can see the scan has identified five passing checks and seven failing checks. All seven failed checks are referring to the same S3 bucket configuration on a specific code block. We can now go back to our serverless.yml and troubleshoot the misconfigured S3 bucket block.
Digging in, we find that an S3 bucket we planned to provision is missing all of the additional properties that are intended to tighten its security posture.
For example, the bucket encryption property that specifies the default encryption for a bucket using server-side encryption with Amazon S3-managed keys (SSE-S3) or AWS KMS-managed keys (SSE-KMS) bucket isn’t a required feature. If you don’t explicitly include it in your serverless.yml or in an additional configuration file, buckets that are created as part of your Serverless infrastructure will not be encrypted.
Bridgecrew infrastructure scans for the AWS::S3::Bucket object currently covers nine of these properties to ensure that all block-public-policy requirements are met.
Automating Serverless Framework scanning
To ensure that you aren’t deploying misconfigured Serverless Framework code, it’s best practice to scan on every commit or pull request as part of your code review processes. With Bridgecrew’s source control and CI/CD integrations, you can put guardrails in place at the build level and get continuous alerts when misconfigurations are identified. You can run Bridgecrew as a GitHub Action, a Circle CI orb, or a Jenkins job to get continuous scanning of your Serverless YAML files.
When configuration issues are identified, you can use our AWS policies documentation linked inline in the CLI for individual fixes or defer to the Bridgecrew platform for detailed remediation guidelines as well as the actual code to implement fixes then and there.
Our goal is to empower teams with continuous visibility into their Serverless Framework code so they can take ownership of and prevent security issues from being deployed. By helping developers thwart cloud misconfigurations pre-deployment, it’s our aim to save developers’ time spent fixing issues down the road in production and improve their applications’ overall cloud security posture.
To stay up to date with our growing library of policies across frameworks, resources, and clouds, follow our changelog and subscribe to our blog. 👉
