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

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

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

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

detect-secrets Configuration

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

Install hooks

pre-commit install

git-secrets for AWS Credentials

git secrets --install
git secrets --register-aws

Example Detection

AWS_SECRET_ACCESS_KEY detected
Commit rejected

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"

Example Vulnerability Detection

query = f"SELECT * FROM users WHERE id = {user_input}"

Semgrep flags

Possible SQL injection vulnerability

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

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 .

Trivy Dependency Scan

trivy fs .

Example Output

Critical vulnerability:
log4j-core 2.14.1
CVE-2021-44228

Dependency Update Automation

Use Renovate or Dependabot

version: 2
updates:
- package-ecosystem: npm
  schedule:
    interval: daily

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'

Example Container Findings

openssl package vulnerable
Severity: HIGH

Distroless Images Reduce Attack Surface

Instead of

FROM ubuntu:22.04

Use

FROM gcr.io/distroless/static

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

Example Terraform Misconfiguration

resource "aws_security_group" "bad" {
  ingress {
    cidr_blocks = ["0.0.0.0/0"]
  }
}

Checkov flags

Security group allows unrestricted ingress

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

CI Integration Example

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

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

Importing Scan Results

curl -X POST https://dojo/api/v2/import-scan/

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

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

Shorter is better.

Vulnerability Escape Rate

How many vulnerabilities reach production?

False Positive Rate

If scanners create excessive noise

Developers stop trusting alerts

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

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.

推荐订阅源

DEV Community