DevSecOps — Shifting Security Left

Building security into every step instead of bolting it on at the end.

What Shift Left Means

For decades, security worked like this: developers built things, security reviewed them, found problems, demanded changes weeks before launch. Result: late-stage rework, missed deadlines, security as adversary.

DevSecOps inverts this. Security is everyone's responsibility, integrated into every step of the development lifecycle. Tools and practices catch issues at the earliest possible point — when fixing them is cheap.

Old world:
  design → build → test → security review (find problems) → rework → ship
                                  └── too late, expensive ──┘

DevSecOps:
  design → build → test → ship → monitor
   ▲       ▲       ▲      ▲       ▲
   │       │       │      │       │
 threat  linters  scans  signing  runtime
 model   SAST     DAST   policies detection

The big change isn't the tools — it's the culture. Developers OWN security in their code. Security engineers build TOOLS that make secure development the default.

Static Analysis (SAST)

Static Application Security Testing scans source code for vulnerabilities without running it.

Tools:
• Semgrep — fast, customizable, good defaults
• SonarQube — broad code quality including security
• CodeQL (GitHub) — powerful, GitHub-integrated
• Snyk Code — commercial, well-curated rules
• Bandit (Python), gosec (Go), eslint security plugins

What SAST catches:
• SQL injection: string concatenation in queries
• Hardcoded secrets in source
• Insecure deserialization
• Path traversal vulnerabilities
• Use of weak cryptography

Running Semgrep in CI:

- uses: returntocorp/semgrep-action@v1
  with:
    config: |
      p/owasp-top-ten
      p/security-audit
      p/secrets

False positive management is critical. Tune rules to your codebase. Anything that fires daily without action is noise — disable it or make it actionable.

SAST runs in seconds-to-minutes. Add it to PR checks. Block PRs with critical findings. Auto-create issues for non-critical findings.

Dependency Scanning

Most of your code's vulnerabilities aren't in your code — they're in dependencies. The npm ecosystem alone publishes thousands of CVEs per year.

Tools:
• GitHub Dependabot — automatic, free, integrated
• Snyk — commercial, broader, faster updates
• Trivy — open source, also scans containers
• OWASP Dependency-Check — Java-focused

Dependabot setup (.github/dependabot.yml):

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    open-pull-requests-limit: 10
  - package-ecosystem: "docker"
    directory: "/"
    schedule:
      interval: "weekly"

Dependabot opens PRs to bump vulnerable dependencies. Pair with auto-merge for patch versions.

Critical patterns:
• PIN your dependencies (use lock files)
• REVIEW major updates manually
• Run dependency scans on every PR
• Set policies for severity: block CRITICAL, alert HIGH, ignore LOW

Don't let vuln backlogs pile up. A team that's "behind on Dependabot PRs by 6 months" is at the same risk level as one with no scanning at all.

IaC & Container Scanning

Infrastructure as Code can have security flaws too — public S3 buckets, security groups open to 0.0.0.0/0, missing encryption.

Tools that scan IaC:
• Checkov — open source, Terraform/CloudFormation/K8s/Dockerfile
• tfsec — Terraform-focused
• Trivy — also does IaC scanning
• Snyk IaC — commercial

- name: Run Checkov
  uses: bridgecrewio/checkov-action@master
  with:
    directory: terraform/
    framework: terraform

Container scanning was covered in Module 11. The DevSecOps pipeline ties it all together:

- name: Build image
  run: docker build -t myapp:${{ github.sha }} .

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

- name: Sign image
  run: cosign sign --yes myapp:${{ github.sha }}

- name: Generate SBOM
  run: syft myapp:${{ github.sha }} -o spdx-json > sbom.json

Multi-layered: trusted base images, scan at build, sign, verify at deploy, monitor at runtime.

Runtime Security

Static checks miss runtime issues. Things you only see when code is actually executing:
• Unusual API calls
• Lateral movement attempts
• Cryptocurrency miners
• Data exfiltration

Cloud-native runtime security tools:
• Falco — open source runtime security for K8s. Detects anomalous syscalls.
• AWS GuardDuty — threat detection across AWS APIs and traffic
• GCP Security Command Center
• Sysdig Secure, Aqua, Wiz — commercial unified platforms

A Falco rule:

- rule: Unexpected outbound connection
  desc: Detect unexpected outbound connections from a container
  condition: >
    outbound and container.image.repository != "expected-image"
  output: Unexpected egress (image=%container.image.repository dest=%fd.rip:%fd.rport)
  priority: WARNING

For most teams in 2026:
• Use cloud-native (GuardDuty, Defender for Cloud) for cloud-API anomalies
• Run Falco on K8s if you have it
• Add a unified tool (Wiz, Lacework, Sysdig) when you have budget and scale

The Mindset Shift

Tools alone don't make DevSecOps. Cultural changes that matter:

1. Security is in the definition of done. Code isn't done if it has known vulnerabilities, no auth, or lacks input validation.

2. Threat modeling at design time. Before coding a new feature, the team thinks: who could abuse this? What could go wrong? STRIDE framework (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) is a useful structure.

3. Security champions. One developer per team gets training, becomes the local expert, knows when to escalate.

4. Blameless security postmortems. When a vulnerability is found, "why was the system designed in a way that allowed this?" not "who's at fault?"

5. Make the secure path the easy path. If using the right framework defaults gives you good security, devs use them. If security requires extra work, it gets skipped under deadline pressure.

The next lesson covers secrets management — the most common DevSecOps weak point and one of the easiest to fix.