DevSecOps Implementation Guide

Executive Summary

Software development moves fast. Security has historically lagged behind — applied at the end of the development process as an audit function, producing findings that either block releases or are accepted as tolerable risk. This approach is expensive: fixing a security defect post-production costs 6–100x more than fixing it during design.

DevSecOps integrates security practices into every phase of the software development lifecycle (SDLC). The goal is not to slow development — it is to make security the path of least resistance by embedding it into the tools and workflows developers already use.

This guide provides a practical implementation roadmap for engineering teams and security professionals building a DevSecOps capability. It covers tooling, process, and culture — because technical controls without cultural buy-in fail.

Chapter 1: Shifting Security Left

The Security Debt Problem

Traditional security is applied late: penetration testing before go-live, vulnerability scans in production. This approach creates security debt — a backlog of vulnerabilities in production code that grows faster than it is remediated.

Cost of fixing defects by phase (IBM Systems Sciences Institute):

Shifting security left moves vulnerability discovery earlier — when it is cheaper and faster to fix.

What DevSecOps Adds to Each Phase

Business Case for DevSecOps

• Speed: Security issues caught in development don’t delay releases
• Cost: Fewer expensive post-production fixes
• Quality: Security defects treated like any other defect — caught in the development workflow
• Compliance: Continuous security evidence for audits (PCI DSS, ISO 27001, SOC 2)
• Culture: Security becomes a shared responsibility, not a security team gatekeeping function

Chapter 2: Security Requirements and Threat Modelling

Security Requirements as User Stories

Security should enter the development process at the requirements phase. Write security requirements as user stories:

As a security engineer,
I want all API endpoints to require authentication,
So that unauthenticated users cannot access protected resources.

Acceptance Criteria:
- Endpoints return 401 for unauthenticated requests
- JWT tokens are validated with correct algorithm
- Token expiry is enforced
- Expired tokens return 401, not redirect to login page

Security requirements belong in the same backlog as functional requirements. They should be estimated, prioritised, and tracked.

Threat Modelling

Threat modelling answers: “What could go wrong with this feature, and how do we prevent it?”

When to threat model:

• New features with security implications (authentication, payment, data access)
• Architectural changes
• Integration with third-party systems
• Significant changes to data flow or storage

STRIDE Framework:

Threat modelling process (simplified):

1. Draw a data flow diagram: actors, processes, data stores, external entities, trust boundaries
2. Enumerate threats using STRIDE for each component
3. Rate each threat (likelihood × impact)
4. Define mitigations for high-rated threats
5. Create implementation tickets for each mitigation

Tools: OWASP Threat Dragon (free), Microsoft Threat Modeling Tool (free), Miro/draw.io (manual).

Chapter 3: SAST — Static Application Security Testing

What SAST Does

SAST analyses source code (or compiled bytecode) without executing it, looking for patterns associated with security vulnerabilities: SQL queries built with string concatenation, unsanitised output written to HTML, use of deprecated cryptographic functions.

SAST Limitations

• False positives: SAST tools produce many false positives, especially in complex codebases. Developers who see too many false positives learn to ignore the tool.
• Business logic: SAST cannot detect logical vulnerabilities (incorrect authorisation logic, insecure direct object references)
• Runtime context: SAST doesn’t know what data reaches each function at runtime

SAST Tool Selection

Recommendation: Start with a free, language-specific tool (Bandit, gosec, Brakeman) in CI/CD before investing in commercial SAST. Commercial tools (Checkmarx, Veracode, Snyk Code) offer better accuracy and dashboards but cost $10,000–$100,000+/year.

CI/CD Integration

# Example: GitHub Actions with Semgrep
name: SAST

on: [push, pull_request]

jobs:
  semgrep:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: returntocorp/semgrep-action@v1
        with:
          config: >-
            p/owasp-top-ten
            p/python
          publishToken: ${{ secrets.SEMGREP_APP_TOKEN }}

Gating policy: Define which finding severities block the build:

• Block: Critical findings (never merge code with critical SAST findings)
• Warning: High findings (display in PR, require acknowledgment)
• Informational: Medium/Low (logged, not blocking)

Chapter 4: SCA — Software Composition Analysis

Why SCA Is Critical

Modern applications are 80–90% third-party code (libraries, frameworks, packages). Vulnerabilities in dependencies are just as dangerous as vulnerabilities in your own code — and often easier for attackers to exploit because CVEs are publicly documented.

Log4Shell (CVE-2021-44228) is the canonical example: a single vulnerable library dependency in thousands of applications; exploitable with a single log message.

SCA Tools

SCA in CI/CD

# Python example with pip-audit
- name: Run pip-audit
  run: |
    pip install pip-audit
    pip-audit --strict --output=json > pip-audit-results.json
  continue-on-error: false  # Fail on Critical

Dependency Management Policy

• Block: Dependencies with Critical CVEs (CVSS 9+) must be updated or removed before merge
• Review: High CVEs require security team acknowledgment if not immediately patchable
• Regular updates: Schedule weekly dependency update PRs (Dependabot automates this)
• Lock files: Always commit package-lock.json / Pipfile.lock / go.sum to prevent version drift

Chapter 5: Secrets Management

Hardcoded credentials in source code is one of the most common and impactful security failures. GitGuardian detected over 12 million secrets exposed in GitHub repositories in 2024.

Pre-Commit Secrets Detection

Install pre-commit hooks that scan for secrets before they are committed:

# Install pre-commit and gitleaks
pip install pre-commit
brew install gitleaks

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.16.0
    hooks:
      - id: gitleaks

Gitleaks detects: AWS access keys, GitHub tokens, private keys, API keys, database connection strings, JWT secrets, and hundreds of other patterns.

Repository Scanning

Enable GitHub Advanced Security secret scanning on all repositories. It scans all commits, including history, and automatically revokes detected credentials for supported services (GitHub tokens, AWS keys, Stripe keys, etc.).

For GitLab: Enable Secret Detection in CI/CD.

For self-hosted repositories: Run GitLeaks or TruffleHog in CI/CD on every push.

Secrets Management in Applications

Never store secrets in:

• Source code or configuration files
• Environment variables baked into Docker images
• Kubernetes ConfigMaps
• CI/CD pipeline environment variables (for highly sensitive secrets)

Approved storage locations:

Rotation: Secrets should be rotatable without downtime. Design applications to support multiple valid secret versions during rotation.

Chapter 6: DAST — Dynamic Application Security Testing

What DAST Does

DAST tests running applications by sending malicious inputs and observing responses. Unlike SAST, DAST sees the application as an attacker does — from the outside, with no code access.

DAST catches vulnerabilities that SAST misses (runtime behaviour, configuration issues) and vice versa. Both are needed.

DAST Tools

DAST in CI/CD

# GitHub Actions with OWASP ZAP
- name: ZAP Baseline Scan
  uses: zaproxy/action-baseline@v0.9.0
  with:
    target: 'https://staging.myapp.com'
    rules_file_name: '.zap/rules.tsv'
    cmd_options: '-a'

Staging environment requirement: DAST must run against a staging environment that mirrors production — never directly against production (it may create data, trigger alerts, or cause issues).

Chapter 7: Container and Infrastructure Security

Container Image Security

Every container image should be scanned before deployment:

# Trivy in CI/CD
- name: Scan Docker image
  uses: aquasecurity/trivy-action@master
  with:
    image-ref: '${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:${{ github.sha }}'
    format: 'sarif'
    exit-code: '1'
    ignore-unfixed: true
    severity: 'CRITICAL,HIGH'
    output: 'trivy-results.sarif'

- name: Upload Trivy scan results to GitHub Security
  uses: github/codeql-action/upload-sarif@v2
  with:
    sarif_file: 'trivy-results.sarif'

Container security baseline:

• Use minimal base images (Alpine, distroless) — fewer packages = smaller attack surface
• Run as non-root user inside the container
• No secrets in the image (use runtime secret injection)
• Enable Docker Content Trust (image signing) for production

Infrastructure as Code (IaC) Security

Terraform, CloudFormation, and Kubernetes manifests are code — they should be security-scanned:

# Run Checkov on Terraform
checkov -d ./terraform/ --framework terraform --output sarif > checkov-results.sarif

Chapter 8: Security Champions Programme

Technical controls are insufficient without cultural change. The Security Champions Programme creates security advocates within development teams.

Programme Structure

Who is a Security Champion? A developer (or DevOps engineer) who takes on security responsibilities alongside their normal role. Champions are not full-time security — typically 10–20% of their time.

Champion responsibilities:

• First point of contact for security questions within their team
• Participate in threat modelling for new features
• Review SAST/DAST findings and triage false positives
• Attend monthly security champion meetings
• Complete security training requirements (minimum: OWASP Top 10, secure coding for their language)

Programme requirements:

• Executive sponsorship and visible support
• Dedicated time (not purely voluntary — 10% of sprint capacity for security)
• Training budget and resources
• Recognition: security champion achievement should be part of performance review

Security Training for Developers

Chapter 9: Metrics and Maturity

DevSecOps Metrics

DevSecOps Maturity Model

Most organisations start at Level 0–1. Reaching Level 3 is the target for mature DevSecOps.

Implementation Roadmap

Month 1–2:

• Deploy SAST and SCA in CI/CD (start with critical repos)
• Deploy pre-commit secrets detection
• Enable GitHub Advanced Security secret scanning

Month 3–4:

• Extend SAST/SCA to all repositories
• Implement secrets management (migrate from config files to secrets manager)
• Run first threat modelling workshop

Month 5–6:

• Implement DAST in staging pipeline
• Launch Security Champions programme (identify champions, start training)
• Establish security metrics dashboard

Month 7–12:

• Container and IaC scanning
• Security requirements in backlog
• Regular security champion sync and training
• Quarterly security metrics review

Conclusion

DevSecOps is a journey, not a destination. The most effective implementations start small — pick one or two tools, integrate them into existing workflows, and build from there. The goal is to make security invisible to developers: automatic checks that catch issues, clear feedback on what to fix, and fast feedback loops that don’t slow down shipping.

CyberneticsPlus helps engineering teams implement DevSecOps — from tool selection and CI/CD pipeline integration to threat modelling training and security champions programme design. Contact us to start your DevSecOps journey.