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.