Securing Your Container Pipeline: Using AWS Inspector with GitHub Actions

As an AWS Community Builder, I'm excited to share a practical approach to integrating security scanning into your container deployment pipeline. Today, I'll walk you through an example GitHub repository that demonstrates how to use the AWS Inspector Vulnerability Scan GitHub Action to scan Docker images before they're pushed to Amazon ECR. The Container Security Challenge Containers have revolutionised how we deploy applications, but they also introduce unique security challenges. A common misconception is that containerisation automatically guarantees security. In reality, containers can harbour vulnerabilities in their base images, dependencies, or application code. Enter AWS Inspector and GitHub Actions To address this challenge, I'd like to highlight this example repository that demonstrates a complete workflow for building, scanning, and deploying Docker containers with built-in security controls. The repository implements a GitHub Actions workflow that: Builds your Docker image Scans it for vulnerabilities using AWS Inspector Only pushes to ECR if the image meets your defined security thresholds How the Workflow Works At its core, the workflow uses the Vulnerability Scan GitHub Action for Amazon Inspector, which integrates with AWS Inspector to perform comprehensive vulnerability scanning on your container images. Here's a key section from the workflow file that handles the scanning: - name: Scan built image with Inspector uses: aws-actions/vulnerability-scan-github-action-for-amazon-inspector@v1 id: inspector with: artifact_type: 'container' artifact_path: '${{ steps.login-ecr.outputs.registry }}/${{ env.ECR_REPOSITORY }}:${{ github.sha }}' critical_threshold: ${{ env.CRITICAL_THRESHOLD }} high_threshold: ${{ env.HIGH_THRESHOLD }} medium_threshold: ${{ env.MEDIUM_THRESHOLD }} low_threshold: ${{ env.LOW_THRESHOLD }} other_threshold: ${{ env.OTHER_THRESHOLD }} The workflow includes configurable thresholds for different vulnerability severity levels, allowing you to define what constitutes an acceptable level of risk for your organisation: env: CRITICAL_THRESHOLD: 0 # No critical vulnerabilities allowed HIGH_THRESHOLD: 0 # No high vulnerabilities allowed MEDIUM_THRESHOLD: 5 # Up to 5 medium vulnerabilities allowed LOW_THRESHOLD: 5 # Up to 5 low vulnerabilities allowed OTHER_THRESHOLD: 5 # Up to 5 other vulnerabilities allowed Why You Should Implement Container Scanning 1. Catch Vulnerabilities Before Deployment By scanning container images during the build process, you prevent vulnerable containers from ever being pushed to your registry. This provides a critical security checkpoint at the beginning of your deployment pipeline. The example repository demonstrates a fail-fast approach: - name: Fail job if vulnerability threshold is exceeded run: exit ${{ steps.inspector.outputs.vulnerability_threshold_exceeded }} 2. Regular Scanning Identifies New Vulnerabilities New vulnerabilities are discovered constantly. By implementing scheduled builds of your container images (e.g., weekly), you can leverage this scanning mechanism to identify when previously secure images become vulnerable due to newly discovered CVEs. This proactive approach means you'll discover vulnerabilities through your CI/CD pipeline rather than through a security incident. 3. Improved Security Posture Implementing this scanning workflow significantly improves your overall security posture by: Creating a Software Bill of Materials (SBOM) for each image Establishing clear security standards through configurable thresholds Providing audit trails of security scanning results Integrating security directly into your development workflow 4. Streamlined Deployment Process The workflow not only scans but also handles the complete deployment process to ECR, making it an all-in-one solution for secure container deployment. Important Security Considerations While this scanning approach significantly improves your container security, it's crucial to understand that it doesn't absolve you of all security responsibilities. Container scanning focuses on known vulnerabilities in the container image, but it doesn't: Detect runtime security issues Protect against misconfigurations in how the container is deployed Replace the need for network security controls Eliminate the need for regular patching of running containers You should combine this approach with other security practices like runtime protection, network policies, and regular updates to running containers. Cost Considerations Before implementing this solution, it's important to understand the cost structure for AWS Inspector in your region. For the Sydney (ap-southeast-2) region, the pricing is: ECR Container Image Scanning: Initial scan on push to ECR: $0.09 per image Au

Mar 15, 2025 - 04:32

Securing Your Container Pipeline: Using AWS Inspector with GitHub Actions

As an AWS Community Builder, I'm excited to share a practical approach to integrating security scanning into your container deployment pipeline. Today, I'll walk you through an example GitHub repository that demonstrates how to use the AWS Inspector Vulnerability Scan GitHub Action to scan Docker images before they're pushed to Amazon ECR.

The Container Security Challenge

Containers have revolutionised how we deploy applications, but they also introduce unique security challenges. A common misconception is that containerisation automatically guarantees security. In reality, containers can harbour vulnerabilities in their base images, dependencies, or application code.

Enter AWS Inspector and GitHub Actions

To address this challenge, I'd like to highlight this example repository that demonstrates a complete workflow for building, scanning, and deploying Docker containers with built-in security controls.

The repository implements a GitHub Actions workflow that:

Builds your Docker image
Scans it for vulnerabilities using AWS Inspector
Only pushes to ECR if the image meets your defined security thresholds

How the Workflow Works

At its core, the workflow uses the Vulnerability Scan GitHub Action for Amazon Inspector, which integrates with AWS Inspector to perform comprehensive vulnerability scanning on your container images.

Here's a key section from the workflow file that handles the scanning:

- name: Scan built image with Inspector
  uses: aws-actions/vulnerability-scan-github-action-for-amazon-inspector@v1
  id: inspector
  with:
    artifact_type: 'container'
    artifact_path: '${{ steps.login-ecr.outputs.registry }}/${{ env.ECR_REPOSITORY }}:${{ github.sha }}'
    critical_threshold: ${{ env.CRITICAL_THRESHOLD }}
    high_threshold: ${{ env.HIGH_THRESHOLD }}
    medium_threshold: ${{ env.MEDIUM_THRESHOLD }}
    low_threshold: ${{ env.LOW_THRESHOLD }}
    other_threshold: ${{ env.OTHER_THRESHOLD }}

The workflow includes configurable thresholds for different vulnerability severity levels, allowing you to define what constitutes an acceptable level of risk for your organisation:

env:
  CRITICAL_THRESHOLD: 0  # No critical vulnerabilities allowed
  HIGH_THRESHOLD: 0      # No high vulnerabilities allowed
  MEDIUM_THRESHOLD: 5    # Up to 5 medium vulnerabilities allowed
  LOW_THRESHOLD: 5       # Up to 5 low vulnerabilities allowed
  OTHER_THRESHOLD: 5     # Up to 5 other vulnerabilities allowed

Why You Should Implement Container Scanning

1. Catch Vulnerabilities Before Deployment

By scanning container images during the build process, you prevent vulnerable containers from ever being pushed to your registry. This provides a critical security checkpoint at the beginning of your deployment pipeline.

The example repository demonstrates a fail-fast approach:

- name: Fail job if vulnerability threshold is exceeded
  run: exit ${{ steps.inspector.outputs.vulnerability_threshold_exceeded }}

2. Regular Scanning Identifies New Vulnerabilities

New vulnerabilities are discovered constantly. By implementing scheduled builds of your container images (e.g., weekly), you can leverage this scanning mechanism to identify when previously secure images become vulnerable due to newly discovered CVEs.

This proactive approach means you'll discover vulnerabilities through your CI/CD pipeline rather than through a security incident.

3. Improved Security Posture

Implementing this scanning workflow significantly improves your overall security posture by:

Creating a Software Bill of Materials (SBOM) for each image
Establishing clear security standards through configurable thresholds
Providing audit trails of security scanning results
Integrating security directly into your development workflow

4. Streamlined Deployment Process

The workflow not only scans but also handles the complete deployment process to ECR, making it an all-in-one solution for secure container deployment.

Important Security Considerations

While this scanning approach significantly improves your container security, it's crucial to understand that it doesn't absolve you of all security responsibilities. Container scanning focuses on known vulnerabilities in the container image, but it doesn't:

Detect runtime security issues
Protect against misconfigurations in how the container is deployed
Replace the need for network security controls
Eliminate the need for regular patching of running containers

You should combine this approach with other security practices like runtime protection, network policies, and regular updates to running containers.

Cost Considerations

Before implementing this solution, it's important to understand the cost structure for AWS Inspector in your region. For the Sydney (ap-southeast-2) region, the pricing is:

ECR Container Image Scanning:

Initial scan on push to ECR: $0.09 per image
Automated rescans for continuous scanning: $0.01 per rescan

On-demand Container Image Scanning (including within CI/CD solutions):

$0.03 per image scanned

For most organisations, this cost is minimal compared to the potential cost of a security incident. For example, if you build and scan 100 container images per month with this workflow, your cost would be approximately $3.00 per month.

Setting Up the Solution

The example repository provides detailed instructions for setting up:

OIDC authentication between GitHub and AWS
Required IAM roles with appropriate permissions
GitHub Secrets configuration
Example Dockerfile with security best practices

The implementation uses role chaining for enhanced security, ensuring that your GitHub Actions have only the minimum permissions required.

Conclusion

The docker-ecr-github-action-inspector-scanner-example repository provides a production-ready solution for integrating container security scanning into your deployment workflow. By implementing this approach, you create a strong first line of defense against container vulnerabilities.

Remember that security is a continuous process. Using this scanning approach in combination with regular scheduled builds gives you a powerful mechanism for identifying and addressing new vulnerabilities before they impact your production environment.

Have you implemented container scanning in your workflows? I'd love to hear about your experiences in the comments below!