What is DevSecOps? Security Built Into the Pipeline

DevSecOps is the practice of integrating security checks directly into the software development and delivery pipeline, rather than treating security as a separate gate at the end of the process. The name reflects an extension of DevOps culture: just as DevOps merged development and operations workflows, DevSecOps pulls the security function into the same continuous delivery loop.

The core premise is that fixing a vulnerability in production costs vastly more -- in time, money, and risk -- than catching it during development. A secret accidentally committed to a Git repository is expensive to remediate. A critical CVE in a base image found after deployment requires emergency patching under pressure. Finding the same issues in a pull request CI check costs a developer 10 minutes. This is what "shift-left" means in practice.

DevSecOps is a natural extension of the CI/CD practices covered in GitHub Actions and Jenkins.

SAST and DAST

SAST (Static Application Security Testing) analyses source code without running it. Tools like Semgrep, SonarQube, and Checkov scan for insecure code patterns -- SQL injection vectors, hardcoded credentials, insecure random number generation, SSRF vulnerabilities. SAST runs fast and integrates cleanly into pull request checks.

DAST (Dynamic Application Security Testing) tests a running application by sending requests designed to trigger security failures. OWASP ZAP and Burp Suite are standard DAST tools. DAST is slower and requires a deployed environment to test against, so it typically runs in a staging CI stage rather than on every pull request.

Container Image Scanning with Trivy

Container images accumulate OS packages and language dependencies, each with their own CVE history. Trivy is an open-source scanner from Aqua Security that checks images against vulnerability databases. It is fast, accurate, and integrates directly into GitHub Actions.

Here is a production-ready Trivy scan step added to an existing GitHub Actions workflow:

# .github/workflows/security.yml
name: Security Scan

on:
  push:
    branches: [main]
  pull_request:

jobs:
  trivy-scan:
    name: Container Vulnerability Scan
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Build image for scanning
        run: docker build -t myapp:scan .

      - name: Run Trivy vulnerability scanner
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: 'myapp:scan'
          format: 'table'
          exit-code: '1'           # fail the build on HIGH/CRITICAL
          ignore-unfixed: true     # skip CVEs with no available fix
          vuln-type: 'os,library'
          severity: 'HIGH,CRITICAL'

      - name: Generate SBOM
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: 'myapp:scan'
          format: 'cyclonedx'
          output: 'sbom.cdx.json'

      - name: Upload SBOM artifact
        uses: actions/upload-artifact@v4
        with:
          name: sbom
          path: sbom.cdx.json

exit-code: '1' causes the workflow to fail when HIGH or CRITICAL vulnerabilities are found. ignore-unfixed: true avoids failing on CVEs where no fix exists yet -- a pragmatic choice that reduces noise without hiding exploitable vulnerabilities.

Secrets Scanning

Accidentally committing API keys, database passwords, or private certificates to a repository is one of the most common and serious security incidents in software engineering. Tools like git-secrets (AWS) and truffleHog scan commit history and staged changes for patterns matching known secret formats -- AWS access keys, GitHub tokens, private keys, and more.

GitHub's own Secret Scanning feature alerts repository owners when a recognised secret format is detected in a push. Snyk also covers secrets detection alongside dependency scanning.

The correct fix for a leaked secret is not to rewrite Git history -- it is to rotate the credential immediately and treat the old one as compromised, regardless of whether the commit was public or private.

Software Bill of Materials (SBOM)

An SBOM is a machine-readable inventory of every dependency in your software. The Trivy example above generates one in CycloneDX format. SBOMs are increasingly required in regulated industries and government procurement. Tools like Grype can consume an SBOM and run vulnerability scans against it separately from the image scan, enabling ongoing monitoring of dependencies even after deployment.

DevSecOps is a significant topic in the DevOps tools guide. Security awareness separates junior DevOps engineers from those trusted to own production infrastructure.

Frequently Asked Questions