Build, Publish, Secure: AWS CodePipeline Now Simplifies ECR Publishing and Vulnerability Scans

Tired of setting up CodeBuild just to push Docker images or run vulnerability scans?

With AWS CodePipeline's new ECRBuildAndPublish and InspectorScan actions, you can now build, publish, and secure your images directly within your pipeline—no extra setup needed. Curious how it works? Let’s dive in!

Motivation

26 November, 2024 – Just ahead of re:Invent 2024, AWS released an exciting update introducing ECRBuildAndPublish and InspectorScan actions. This update simplifies building and publishing Docker images, letting your pipeline handle it seamlessly.

What Does This Update Mean for You?

Before the Update 😭

To incorporate Docker image builds and vulnerability scans into your pipeline, you had to manually configure a CodeBuild project. This involved:

• Setting up CodeBuild project configurations.
• Managing IAM roles and permissions to ensure secure access to ECR and other resources.
• Writing and maintaining a buildspec.yml file with commands to build and push Docker images.
• Integrating third-party security tools for scanning images or source code, requiring additional setup and cost.
• Handling the associated learning curve and operational overhead, which could delay your pipeline delivery.

After the Update 🤩

With the new ECRBuildAndPublish and InspectorScan actions in CodePipeline, all of this complexity is removed:

• You simply define the ECR repository name and point to the Dockerfile in your source code repository.
• CodePipeline automatically builds the image, pushes it to ECR, and even integrates a vulnerability scan—all without requiring a separate CodeBuild project.
• This means less time spent on setup, reduced complexity, and fewer resources consumed.

This update not only simplifies pipeline configuration but also lowers the barrier to entry for automating containerized workflows, enabling teams to focus more on innovation rather than operational details.

Key Notes on These Actions

• ECRBuildAndPublish action is not the same as the Amazon ECR source action in CodePipeline, which triggers pipeline when a change occurs in your Amazon ECR source repository.

• Both actions utilize CodePipeline-managed CodeBuild compute, incurring separate AWS CodeBuild charges.

See It in Action: Setting Up ECRBuildAndPublish and InspectorScan in CodePipeline

Prerequisites

• Access to AWS account
• Already created an Amazon ECR repository
• Dockerfile

Note: I am using a vulnerable DockerFile containing Log4j cve for this blog to show the results of vulnerability scan by code pipeline action. DON'T USE IT IN PRODUCTION

• Dockerfile repo : https://github.com/jatinmehrotra/log4jpoc

Create the ECR repository

• Create a new repository, you can name anything you want

Create the Pipeline

• Create a new codepipline using Build custom pipeline option.

• I am using GitHub as source provider meaning any change to my repository will trigger pipeline to run. You will need to configure codestar connection.

• Add ECRBuildAndPublish action and specify your ECR repository

• Skip Deploy stage and create the pipeline.

• The pipeline will automatically run and push the image to ECR

Note: If you see error toomanyrequests: You have reached your pull rate limit. You may increase the limit by authenticating and upgrading then try to use the base image from AWS ECR public gallery

A big Problem 🚨

• At the moment of writing this blog, when you create pipeline from console ( this has been the default options for long ), when I create pipeline from console it is automatically executed.

• Now this is a very big problem only in the case of ECRBuildAndPublish action because if a vulnerable docker image will be pushed to ECR and what if the downstream system like K8 deploys container from that image and then a vulnerable application will be deployed which can huge problem.

• This is a problem because during creation of Pipeline from console you cannot add any other stage or action to check vulnerabilities, thus fail the pipeline execution and prevent image being published to ECR repository.

• I advise people to use IaC to have more control until this is fixed on console.

Testing AWS InspectorScan

• You can InspectorScan action in two mode: SourceCodeScan or ECRImageScan

• I have used Repository which container both Source Code vulnerabilities as well Docker Image vulnerabilities.

• For me the ideal place to add both the actions and secure my CI/CD would be as follows:

  • Add InspectorScan action's SourceCodeScan before ECRBuildAndPublish action (Build stage)
  • Add InspectorScan action's ECRImageScan after ECRBuildAndPublish action

Testing InspectorScan's SourceCodeScan

• Edit the pipeline
• Add the stage, I am giving name as scan-code

• add action group to the stage and edit it

• Add action provider as Aws Inspector Scan

• Select run mode as Source Code Scan

• Specify threshold values for Critical, High, Medium, Low as 0. This is very important to fail the pipeline as it means the number of Critical,High, Medium, Low severity vulnerabilities found in your source beyond which CodePipeline should fail the action.

• specify the name of the output artifact of your choice and save the pipeline changes and manually run the pipeline.

• As you can see the pipeline failed before the execution reached ECRBuildAndPublish action (Build Stage)

Testing InspectorScan's ECRImageScan

• ECRImageScan scans the images present in ECR repository. If image with tag is not present the action will fail automatically.

• We need to add action after ECRBuildAndPublish action, so the steps remain same as Source Code Scan.

• I will add new stage and action to for scanning pushed docker images inside ECR repostiory.

• In order to pass the pipeline I will remove the threshold values form Source Code Scan to pass the execution till ECRImageScan.

• Save and manually run the Pipeline

From Solutions Architect Perspective

• The introduction of ECRBuildAndPublish and InspectorScan actions in AWS CodePipeline marks a significant step forward in simplifying containerized workflows. By eliminating the need for additional CodeBuild setups and seamlessly integrating security scans, AWS has made pipelines faster and more accessible.

• However, the automatic execution of pipelines created via the console raises valid security concerns, particularly with vulnerable images potentially being pushed to ECR. Until AWS introduces a fix, Infrastructure as Code (IaC) remains the best way to maintain control over your pipeline.

This update is a game-changer for teams looking to innovate faster while ensuring robust security measures.

📣 What are your thoughts on these updates?

🔍 Have you encountered similar challenges or found creative workarounds?

Drop your thoughts in the comments below or connect with me on Linkedin, X, let’s build a stronger, more secure pipeline community together! 🚀