DevOps Pipeline Security in 2026: SAST, DAST, Supply Chain and Interview Questions

DevOps pipeline security requires embedding security checks at every stage of the CI/CD workflow, from pre-commit hooks to production monitoring. The Datadog State of DevSecOps Report 2026 reveals that 87% of organizations run services with at least one known exploitable vulnerability, while software supply chain attacks now cost the global economy over $80 billion annually.

SAST: Static Analysis That Catches Vulnerabilities Before Merge

Static Application Security Testing (SAST) analyzes source code without executing it. The tool parses the codebase, builds an abstract syntax tree, and matches patterns against known vulnerability signatures. Running SAST on every pull request catches SQL injection, XSS, and hardcoded credentials before code reaches the main branch.

Semgrep has become the de facto open-source SAST tool in 2026. Unlike regex-based scanners, Semgrep understands code structure and supports custom rules in YAML.

# .github/workflows/sast.yml
name: SAST Scan

on:
  pull_request:
    branches: [main, develop]

jobs:
  semgrep:
    runs-on: ubuntu-latest
    container:
      image: semgrep/semgrep:latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Run Semgrep
        run: semgrep scan --config=auto --sarif --output=semgrep.sarif
        
      - name: Upload SARIF
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: semgrep.sarif

The --config=auto flag loads community rules matching the detected languages. SARIF output integrates with GitHub Security tab for tracking findings over time.

DAST: Runtime Testing That Finds What Static Analysis Misses

Dynamic Application Security Testing (DAST) attacks a running application to find vulnerabilities that only manifest at runtime. Broken authentication, authorization flaws, and business logic bugs require actual HTTP requests to detect. SAST cannot find that an admin endpoint lacks proper access control, but DAST will try to access it without credentials and flag the exposure.

OWASP ZAP remains the most widely deployed open-source DAST tool. ZAP 3.0, released in early 2026, added native support for GraphQL and gRPC scanning.

# .github/workflows/dast.yml
name: DAST Scan

on:
  deployment:
    types: [created]

jobs:
  zap-scan:
    runs-on: ubuntu-latest
    steps:
      - name: ZAP Full Scan
        uses: zaproxy/action-full-scan@v0.12.0
        with:
          target: ${{ secrets.STAGING_URL }}
          rules_file_name: '.zap/rules.tsv'
          cmd_options: '-a -j -l WARN -z "-config api.disablekey=true"'
          
      - name: Upload Report
        uses: actions/upload-artifact@v4
        with:
          name: zap-report
          path: report_html.html

DAST runs post-deployment because it needs a live target. The staging environment serves as the test surface, keeping production isolated from scanning traffic.

SCA: Dependency Scanning for Known Vulnerabilities

Software Composition Analysis (SCA) scans dependencies against vulnerability databases like the National Vulnerability Database and GitHub Advisory Database. A single vulnerable transitive dependency can expose the entire application. The 2026 Datadog report found that 42% of services depend on libraries no longer actively maintained.

Trivy scans containers, filesystems, and git repositories for vulnerabilities in one binary. It generates SBOM output in CycloneDX and SPDX formats.

# .github/workflows/sca.yml
name: Dependency Scan

on:
  push:
    branches: [main]
  schedule:
    - cron: '0 6 * * *'  # Daily at 6 AM

jobs:
  trivy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Run Trivy vulnerability scanner
        uses: aquasecurity/trivy-action@0.28.0
        with:
          scan-type: 'fs'
          scan-ref: '.'
          format: 'sarif'
          output: 'trivy-results.sarif'
          severity: 'CRITICAL,HIGH'
          
      - name: Upload Trivy scan results
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: 'trivy-results.sarif'

The scheduled daily scan catches newly disclosed CVEs even without code changes. Filtering to CRITICAL and HIGH severity prevents alert fatigue from low-risk findings.

Supply Chain Security: SBOM and SLSA Provenance

The EU Cyber Resilience Act, with reporting obligations taking effect in September 2026, mandates Software Bill of Materials (SBOM) generation for products sold in the EU. An SBOM lists every component in the software, including direct dependencies, transitive dependencies, and their versions.

SLSA (Supply-chain Levels for Software Artifacts) complements SBOM by verifying how software was built. SBOM answers "what components are in this software?" while SLSA answers "can the build process be trusted?"

# .github/workflows/supply-chain.yml
name: Supply Chain Security

on:
  push:
    tags:
      - 'v*'

jobs:
  build-with-provenance:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      id-token: write
      attestations: write
    steps:
      - uses: actions/checkout@v4
      
      - name: Build container image
        run: docker build -t myapp:${{ github.ref_name }} .
        
      - name: Generate SBOM
        uses: anchore/sbom-action@v0.17.0
        with:
          image: myapp:${{ github.ref_name }}
          format: cyclonedx-json
          output-file: sbom.json
          
      - name: Sign with Cosign
        uses: sigstore/cosign-installer@v3.7.0
        
      - name: Sign image and attach SBOM
        run: |
          cosign sign --yes myapp:${{ github.ref_name }}
          cosign attach sbom --sbom sbom.json myapp:${{ github.ref_name }}
          cosign sign --yes --attachment sbom myapp:${{ github.ref_name }}

Sigstore's Cosign signs artifacts using keyless signing backed by the Fulcio certificate authority. The signature binds the artifact to the CI workflow that produced it, enabling verification that the image came from a trusted pipeline.

Secrets Detection: The First Line of Defense

Hardcoded secrets remain the most common security finding in codebases. AWS access keys, database passwords, and API tokens committed to version control have caused breaches at every scale. Secrets detection runs pre-commit to block credentials before they enter the repository.

Gitleaks detects secrets using regex patterns and entropy analysis. A pre-commit hook prevents secrets from ever being committed.

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.21.2
    hooks:
      - id: gitleaks
        args: ['--verbose']

# .github/workflows/secrets.yml
name: Secrets Detection

on:
  pull_request:

jobs:
  gitleaks:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
          
      - name: Gitleaks scan
        uses: gitleaks/gitleaks-action@v2
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

The fetch-depth: 0 option clones full history, allowing Gitleaks to scan all commits in the PR, not just the latest.

DevSecOps Interview Questions: What Recruiters Ask

DevSecOps interviews assess both security knowledge and practical CI/CD experience. The questions below appear frequently in 2026 interviews for senior DevOps and platform engineering roles. See more pipeline security questions on the CI/CD Pipeline Security interview module.

"How would you implement shift-left security in an existing pipeline?"

Shift-left security moves testing earlier in the development cycle. The practical implementation involves adding pre-commit hooks for secrets detection, SAST scans on pull requests, and SCA checks in the build phase. The key is incremental adoption: start with secrets detection because it has the lowest false-positive rate and highest signal, then add SCA for known CVEs, then tune SAST rules to reduce noise before enabling it as a blocking check.

"Explain the difference between SAST and DAST. When would you use each?"

SAST analyzes source code without execution. It finds SQL injection, XSS, and insecure cryptography by pattern matching against the code structure. SAST runs early, on every PR, because it only needs the code.

DAST attacks a running application. It finds authentication bypasses, broken access control, and injection vulnerabilities that only manifest at runtime. DAST runs post-deployment against a staging environment.

The two complement each other. SAST catches coding errors before merge; DAST verifies that the deployed application behaves securely. A mature pipeline runs both.

"What is an SBOM and why is it required?"

A Software Bill of Materials lists every component in the software, including direct and transitive dependencies with exact versions. Regulatory requirements like the EU Cyber Resilience Act mandate SBOM generation for products entering the EU market starting September 2026.

Practically, SBOM enables rapid incident response. When a new CVE drops, the security team can query the SBOM database to identify every service running the vulnerable component instead of scanning all repositories manually.

"How do you prevent alert fatigue in security tooling?"

Alert fatigue occurs when developers ignore security findings because the signal-to-noise ratio is too low. Prevention requires tuning each tool before enabling blocking gates. For SAST, disable rules that produce false positives in the codebase and enable them gradually after cleanup. For SCA, focus on CRITICAL and HIGH severity findings with known exploits. For DAST, configure baseline scans to exclude false positives from future runs.

The metric to track is time-to-fix for real vulnerabilities. If that number increases, developers are ignoring alerts.

Container and Runtime Security

Container image scanning catches vulnerabilities before deployment. Runtime security monitors containers in production for anomalous behavior. The combination addresses both known vulnerabilities (CVEs in base images) and unknown threats (compromised containers, cryptominers).

Trivy scans images as part of the build pipeline. Falco monitors runtime behavior using eBPF.

# .github/workflows/container-security.yml
name: Container Security

on:
  push:
    branches: [main]

jobs:
  scan-image:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Build image
        run: docker build -t myapp:${{ github.sha }} .
        
      - name: Scan image
        uses: aquasecurity/trivy-action@0.28.0
        with:
          image-ref: myapp:${{ github.sha }}
          format: 'table'
          exit-code: '1'
          severity: 'CRITICAL'
          ignore-unfixed: true

The ignore-unfixed: true flag skips vulnerabilities without available patches. This prevents blocking deployments for CVEs that cannot currently be remediated.

For runtime security, Falco rules detect suspicious activity in running containers. The container supply chain security module covers image signing and admission control in depth.

IaC Security: Scanning Terraform and Kubernetes Manifests

Infrastructure as Code introduces security risks at the configuration layer. Overly permissive IAM policies, publicly accessible S3 buckets, and unencrypted databases result from insecure defaults in IaC templates.

Checkov scans Terraform, CloudFormation, Kubernetes, Helm, and Dockerfiles for misconfigurations.

# .github/workflows/iac-scan.yml
name: IaC Security Scan

on:
  pull_request:
    paths:
      - 'terraform/**'
      - 'k8s/**'
      - 'helm/**'

jobs:
  checkov:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Run Checkov
        uses: bridgecrewio/checkov-action@v12
        with:
          directory: .
          framework: terraform,kubernetes,helm
          output_format: sarif
          output_file_path: checkov.sarif
          soft_fail: false
          
      - name: Upload SARIF
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: checkov.sarif

The path filter ensures IaC scans only run when infrastructure files change, reducing CI time for application-only changes.

The Complete DevSecOps Pipeline for 2026

A production-ready DevSecOps pipeline in 2026 integrates these tools at each stage:

• Pre-commit: Gitleaks (secrets), optional local SAST
• Pull request: Semgrep (SAST), Trivy (SCA), Checkov (IaC)
• Build: Container image scanning, SBOM generation
• Pre-deploy: Image signing with Cosign, admission control with Kyverno
• Post-deploy: DAST with ZAP against staging
• Runtime: Falco for container monitoring, cloud security posture management

The free stack (Semgrep, Trivy, ZAP, Gitleaks, Checkov, Falco) covers every category. Commercial tools add central dashboards, policy management, and reduced tuning effort, but the security coverage is achievable without licensing costs.

Organizations preparing for DevSecOps roles should practice building these pipelines in personal projects. The cloud identity and secrets management module covers the secrets management side of the equation.