DevSecOps Guide: Shift-Left Security, SAST/DAST, and CI/CD Pipeline Integration [2026]

The traditional security model — where developers write code, security reviews it weeks or months later, and operations deploys whatever passes — breaks at modern development velocity. Defects found in production cost 25x more to fix than defects found during development. Security teams reviewing code after the fact slow release cycles and still miss vulnerabilities because they cannot review every commit.

DevSecOps is the practice of integrating security tools and responsibilities into the development pipeline from day one. Not security audits after development — security checks running automatically on every commit, giving developers immediate feedback when they introduce vulnerabilities, before the vulnerable code ever reaches a production environment.

This guide covers the full DevSecOps toolchain: SAST and DAST tools and their CI/CD integration, container image scanning, dependency vulnerability management, secrets detection, Infrastructure as Code security, and the metrics that indicate a mature DevSecOps program.

DevSecOps: Shift-Left Security in Practice

"Shift left" refers to moving security earlier in the software development lifecycle — to the left on a timeline that runs from requirements through deployment. Earlier detection means cheaper remediation.

The cost curve is well-established:

A SQL injection vulnerability caught by a SAST tool as the developer writes the code takes minutes to fix. The same vulnerability discovered in a penetration test takes days (remediation, testing, deployment). Discovered in production after exploitation, it takes weeks (incident response, forensics, customer notification, remediation, redeployment) and potentially carries regulatory consequences.

The goal of a DevSecOps pipeline is not to add security gates that slow deployments — it is to catch vulnerabilities so early that fixing them is trivial. The developer who introduces a vulnerability should see the SAST alert within minutes, while the code is still in their working context.

SAST: Static Application Security Testing

SAST analyzes source code without executing it. The analysis builds a model of how data flows through the application and identifies patterns that match known vulnerability classes: SQL injection, XSS, path traversal, insecure cryptography, hard-coded credentials.

How SAST Works

The analyzer parses source code into an abstract syntax tree (AST), models data flow (tracking where user-controlled data can flow), and applies vulnerability pattern matching. Sophisticated SAST tools perform taint analysis — tracking "tainted" (user-controlled) data through transformations to identify where it reaches dangerous sinks (database queries, shell commands, HTML output) without being sanitized.

SAST Tools

Semgrep is particularly strong for custom rule development — writing a rule that catches a specific vulnerability pattern in your codebase is straightforward, and the community rules library provides thousands of pre-built patterns. CodeQL (GitHub Advanced Security) is powerful for complex dataflow vulnerabilities that simpler pattern-matching cannot catch.

CI/CD Integration

SAST should run on every pull request. The workflow:

1. Developer opens pull request
2. SAST scan runs automatically (typically 2-10 minutes for most codebases)
3. New findings in the diff are reported as inline PR comments and PR status checks
4. Critical and high severity findings block merge; medium findings are advisory

The key word is "new findings in the diff." Running SAST on the full codebase and blocking on all findings — including pre-existing ones — produces an unusable gate. Start by establishing a baseline (existing findings are tracked but not blocking), then enforce the policy that new code cannot introduce new critical or high vulnerabilities.

False positive management: SAST tools generate false positives. An alert rate above 20-30% false positives undermines developer trust and leads to alerts being ignored. Tune rule sets to suppress false-positive-prone rules or adjust their severity. Build a process for developers to mark findings as false positives with explanation — track these to identify rules that need tuning.

DAST: Dynamic Application Security Testing

DAST tests the running application from the outside, simulating how an attacker would probe it. It discovers vulnerabilities that SAST cannot find: runtime configuration errors, authentication bypass through parameter manipulation, XSS in rendered HTML, and injection vulnerabilities that SAST's taint analysis missed.

How DAST Works

DAST sends HTTP requests to the application's endpoints, systematically varying parameters, headers, and request bodies to probe for vulnerability patterns. It inspects responses for error messages, unexpected behavior, and signs of successful injection.

DAST Tools

OWASP ZAP is the standard open-source choice. Its CI/CD integration via the zap-baseline Docker image runs a baseline scan against a deployed application in under 10 minutes, reporting OWASP Top 10 vulnerabilities and misconfigurations.

CI/CD Integration

DAST requires a running application — it cannot run on source code. The pipeline position:

1. Build artifact is created
2. Artifact deployed to a staging environment
3. DAST scan runs against the staging URL
4. Critical findings block promotion to production; others create tracking issues

DAST scans are slower than SAST (10 minutes to several hours depending on application size and scan depth). For large applications, run a fast baseline scan on every deployment and a deep scan nightly or on release candidates.

Container Security

Modern applications run in containers. A container image is a packaged execution environment that may include base OS packages, language runtimes, and application dependencies — any of which can have known vulnerabilities.

Container Image Scanning

Container scanners analyze image layers against vulnerability databases (NVD, GHSA, OS vendor advisories) and report packages with known CVEs:

Trivy is the pragmatic choice for most teams — it is fast, comprehensive, and integrates into CI/CD with a single Docker command. Run Trivy on every image build:

# GitHub Actions
- name: Scan container image
  uses: aquasecurity/trivy-action@master
  with:
    image-ref: 'myapp:${{ github.sha }}'
    exit-code: '1'
    severity: 'CRITICAL,HIGH'

The exit-code: 1 configuration fails the pipeline on critical and high vulnerabilities. This prevents shipping images with known critical vulnerabilities. For base image vulnerabilities you cannot immediately patch, add the CVE to an allowlist with an assigned owner and expiry date.

Container Hardening

Beyond vulnerability scanning:

• Use minimal base images (distroless, Alpine) to reduce the attack surface
• Run containers as non-root users
• Set read-only filesystems where possible
• Never include secrets in image layers — use runtime secret injection (Kubernetes Secrets, AWS Secrets Manager)
• Scan not just at build time, but also in the running registry (new CVEs are discovered continuously)

Dependency Vulnerability Scanning

The average enterprise application has hundreds of direct and transitive dependencies. Vulnerabilities in dependencies — Log4Shell, the npm event-stream incident, the 2021 ua-parser-js compromise — are the most common source of critical security incidents in software.

Tools for dependency scanning:

Dependabot provides automatic pull requests to upgrade vulnerable dependencies — the fix is already prepared, the developer just needs to review and merge. For supply chain security (preventing compromised packages from being introduced), Socket Security provides behavioral analysis of new and updated packages.

Integrate dependency scanning in CI/CD to block deployments with critical vulnerabilities. Maintain a Software Bill of Materials (SBOM) — a machine-readable inventory of all dependencies — generated at build time. SBOMs enable rapid response when a new vulnerability is discovered: you can immediately identify which applications are affected.

Secrets Detection

A developer accidentally commits a database password, AWS access key, or API secret to a Git repository. The commit is pushed to a remote repository. Even if the repository is private, the secret should be considered compromised — it may be accessible to all developers, CI/CD systems, and anyone who can read the repository history.

Secrets scanning tools detect this before or immediately after it happens:

Pre-commit hooks are the most effective defense: stop the commit before it leaves the developer's machine. The detect-secrets library installs as a pre-commit hook and blocks commits that contain high-entropy strings matching known secret patterns (API key formats, private key headers, connection strings).

Historical scanning is necessary after implementing secrets detection — before the tooling was in place, secrets may already be in the repository history. TruffleHog and GitGuardian can scan the entire commit history. Rotate any secrets found.

IaC Security Scanning

Infrastructure as Code (Terraform, CloudFormation, Kubernetes manifests, Helm charts) defines cloud resources programmatically. IaC misconfigurations — a Terraform resource that creates a world-accessible S3 bucket, a Kubernetes pod spec running as root — are cloud security risks that can be caught before deployment.

Checkov runs against your IaC directory and reports policy violations against 1,000+ built-in checks covering CIS Benchmarks, PCI-DSS, SOC 2, and cloud provider best practices. Integrate it into the PR pipeline — IaC changes that introduce security misconfigurations should not merge.

DevSecOps Metrics

Measure the effectiveness of the security automation program:

Mean Time to Detect (MTTD): how long after a vulnerability is introduced does the pipeline detect it? SAST running on every commit should produce detection within minutes. DAST running on deployments produces detection within hours.

Mean Time to Remediate (MTTR): how long from detection to fix and deployment? For critical vulnerabilities: target 7 days maximum. For high: 30 days. Tracked over time, MTTR indicates whether the security process is creating a backlog or keeping pace.

False positive rate: what percentage of SAST/DAST findings are false positives? Above 30% indicates tool misconfiguration that will erode developer trust. Target: below 15%.

Security debt: the total count of open, unresolved vulnerabilities weighted by severity. Trending down indicates the program is reducing risk. Trending up indicates the team is not keeping pace.

Deployment frequency: DevSecOps should not slow down deployments. If deployment frequency decreases after implementing security scanning, the gates are too strict or the tools are too slow — both are fixable. The goal is security without friction.

A mature DevSecOps program catches most vulnerabilities before they reach staging and catches the rest before they reach production. It does not eliminate all security work — manual code review, penetration testing, and threat modeling remain necessary — but it eliminates the class of vulnerabilities that should never reach production in the first place.