DevOps Security

DevSecOps stands for Development, Security, and Operations. It integrates security practices directly into the DevOps process rather than treating security as a final checkpoint before release. The goal is to make security everyone's responsibility — baked into code, pipelines, and infrastructure from the very beginning.

The traditional model treats security as a gate at the end: developers build everything, then a security team reviews it before launch. This creates bottlenecks, late-stage surprises, and costly rework. DevSecOps shifts security left — to the earliest possible point in the development cycle.

Shift-Left Security

"Shift left" means moving security checks earlier in the pipeline — toward the left side of the development timeline. Fixing a vulnerability costs dramatically more the later it is found:

Stage Vulnerability FoundRelative Cost to Fix
During development (IDE)1x
During code review6x
During QA/testing15x
After production deployment100x

Security in Each Pipeline Stage

Stage 1: Code (IDE and Pre-commit)

Security starts before code even reaches the repository:

  • IDE plugins: Tools like Snyk IDE or SonarLint scan code in real time as developers type.
  • Pre-commit hooks: Git hooks that automatically scan code before allowing a commit.
  • Secret detection: Tools like detect-secrets or gitleaks catch accidentally committed API keys, passwords, or tokens before they reach Git history.
# Install gitleaks for secret scanning
# In .pre-commit-config.yaml:

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

Stage 2: Build – SAST (Static Application Security Testing)

SAST tools analyze source code without running it, looking for security weaknesses:

  • SonarQube: Scans code for vulnerabilities, code smells, and security hotspots.
  • Semgrep: Fast, lightweight static analysis for dozens of languages.
  • Bandit: Python-specific security linter.
  • ESLint security plugins: JavaScript/TypeScript security rules.

Stage 3: Dependencies – SCA (Software Composition Analysis)

Most modern applications use hundreds of open-source libraries. SCA tools check these dependencies for known vulnerabilities (CVEs):

  • Snyk: Scans npm, pip, Maven, and other package managers for vulnerable versions.
  • OWASP Dependency-Check: Open-source tool for identifying known vulnerabilities in dependencies.
  • Dependabot (GitHub): Automatically opens pull requests to update vulnerable dependencies.
# Example: GitHub Actions step for Snyk dependency scanning
- name: Run Snyk to check for vulnerabilities
  uses: snyk/actions/node@master
  env:
    SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
  with:
    args: --severity-threshold=high

Stage 4: Container Scanning

Docker images often contain OS packages with known vulnerabilities. Container scanning tools inspect every layer of a Docker image:

  • Trivy: Fast, comprehensive scanner for container images, file systems, and Git repos.
  • Clair: Open-source vulnerability scanner for containers.
  • AWS ECR scanning: Built-in scanning for images stored in ECR.
# Scan a Docker image with Trivy
trivy image myapp:1.0

# Fail CI if HIGH or CRITICAL vulnerabilities found
trivy image --exit-code 1 --severity HIGH,CRITICAL myapp:1.0

Stage 5: Infrastructure Security

Terraform and other IaC code can contain security misconfigurations. IaC scanning catches them before deployment:

  • Checkov: Scans Terraform, CloudFormation, Kubernetes YAML for security issues.
  • tfsec: Terraform-specific security scanner.
  • KICS: Scans infrastructure code across multiple IaC formats.
# Scan Terraform code with Checkov
checkov -d ./terraform/

# Common findings: S3 buckets with public access, security groups too permissive,
# encryption disabled, logging not enabled

Stage 6: DAST (Dynamic Application Security Testing)

DAST tools test a running application by simulating attacks from the outside:

  • OWASP ZAP (Zed Attack Proxy): Open-source web scanner that crawls and attacks a live application looking for SQL injection, XSS, and other OWASP Top 10 vulnerabilities.
  • Burp Suite: Industry-standard web security testing platform.

Secrets Management

Hardcoded secrets (passwords, API keys, database URLs) in source code are one of the most common and dangerous security mistakes. DevSecOps uses proper secrets management:

HashiCorp Vault

Vault stores, manages, and controls access to secrets. Applications request secrets at runtime — secrets are never stored in code or environment files.

# Store a secret in Vault
vault kv put secret/webapp db_password="s3cur3p@ss"

# Retrieve a secret
vault kv get secret/webapp

AWS Secrets Manager

AWS-native secret storage with automatic rotation. Applications retrieve secrets via API or IAM role — no credentials in code.

Environment-Based Secrets in CI/CD

# In GitHub Actions, secrets are stored in Settings > Secrets
# and injected at runtime:
- name: Deploy application
  env:
    DB_PASSWORD: ${{ secrets.DB_PASSWORD }}
    API_KEY: ${{ secrets.STRIPE_API_KEY }}
  run: ./deploy.sh

OWASP Top 10

The OWASP (Open Web Application Security Project) Top 10 is the standard reference for the most critical web application security risks. DevSecOps teams build checks for these into their pipelines:

  1. Broken Access Control
  2. Cryptographic Failures
  3. Injection (SQL, NoSQL, Command)
  4. Insecure Design
  5. Security Misconfiguration
  6. Vulnerable and Outdated Components
  7. Identification and Authentication Failures
  8. Software and Data Integrity Failures
  9. Security Logging and Monitoring Failures
  10. Server-Side Request Forgery (SSRF)

Network Security in DevOps

  • Least Privilege Network Rules: Security groups and firewall rules allow only necessary traffic.
  • Private Subnets: Databases and internal services never exposed to the public internet.
  • TLS Everywhere: All communication encrypted with HTTPS/TLS — internally and externally.
  • Network Policies in Kubernetes: Pod-to-pod communication restricted by policy.
  • Web Application Firewall (WAF): Filters malicious HTTP traffic before it reaches the application.

Compliance as Code

Regulatory compliance (PCI DSS, HIPAA, SOC 2) can be enforced programmatically. Tools like AWS Config, Open Policy Agent (OPA), and Falco define compliance rules as code and automatically detect violations in real time.

A Complete DevSecOps Pipeline

Developer commits code
        ↓
Pre-commit hooks: secret detection, linting
        ↓
CI Pipeline triggered:
  → SAST (SonarQube/Semgrep)
  → SCA (Snyk dependency scan)
  → Build Docker image
  → Container scan (Trivy)
  → IaC scan (Checkov on Terraform)
        ↓
Deploy to staging:
  → DAST (OWASP ZAP)
  → Integration tests
        ↓
Manual security review (for major releases)
        ↓
Deploy to production
        ↓
Runtime: WAF, CloudTrail, Falco, monitoring

Summary

  • DevSecOps integrates security into every stage of the DevOps pipeline.
  • Shift-left means catching vulnerabilities early — in code, not in production.
  • SAST, SCA, container scanning, IaC scanning, and DAST each protect a different layer.
  • Secrets management tools (Vault, AWS Secrets Manager) keep sensitive values out of code.
  • OWASP Top 10 provides the reference list of critical security risks to test against.
  • Security automation in CI/CD makes security continuous, fast, and consistent.

Leave a Comment