DevSecOps and Threat Modeling¶

By Sameer Alam · Updated 14 September 2026

What You'll Learn¶

• What DevSecOps changes about who owns security and when it happens
• Which automated controls belong at each stage of delivery
• How to run a lightweight threat model with STRIDE, using a worked example
• How to secure CI/CD pipelines, which are high-value targets in their own right

What DevSecOps Means¶

Traditional security reviewed a finished system just before release: slow, adversarial, and too late to change the design. DevSecOps makes security a shared responsibility built into everyday engineering:

• Security requirements and threat models happen during design, when changes are cheap.
• Automated checks run on every commit and build, giving developers feedback in minutes.
• Guardrails over gates: secure defaults and paved roads make the safe path the easy path.
• Security teams build tooling, set policy, coach, and handle the hard problems — they don't manually review every change.

Controls by Stage¶

Start with the controls that catch the most common real incidents — leaked secrets, known-vulnerable dependencies, and cloud misconfigurations — before investing in the rest. See Code Quality: Open-Source Tools for SAST and SCA setup.

Shift Left, and Shift Right¶

• Shift left means catching issues earlier, where they're cheaper to fix.
• Shift right means assuming some issues will reach production anyway, and detecting and containing them there: runtime monitoring, anomaly detection, least privilege that limits the blast radius, and practiced incident response.

You need both. No pipeline catches everything, and zero-day vulnerabilities in dependencies appear after you ship.

Threat Modeling¶

A threat model answers four questions (from the Threat Modeling Manifesto):

1. What are we working on?
2. What can go wrong?
3. What are we going to do about it?
4. Did we do a good enough job?

It doesn't need to be a big formal exercise. An hour with the team, a diagram, and a list is enough for most features. Do it when designing a new service, adding a new trust boundary (a public endpoint, a third-party integration), or handling a new kind of sensitive data.

STRIDE¶

STRIDE is a checklist for question two:

Worked Example: A File Upload Feature¶

What are we working on? Users upload invoices (PDFs) through the web app. An API stores them in S3, and a worker extracts text for search.

flowchart LR
  U["User browser"] -->|"HTTPS, session cookie"| API["Upload API"]
  API -->|"presigned URL"| U
  U -->|"PUT file"| S3["S3 bucket<br/>invoices"]
  S3 -->|"event"| Q["SQS queue"]
  Q --> W["Text extraction worker"]
  W --> DB["Search index"]
  subgraph TB1["Trust boundary: internet"]
    U
  end

What can go wrong? Walking each element and data flow through STRIDE:

What are we going to do about it?

Did we do a good enough job? Review the model when the design changes, and check that each mitigation has a test or a monitored control — not just a ticket that was closed.

Securing the CI/CD Pipeline¶

Pipelines hold credentials to production and can change what gets deployed, so attackers target them directly. Common attacks:

Hardening checklist for GitHub Actions¶

on:
  pull_request:          # not pull_request_target for untrusted code
  push:
    branches: [main]

permissions:
  contents: read         # default least privilege; grant more per job

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      # Pin third-party actions to a full commit SHA; keep the version as a comment
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
        with:
          persist-credentials: false

      - name: Build
        run: make build

  deploy:
    needs: build
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    environment: production        # required reviewers and branch restrictions
    permissions:
      contents: read
      id-token: write              # OIDC to the cloud, no stored keys
    steps:
      - run: echo "deploy with short-lived credentials"

• Least-privilege GITHUB_TOKEN with permissions: at the workflow and job level.
• Never run untrusted code with secrets. pull_request_target and workflow_run run with repository secrets; don't check out and execute pull request code in them.
• Pin actions to commit SHAs, and let Dependabot or Renovate update them. Tags can be moved; SHAs can't.
• Use OIDC federation instead of stored cloud credentials — see AWS OIDC roles.
• Protect production with environments, required reviewers, and branch or tag restrictions.
• Treat workflow files as sensitive code — require code owner review for .github/workflows/.
• Isolate self-hosted runners: ephemeral runners, never shared between public and private repositories.
• Audit with OpenSSF Scorecard, which checks branch protection, pinned dependencies, token permissions, and more.

Common Mistakes¶

• Treating security as a final approval gate instead of automated feedback throughout delivery.
• Turning on every scanner at once with blocking thresholds, flooding teams with findings they learn to ignore.
• Threat models written once for compliance and never updated when the design changes.
• Mitigations tracked as tickets without a test or monitored control proving they work.
• Workflows with default write permissions, unpinned third-party actions, and long-lived cloud keys in secrets.
• Running pull request code from forks in pull_request_target workflows with access to secrets.

Interview Questions¶

• What does "shift left" mean, and why isn't it enough on its own?
• Walk through STRIDE and give an example threat for each category.
• Threat model a feature that lets users upload files. What are the top risks?
• How would you harden a GitHub Actions pipeline that deploys to production?
• What is poisoned pipeline execution, and how do you prevent it?

Next¶

Continue to Secrets Management With Vault.