DEV Community

Cover image for DevSecOps Pipeline in a Day: Automated Security from Commit to Deploy
varun varde
varun varde

Posted on

DevSecOps Pipeline in a Day: Automated Security from Commit to Deploy

#webdev #ai #devops #devsecops

Security that happens after deployment is already too late.

By the time a quarterly penetration test discovers hardcoded secrets, vulnerable containers, or publicly exposed infrastructure, the vulnerable code has usually been in production for months. Sometimes years. The remediation backlog grows. Developers lose context. Security becomes bureaucratic archaeology rather than operational engineering.

DevSecOps changes the timing.

Instead of treating security as a gate at the end of delivery, it embeds security checks throughout the software lifecycle.

Commit → Build → Test → Scan → Deploy → Monitor
Enter fullscreen mode Exit fullscreen mode

Every stage becomes an opportunity to reduce risk automatically.

This tutorial builds a complete open-source DevSecOps pipeline in a single day:

  • Secret detection before commits
  • SAST on every pull request
  • Dependency vulnerability scanning
  • Container image scanning
  • Terraform and Kubernetes IaC scanning
  • DAST against staging environments
  • Centralised vulnerability reporting
  • Security SLA policies

No enterprise security platform required.

The DevSecOps Security Layer Model Where Each Check Lives

Security works best when distributed.

Not centralised.

Each security control belongs at the earliest operational layer where it can execute effectively.

The Six-Layer Model 

Layer 1 → Developer workstation
Layer 2 → Pull request pipeline
Layer 3 → Dependency validation
Layer 4 → Container security
Layer 5 → Infrastructure-as-Code validation
Layer 6 → Runtime application testing
Enter fullscreen mode Exit fullscreen mode

Every layer catches different failure modes.

Why Layering Matters

No single scanner catches everything.

Example

Security becomes resilient through redundancy.

Layer 1: Pre-Commit Hooks — detect-secrets and git-secrets Setup

The cheapest vulnerability to fix is the one that never enters Git history.

Installing Pre-Commit Framework

pip install pre-commit
Enter fullscreen mode Exit fullscreen mode

detect-secrets Configuration

repos:
- repo: https://github.com/Yelp/detect-secrets
  rev: v1.4.0
  hooks:
  - id: detect-secrets
Enter fullscreen mode Exit fullscreen mode

Install hooks

pre-commit install
Enter fullscreen mode Exit fullscreen mode

git-secrets for AWS Credentials

git secrets --install
git secrets --register-aws
Enter fullscreen mode Exit fullscreen mode

Example Detection

AWS_SECRET_ACCESS_KEY detected
Commit rejected
Enter fullscreen mode Exit fullscreen mode

This prevents catastrophic credential leakage before CI even starts.

Why Pre-Commit Security Matters

Secrets committed once often persist forever in Git history.

Even after deletion.

Prevention beats remediation.

Always.

Layer 2: SAST in CI — Semgrep for Application Code

Static Application Security Testing identifies insecure coding patterns before deployment.

Semgrep is exceptionally effective because it balances signal quality with developer usability.

GitHub Actions SAST Workflow

sast:
  runs-on: ubuntu-latest
  steps:
  - uses: actions/checkout@v4

  - name: Semgrep SAST
    uses: returntocorp/semgrep-action@v1
    with:
      config: "p/owasp-top-ten p/python p/javascript"
Enter fullscreen mode Exit fullscreen mode

Example Vulnerability Detection

query = f"SELECT * FROM users WHERE id = {user_input}"
Enter fullscreen mode Exit fullscreen mode

Semgrep flags

Possible SQL injection vulnerability
Enter fullscreen mode Exit fullscreen mode

Custom Security Rules

Production environments eventually require organisation-specific rules.

Example

rules:
- id: no-public-s3
  pattern: '"public-read"'
  message: Public S3 ACL forbidden
  severity: ERROR
Enter fullscreen mode Exit fullscreen mode

Why SAST Must Run on Every PR

Security reviews delayed until release branches create vulnerability bottlenecks.

Fast feedback changes behaviour.

Delayed feedback creates resentment.

Layer 3: SCA — OWASP Dependency-Check and Trivy for Dependencies

Modern applications inherit more code than they write.

Dependency vulnerabilities therefore matter enormously.

OWASP Dependency-Check

dependency-check.sh \
  --project app \
  --scan .
Enter fullscreen mode Exit fullscreen mode

Trivy Dependency Scan

trivy fs .
Enter fullscreen mode Exit fullscreen mode

Example Output

Critical vulnerability:
log4j-core 2.14.1
CVE-2021-44228
Enter fullscreen mode Exit fullscreen mode

Dependency Update Automation

Use Renovate or Dependabot

version: 2
updates:
- package-ecosystem: npm
  schedule:
    interval: daily
Enter fullscreen mode Exit fullscreen mode

Automation reduces vulnerability half-life dramatically.

Layer 4: Container Image Scanning — Trivy in Your Docker Build Pipeline

Containers frequently contain:

  • Vulnerable OS packages
  • Unpatched libraries
  • Misconfigurations
  • Embedded secrets

Scanning them is mandatory.

Build and Scan Workflow

container-scan:
  runs-on: ubuntu-latest

  steps:
  - uses: actions/checkout@v4

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

  - name: Trivy vulnerability scan
    uses: aquasecurity/trivy-action@master
    with:
      image-ref: app:${{ github.sha }}
      exit-code: '1'
      severity: 'CRITICAL,HIGH'
Enter fullscreen mode Exit fullscreen mode

Example Container Findings

openssl package vulnerable
Severity: HIGH
Enter fullscreen mode Exit fullscreen mode

Distroless Images Reduce Attack Surface

Instead of

FROM ubuntu:22.04
Enter fullscreen mode Exit fullscreen mode

Use

FROM gcr.io/distroless/static
Enter fullscreen mode Exit fullscreen mode

Smaller images. Fewer packages. Fewer CVEs.

Layer 5: IaC Security Scanning — Checkov on Every Terraform Plan

Infrastructure misconfigurations cause some of the most damaging cloud breaches.

IaC scanning catches them before deployment.

Checkov GitHub Action

iac-scan:
  runs-on: ubuntu-latest

  steps:
  - uses: actions/checkout@v4

  - name: Checkov IaC scan
    uses: bridgecrewio/checkov-action@master
    with:
      directory: terraform/
      framework: terraform
Enter fullscreen mode Exit fullscreen mode

Example Terraform Misconfiguration

resource "aws_security_group" "bad" {
  ingress {
    cidr_blocks = ["0.0.0.0/0"]
  }
}
Enter fullscreen mode Exit fullscreen mode

Checkov flags

Security group allows unrestricted ingress
Enter fullscreen mode Exit fullscreen mode

Recommended IaC Policies

Block:

  • Public S3 buckets
  • Open security groups
  • Unencrypted databases
  • Unencrypted EBS volumes
  • Wildcard IAM policies

Layer 6: DAST — OWASP ZAP Against Your Staging Environment

DAST validates runtime behaviour.

Unlike SAST, it tests deployed applications directly.

OWASP ZAP Docker Scan

docker run -t owasp/zap2docker-stable \
  zap-baseline.py \
  -t https://staging.example.com
Enter fullscreen mode Exit fullscreen mode

CI Integration Example

- name: ZAP Scan
  run: |
    docker run -t owasp/zap2docker-stable \
      zap-baseline.py \
      -t https://staging.example.com
Enter fullscreen mode Exit fullscreen mode

Vulnerabilities DAST Finds Well

  • XSS
  • Missing headers
  • Insecure cookies
  • Open redirects
  • Authentication weaknesses

Why DAST Complements SAST

SAST sees code.

DAST sees behaviour.

You need both.

Centralising Findings in Defect Dojo

Without centralisation, findings scatter across tools and become operational noise.

Defect Dojo consolidates:

  • SAST results
  • Dependency scans
  • Container findings
  • DAST reports Defect Dojo Deployment 
helm install defectdojo defectdojo/defectdojo
Enter fullscreen mode Exit fullscreen mode

Importing Scan Results

curl -X POST https://dojo/api/v2/import-scan/
Enter fullscreen mode Exit fullscreen mode

Why Centralisation Matters

Security programmes fail when visibility fragments.

One dashboard changes operational behaviour.

SLA Policies: How to Treat CRITICAL vs HIGH vs MEDIUM Findings

Not all vulnerabilities deserve identical urgency.

Recommended SLA Model

CI Enforcement Strategy

CRITICAL → Block merge
HIGH → Fail release
MEDIUM → Warn only
Enter fullscreen mode Exit fullscreen mode

Security governance must remain operationally realistic.

Overly aggressive policies create bypass behaviour.

Measuring DevSecOps Effectiveness Mean Time to Remediation

Security programmes require measurable outcomes.

Core Metrics
Mean Time to Remediation (MTTR)

Discovery → Remediation
Enter fullscreen mode Exit fullscreen mode

Shorter is better.

Vulnerability Escape Rate

How many vulnerabilities reach production?

False Positive Rate

If scanners create excessive noise

Developers stop trusting alerts
Enter fullscreen mode Exit fullscreen mode

Signal quality matters enormously.

Coverage Metrics

Track:

  • Repositories scanned
  • Terraform coverage
  • Container coverage
  • Dependency scan adoption

Full GitHub Actions DevSecOps Workflow 

name: DevSecOps Pipeline

on: [push, pull_request]

jobs:

  secrets-scan:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4

    - name: TruffleHog
      uses: trufflesecurity/trufflehog@main

  sast:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4

    - name: Semgrep
      uses: returntocorp/semgrep-action@v1

  dependency-scan:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4

    - name: Trivy FS Scan
      run: trivy fs .

  container-scan:
    runs-on: ubuntu-latest
    steps:
    - run: docker build -t app:${{ github.sha }} .

    - name: Trivy Image Scan
      run: trivy image app:${{ github.sha }}

  iac-scan:
    runs-on: ubuntu-latest
    steps:
    - name: Checkov
      uses: bridgecrewio/checkov-action@master

  dast:
    runs-on: ubuntu-latest
    steps:
    - name: OWASP ZAP
      run: |
        docker run -t owasp/zap2docker-stable \
        zap-baseline.py \
        -t https://staging.example.com
Enter fullscreen mode Exit fullscreen mode

Common DevSecOps Mistakes

1. Blocking Everything Immediately

Teams bypass pipelines if friction becomes unbearable.

Adopt incrementally.

2. Ignoring False Positives

Poor signal quality destroys developer trust.

3. Treating Security as Separate from Engineering

Security tooling must integrate into existing workflows.

Not create parallel ones.

4. No Ownership Model

Findings without owners become backlog sediment.

DevSecOps is not about inserting security gates into delivery pipelines.

It is about making security part of normal engineering behaviour.

The most successful DevSecOps environments share several characteristics:

  • Fast feedback
  • Automated enforcement
  • Low-friction tooling
  • Developer-visible results
  • Incremental adoption

Security stops being ceremonial compliance theatre and becomes operational engineering.

And that is the critical shift.

Because modern software delivery moves too quickly for security reviews performed weeks after deployment.

The only scalable model is continuous security at continuous delivery speed.

Top comments (0)