DevSecOps in CI/CD

“AKA. The Commit That Took Down...

By: Aayush Pokharel

AWS Student Community Day – Dec 27, 2025

Who’s Telling This Story?

  • Aayush Pokharel
  • Lead DevOps Engineer
  • STARTsmall Pvt. Ltd.

It Started With a ‘Harmless’ Commit…

Friday. 4:47 PM. One Change.

“I’ll just push this quickly.
UNO is more Important!"

What Was That Commit About?

I don't remember.

What Was In That Commit?

What Was In That Commit?

A .env file

The Pipeline Didn’t Fail

It Did Exactly What We Built

What Happened Next!

  • I played UNO
  • Bots played with my Credentials

UNO Reverse

  • Credentials abused
  • Compute spun up
  • Boss calls on Saturday Evening!

AWS bill exploded

💸💸💸

Why Traditional CI/CD Failed Us

  • Security at the very end
  • Feedback after merge
  • Vulnerabilities reach production

So I Changed the Question

“How do I stop bad code
BEFORE it becomes a problem?”

DevSecOps

Security Becomes Part of the Story
  • Security from day zero
  • Automated checks
  • Fast feedback
  • Defense in depth

What I Wanted to Achieve

  • Stop secrets from leaking
  • Catch vulnerabilities early
  • Automate security decisions
  • Build trusted container images
  • Push only verified artifacts

The New Pipeline

(Bird’s Eye View)

Developer

Local Security Checks

Git Repository

CI + Security

Image Verification

Production

Rule #1: Catch Mistakes Where They’re Cheapest

On the developer’s machine!

Why Start on the Developer Laptop?

  • Instant feedback
  • No cloud cost
  • Stops bad commits early

Git Hooks

Your First Line of Defense
  • Run before commit
  • Block mistakes automatically
  • Enforce rules consistently

What We Check Before Code Leaves the Laptop

Category Why It Matters
Secrets Prevent leaks
Linting Code quality
Dependencies Known CVEs
IaC Cloud misconfig
Commits Clean history

Tools That Make This Possible

  • gitleaks – secret detection
  • pre-commit – hook framework
  • eslint / flake8 – linting
  • checkov / tfsec – IaC scanning

But Let’s Be Honest…

✅ Fast
✅ Effective

❌ Can be bypassed
❌ Not enforceable

That’s Why We Layer Security

Defense in Depth

Assume the Worst Case

  • Hooks bypassed
  • External contributor
  • Legacy code

The Repository Becomes a Gatekeeper

  • Branch protection
  • Required CI checks
  • Dependency alerts
  • Mandatory reviews

Continuous Integration

Where Security Becomes Non-Negotiable

Why I Chose AWS CodeBuild

  • Fully managed
  • Pay per minute
  • IAM-native
  • ECR integration

The CI Pipeline Stages

Install Tools

Lint + SAST

Dependency Scan

Build Image

Image Scan

Push (Iff Safe)

CI Phases in Practice

install:
  - install security tools

pre_build:
  - lint
  - SAST
  - dependency scan

build:
  - docker build

post_build:
  - image scan
  - push

Static Analysis

Catch Bugs Before They Run

  • Finds insecure patterns
  • No runtime needed

Dependency Scanning

Bugs You Didn’t Write

  • CVE-based detection
  • Transitive dependencies

Containers Change the Game

Your app is only as secure as its image

Secure Image Fundamentals

  • Minimal base images
  • Multi-stage builds
  • Non-root user
  • No secrets inside

Why We Scan Images Before Pushing

❌ Bad images spread fast
✅ Early scan stops bad artifacts
✅ Registry stays trusted

Our Trusted Image Warehouse: ECR

  • IAM access control
  • Image scanning
  • Lifecycle rules
  • AWS-native

The Full Journey of a Secure Commit

  1. Developer commits
  2. Hooks block secrets
  3. CI enforces security
  4. Image is built
  5. Image is scanned
  6. Only clean images are pushed

Tools Are Replaceable

Principles Are NOT!

Layer Option A Option B
CI CodeBuild GitHub Actions
Secrets Git Hooks CI-only
Image Scan Trivy Snyk
Registry ECR Harbour

Choosing the Right Approach

  • Git hooks → Small teams, learning
  • CI-only → OSS projects
  • CodeBuild → AWS-native
  • GitHub Actions → GitHub-first

What I Want You to Remember

  • DevSecOps is about placement
  • Shift security left
  • Automate decisions
  • Fail early, fail cheap

Thank You!

Questions?

linkedin.com/in/AayushPokharel

UNO?

Come Find ME!

Pause. Smile. Set expectations. “This is not a tool talk. This is a story about a mistake… and how we fixed it.”

“I’m not here as someone who never broke prod. I’m here as someone who learned the hard way.”

Create suspense. Friday evening. Small change. No one thinks about security.

Slow down. Make it cinematic. Everyone has done this.

Pause here. Let people react. This is the hook.

Pause here. Let people react. This is the hook.

Important mindset shift. This was not human error. This was design failure.

Ask audience: “How long do you think this took?” Answer: seconds.

“This pipeline was fast… at delivering risk.”

This is where DevSecOps enters.

DevSecOps is not a team. It’s placement of responsibility.

“These goals came directly from the incident.”

“We didn’t add one tool. We added multiple safety nets.”

Ask audience: “Where is the cheapest place to fail?”

“One blocked commit saved us thousands of dollars.”

“This feels like magic when you demo it.”

“No cloud. No permissions. Just discipline.”

“These tools are boring. That’s why they work.”

“If security depends on humans being perfect, it will fail.”

Seatbelts + airbags analogy.

CI must assume zero trust.

“Security is now enforced, not suggested.”

Transition to CI. This is the enforcer layer.

Not saying it’s the best. It was the best *for us*.

“Every stage asks: Is it safe to continue?”

Short explanation. No deep YAML dive.

“SQL injection caught before deploy.”

Tools: - Trivy - OWASP Dependency-Check - Snyk

“Our biggest vuln once came from a library.”

Transition to containers.

“These are boring best practices. Please follow them.”

“Would you store spoiled food in a clean fridge?”

“Nothing enters without inspection.”

Reinforce automation. No manual approvals.

Avoid tool wars.

Context matters more than tools.

Slow down. This is the takeaway slide.

End strong. “Don’t add security later. You’ll forget. Put it where it can’t be ignored.”