Three Security Checks for Any AWS Pipeline

A developer merges a pull request on a Friday afternoon. The repository is public. The commit includes an AWS access key hardcoded in a config file. Twenty minutes later, an email arrives from AWS Abuse.

By then, someone has already found the key, spun up EC2 instances in three regions, and started mining. The bill reaches $3,000 before the key is rotated.

This is not a rare scenario. It happens because nothing in the pipeline was looking for it.

Code review is manual. Humans miss things, especially on a Friday. The fix is not more careful developers. The fix is automated checks that run before code reaches production.

This article covers three of them. Not the full DevSecOps stack. Just the three controls that catch the most common problems in AWS pipelines, and how to add them to GitHub Actions this week.

What These Three Controls Cover

Each control targets a different layer of the problem.

gitleaks scans for secrets in the code itself. API keys, access tokens, passwords committed to the repository.

checkov scans for misconfigurations in infrastructure-as-code. A Terraform file that creates a public S3 bucket or an IAM policy with * on every action.

ECR Enhanced Scanning scans container images for known vulnerabilities before they run in production.

None of these replace a security team. They catch the obvious mistakes automatically, before they become incidents.

Control 1: Secret Scanning with gitleaks

gitleaks scans every commit for patterns that look like credentials. It knows what AWS access keys look like, what GitHub tokens look like, what Stripe keys look like. You do not need to configure a list of patterns from scratch.

Add this job to your GitHub Actions workflow:

jobs:
  secret-scan:
    name: Secret Scanning
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
        with:
          fetch-depth: 0

      - name: Run gitleaks
        uses: gitleaks/gitleaks-action@v3
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          # GITLEAKS_LICENSE: ${{ secrets.GITLEAKS_LICENSE }}  # Required for GitHub Organizations

The fetch-depth: 0 is important. Without it, checkout only pulls the latest commit. gitleaks needs the full history to scan past commits, not just the new ones.

If you are running this in a GitHub Organization (not a personal account), you need a GITLEAKS_LICENSE. Free licenses are available at gitleaks.io. Without it, the action runs but skips PR comments and some features. For personal repositories, it is not required.

If gitleaks finds a secret, the job fails and the merge is blocked. The developer sees exactly which file and which line triggered the finding.

One thing worth knowing: gitleaks catches patterns, not intent. It will flag a key that is already rotated and useless. That is acceptable. A false positive costs one minute to review. A missed credential costs much more.

Control 2: IaC Linting with checkov

checkov reads your Terraform, CloudFormation, or CDK code and checks it against a list of known misconfigurations. Public S3 buckets without encryption. Security groups open to 0.0.0.0/0. IAM roles with * in the action or resource field.

Add this job:

  iac-scan:
    name: IaC Security Scan
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6

      - name: Run checkov
        uses: bridgecrewio/checkov-action@v12.1347.0
        with:
          directory: .
          framework: terraform
          output_format: cli
          soft_fail: false

Set soft_fail: false if you want the pipeline to block on findings. Set it to true if you are starting out and need visibility before enforcement. Starting with true and switching to false after two weeks is a reasonable path.

checkov ships with over 1,000 checks out of the box. Most of them are relevant to AWS. You will get findings on the first run, some of which you will decide to suppress. That is normal. Add a .checkov.yaml file to suppress findings that do not apply to your environment:

skip-check:
  - CKV_AWS_18  # S3 access logging — not required for internal buckets
  - CKV_AWS_144 # S3 cross-region replication — single-region setup

Document why you suppressed each check. Future you will not remember.

Control 3: Image Scanning with ECR Enhanced Scanning

If you push container images to ECR, Enhanced Scanning is already available. It is powered by Amazon Inspector and scans every image you push for CVEs across OS packages and application dependencies.

Enable it at the registry level. This applies to all repositories in your account:

aws ecr put-registry-scanning-configuration \
  --scan-type ENHANCED \
  --rules '[{"repositoryFilters": [{"filter": "*", "filterType": "WILDCARD"}], "scanFrequency": "SCAN_ON_PUSH"}]' \
  --region us-east-1

This enables scanning for all repositories in the registry. Every image push triggers a scan automatically.

To check findings after a push in your pipeline:

  image-scan:
    name: ECR Image Scan Check
    runs-on: ubuntu-latest
    needs: build-and-push
    steps:
      - name: Wait for scan to complete
        run: |
          for i in $(seq 1 12); do
            STATUS=$(aws ecr describe-image-scan-findings \
              --repository-name ${{ env.ECR_REPO }} \
              --image-id imageTag=${{ env.IMAGE_TAG }} \
              --query 'imageScanStatus.status' \
              --output text)
            echo "Scan status: $STATUS"
            if [ "$STATUS" = "COMPLETE" ]; then break; fi
            sleep 10
          done
        env:
          AWS_REGION: us-east-1

      - name: Check for critical findings
        run: |
          CRITICAL=$(aws ecr describe-image-scan-findings \
            --repository-name ${{ env.ECR_REPO }} \
            --image-id imageTag=${{ env.IMAGE_TAG }} \
            --query 'imageScanFindings.findingSeverityCounts.CRITICAL' \
            --output text)

          if [ "\(CRITICAL" != "None" ] && [ "\)CRITICAL" -gt 0 ]; then
            echo "Found $CRITICAL CRITICAL vulnerabilities. Blocking deploy."
            exit 1
          fi
          echo "No critical vulnerabilities found."
        env:
          AWS_REGION: us-east-1

ECR Enhanced Scanning is asynchronous. The poll loop checks every 10 seconds for up to 2 minutes. For most images that is enough. The original sleep 30 approach works but can fail silently if the scan is not done yet, reading stale or empty results.

One honest note: Enhanced Scanning adds cost. Amazon Inspector charges per image scanned. For most teams, the cost is low. Check the Inspector pricing page for your region before enabling it on a registry with hundreds of images pushed per day.

What to Watch After You Add These

The metric that matters is not the pipeline pass rate. It is the number of findings caught per month, and whether developers start fixing them before pushing.

The first two weeks will generate noise. Developers will see the failures, some will fix them, some will ask how to suppress them. That is the point. The conversation about why a check is flagging is more valuable than the check itself.

After a month, look at what checkov is consistently flagging. If the same check fails repeatedly in different repositories, that is a configuration pattern problem, not a developer problem. Fix it at the Terraform module level so it cannot be written wrong in the first place.

What These Controls Do Not Catch

Secret scanning catches patterns. It does not catch secrets stored in environment variables, SSM Parameter Store, or passed at runtime. Those need a different approach.

checkov catches known misconfigurations. It does not catch logic errors. An IAM policy that follows all the syntax rules but grants more than intended will pass checkov. Reviewing permission boundaries and trust policies still requires human judgment.

ECR scanning catches CVEs in known packages. It does not catch vulnerabilities in your application code. SAST tools cover that layer.

These three controls raise the floor. They do not raise the ceiling. A team that adds them today will block a category of incidents that currently reach production. That is the goal, not a perfect pipeline.

The previous article covered incident response for a compromised AWS access key. Secret scanning in the pipeline is the control that prevents that incident from happening in the first place.