Search for a command to run...
gitleaks, checkov, and ECR Enhanced Scanning. What they catch and how to add them.
No comments yet. Be the first to comment.
What it actually does, what it costs, and whether it's worth setting up for your repos
A practical playbook when AWS documentation isn't enough
You already run the services. This is how you wire them.
Practical examples and what Control Tower quietly leaves uncovered
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.
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.
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.
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.
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.
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.
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.