By IT Defined Team | April 10, 2026

Build a real DevSecOps pipeline on AWS with shift-left security — SAST, container scanning, IaC scanning, runtime security, and central aggregation in Security Hub.

Why this pipeline matters in 2026

Two things have changed about security in DevOps over the last few years. First, attackers have gotten very good at supply-chain attacks — compromised npm packages, malicious Docker images, leaked credentials. Second, AI agents are now doing things in your AWS account, which means your old security boundary ("a human reviews every change") is breaking down.

The response is shift-left security. Catch issues early, automate detection, integrate with the developer workflow instead of being a roadblock at the end. This post walks through what a working DevSecOps pipeline looks like in 2026.

Architecture overview

What we're building, in flow order:

• Pre-commit: secret scanning
• PR opened: SAST scan, dependency scan (SCA), IaC scan
• Build: container image scan
• Pre-deploy: policy-as-code check
• Runtime: Falco for behavioral monitoring
• Aggregate: AWS Security Hub centralizes findings
• Respond: EventBridge → Lambda for automated remediation of low-risk issues, Slack alerts for human review of higher-risk

Each layer catches different things. Together they're hard to bypass.

Layer 1: Pre-commit secret scanning

The most common security incident I see at companies under 50 engineers: someone commits an AWS access key. Catch it before it leaves the developer's machine.

Use gitleaks or trufflehog as a pre-commit hook:

# .pre-commit-config.yaml

repos:
- repo: https://github.com/gitleaks/gitleaks
rev: v8.21.0
hooks:
- id: gitleaks

Engineers run pre-commit install once. Now every commit gets scanned. If a key is detected, the commit is blocked.

This isn't enough on its own — engineers can bypass pre-commit hooks. But it catches the accidental case which is 80% of incidents.

Backstop: same scanner runs in CI on every push. If a key sneaks through, you catch it within minutes and rotate.

Layer 2: SAST in CI

Static Application Security Testing — scanning your code for vulnerabilities. Tools: Semgrep, SonarQube, GitHub CodeQL.

Semgrep is my preferred default — it's free for open source, has good rule packs, fast to run.

- name: Run Semgrep
uses: returntocorp/semgrep-action@v1
with:
config: >-

p/security-audit

p/owasp-top-ten

p/command-injection

Configure to fail the build on high-severity findings. Allow medium and low to flow through but be visible.

Be pragmatic about findings. SAST tools have false positives. Tune them, ignore obvious noise. The goal is real signal, not 1000 alerts everyone ignores.

Layer 3: Software Composition Analysis (SCA)

Most vulnerabilities aren't in code you wrote. They're in dependencies you pulled in. SCA scans your dependency tree.

Trivy works for container images and source repositories. For pure dependency scans:
- name: Trivy filesystem scan
uses: aquasecurity/trivy-action@master
with:
scan-type: 'fs'
severity: 'CRITICAL,HIGH'
exit-code: '1'
ignore-unfixed: true

ignore-unfixed is important. There's no point failing the build for vulnerabilities that have no available fix — you can't do anything about them. Track them separately, monitor for fixes, but don't block deploys.

Snyk is the commercial alternative. Better UI, more rules, costs money.

Layer 4: IaC scanning with Checkov

Most cloud breaches are misconfigurations, not exploits. Public S3 bucket. Security group open to 0.0.0.0/0. RDS without encryption. IaC scanning catches these before deploy.

Checkov is the standard tool — works on Terraform, CloudFormation, Kubernetes manifests, Docker:

- name: Checkov
uses: bridgecrewio/checkov-action@master
with:
directory: terraform/
framework: terraform
soft_fail: false

tfsec is an alternative, more focused on Terraform. Both work. Pick one.

Common findings: missing encryption, public access enabled, no logging, weak password policies, unrestricted security groups. Most are obvious in hindsight.

Layer 5: Container image scanning

Scan the image after build, before push to ECR:

- name: Build image
run: docker build -t myapp:${{ github.sha }} .

- name: Scan with Trivy
uses: aquasecurity/trivy-action@master
with:
image-ref: myapp:${{ github.sha }}
severity: 'CRITICAL,HIGH'
exit-code: '1'
ignore-unfixed: true

- name: Push to ECR if scan passes
run: docker push myapp:${{ github.sha }}

ECR also has built-in image scanning powered by Inspector. Enable it for defense in depth, but you don't want to wait for ECR scan to fail builds — Trivy in CI is faster.

Use minimal base images. Distroless or alpine. Fewer packages = fewer vulnerabilities. Most CRITICAL findings I see are from outdated bash or openssl in the base image, not the application code.

Layer 6: Policy-as-code with OPA

Some checks are organization-specific. "All resources must have an Owner tag." "No EC2 instances above m5.large without VP approval." "All S3 buckets must have versioning enabled."

These don't fit pre-built rule packs. Write them as policies in Rego, evaluated by Open Policy Agent.

Use conftest to evaluate policies against Terraform plans:

- name: Generate plan
run: terraform plan -out=plan.tfplan && terraform show -json plan.tfplan > plan.json

- name: Conftest
run: conftest test plan.json --policy policies/

An example policy:

package terraform

deny[msg] {
resource := input.resource_changes[_]
resource.type == "aws_s3_bucket"
not resource.change.after.tags.Owner
msg := sprintf("S3 bucket %s missing Owner tag", [resource.address])
}

Now every Terraform change is checked against your org's standards. Caught at PR time, not after deploy.

Layer 7: Runtime security with Falco

Static checks miss things. Falco watches running containers and detects anomalous behavior — shell spawning in production pods, unexpected outbound connections, privilege escalation attempts.

Install on EKS:

helm repo add falcosecurity https://falcosecurity.github.io/charts
helm install falco falcosecurity/falco \
--namespace falco --create-namespace \
--set falcosidekick.enabled=true \
--set falcosidekick.config.slack.webhookurl=YOUR_SLACK_WEBHOOK

Falco ships with a good default ruleset. Tune it — every environment has legitimate weird behavior that triggers default rules. Tuning takes a few weeks but is worth it.

Layer 8: AWS Security Hub aggregation

All these tools generate findings. Security Hub centralizes them — Trivy findings, Inspector findings, GuardDuty findings, your own Lambda-based custom findings, all in one console.

Enable Security Hub in your account. Enable the standards you care about (CIS AWS Foundations, AWS Foundational Security Best Practices). Integrate Trivy via the Security Hub integration.

From Security Hub, EventBridge rules trigger Lambdas for automated response:

• Public S3 bucket detected → automatically remove public access ACL, notify owner
• Wide-open security group detected → revoke 0.0.0.0/0 ingress, notify owner
• Critical vulnerability in production image → trigger redeploy with latest patched image

Caution: automated remediation is great for low-risk fixes, dangerous for high-risk ones. Don't have a Lambda automatically delete "suspicious" resources. The remediation can cause more damage than the issue.

Compliance as code

If you're in a regulated environment (fintech, healthcare in India, anything serving EU/US), compliance becomes part of the pipeline.

AWS Config rules automate continuous compliance checks. Combine with conformance packs (pre-built sets of rules) for SOC 2, PCI, HIPAA. Findings flow to Security Hub.

Audit Manager generates evidence reports automatically. Auditors get reports from real-time data instead of manual screenshots.

This is the pattern that makes audits less painful. The work is upfront, the payoff is when audits go smoothly because evidence is auto-collected.

Common mistakes

Failing builds for low-severity findings. Fatigue sets in, people start ignoring all alerts. Tune severity thresholds carefully.

Not exempting unfixable vulnerabilities. Track them, but don't block on them. Engineers will start commenting out the scanner.

Treating security as a separate team. Security in DevOps means embedding security in the dev workflow, not having a security team that reviews after the fact.

Forgetting about secrets in CI. Pre-commit hooks help. CI-side scans help. But the most common leak is a developer pasting credentials in a Slack message — train people.

Assuming compliance equals security. They overlap, they're not the same. SOC 2 doesn't make you secure. Don't conflate the two.

What we teach across DevOps and Cybersecurity

At IT Defined we run DevOps and Cybersecurity as separate programs, but DevSecOps sits at the intersection. Students from both programs work through this pipeline as a capstone project — DevOps students focus on the integration, Cybersecurity students focus on rule tuning and incident response.

If you want guided practice on building a real DevSecOps pipeline like this, with hands-on labs in our cloud-based SOC environment, both our AWS DevOps and Cybersecurity programs cover it from different angles.

Frequently asked questions

What's the difference between SAST and SCA?

SAST scans your code. SCA scans your dependencies. Both are needed.

Is Snyk worth paying for over Trivy?

For small teams, Trivy is plenty. For larger orgs, Snyk's UI and license tracking are nice. Not strictly necessary.

How do I deal with vulnerability fatigue?

Track findings as backlog items. Triage weekly. Allocate 10-20% of engineering capacity to security debt. Otherwise it accumulates forever.

What about AWS Inspector?

Use it. Inspector continuously scans EC2 and ECR images. Findings flow to Security Hub. It's a useful complement to Trivy in CI, not a replacement.

About IT Defined

IT Defined is a software training institute in Whitefield, Bangalore, offering hands-on programs in AWS DevOps, Full-Stack MERN, Python, and Cybersecurity. We've trained over 2,000 students with live projects, mock interviews, and placement support.

Visit: itdefined.org  |  Phone: +91 6363730986  |  Email: info@itdefined.org