PS Product SecurityKnowledge Base

🧭 DevSecOps Stage Map and Modern Pipeline Patterns

Intro: Large public DevSecOps guides are most useful when they provide a clean stage model that engineers can remember. This page translates that model into a 2026-ready Product Security interpretation: what belongs in plan, code, build, test, deploy, and operate; what evidence should be produced automatically; and which older examples must be modernized before you copy them into production.

What this page includes

  • a stage-by-stage DevSecOps map for 2026 delivery pipelines
  • what older DevSecOps tutorials still teach well
  • what should be modernized before use in current CI/CD platforms
  • snippet links and KB cross-links for GitHub Actions, GitLab, release evidence, and cloud/runtime follow-through

Why this page exists

Public DevSecOps material is often strongest in two places:

  1. it explains the pipeline as a sequence of stages that people can reason about quickly;
  2. it gives short snippets that make the topic feel implementable.

The weakness is that many of those examples age fast. A stage model can remain useful for years, while:

  • a workflow action version goes stale;
  • branch naming changes;
  • direct SSH deployment becomes the wrong default;
  • provenance, attestations, OIDC, environment protection, and evidence retention become first-class concerns.

This page keeps the stage model and modernizes the implementation expectations.

The 2026 stage map

Stage Main question Fast controls Heavier controls / later lanes Evidence to retain First KB page
Plan / design what security requirements and invariants must hold? threat prompts, trust-boundary notes, authz assumptions, data classification formal threat model, exception review, tenant-isolation review review record, ADR, threat model summary Threat Modeling Methods and Workflows
Develop what should fail before code even leaves the workstation? pre-commit secrets, linters, fast SAST, dependency review hints, secure defaults in templates deeper language or framework analysis commit checks, local config standards, repo policy files Develop Phase — Practical DevSecOps Controls
Build can we trust what was built and from where it came? reproducible build jobs, image and dependency scans, manifest linting provenance, attestation, signing, isolated release jobs artifact digest, SBOM, provenance, build metadata Software Supply Chain Foundations
Test what should block release versus inform later review? unit, integration, API contract, authn/authz smoke tests, lightweight DAST in preview fuzzing, IAST, manual review, deep authenticated DAST test logs, scanner artifacts, gate decisions Test Phase — Fast Gates, Deep Tests, and What Still Belongs Out of Band
Deploy who is allowed to release, under what protections, to which target? protected environments, approval gates, concurrency controls, rollout guardrails phased rollouts, environment-specific policy bundles approval records, deploy actor, target, release evidence Protected Environments and Deployment Approvals
Operate how do we verify posture after release and respond when controls drift? runtime alerts, audit logs, cloud posture checks, dependency drift review detection engineering, purple-team validation, recurring evidence reviews alert trails, incident records, recurring posture evidence Logging and Telemetry Strategy

What older stage-oriented DevSecOps tutorials still get right

Several older articles and community guides remain useful because they keep the delivery flow simple:

  • plan / design;
  • develop / code;
  • build / code analysis;
  • test;
  • deploy;
  • monitor / alert.

That sequence is still a good mental model for Product Security conversations, backlog planning, and interview calibration.

They also get three durable ideas right:

1. Security belongs in the delivery system, not only in a side program

Security checks should be placed where engineers already work: repository settings, merge controls, CI jobs, artifact generation, environment protection, and deployment policy.

2. Fast feedback beats perfect-but-late feedback

Most teams improve faster by moving a few high-signal checks earlier than by adding huge slow scans everywhere.

3. Every stage should either prevent risk, detect drift, or create evidence

A control that does none of those three usually becomes noise.

What must be modernized before you copy public examples into production

Replace long-lived cloud secrets with workload identity

Use OIDC or workload federation where possible instead of static cloud keys in CI variables.

See:

Replace “build then SSH into prod” with protected release flow

Direct SSH deployment examples are useful for illustrating flow, but modern production patterns usually need:

  • protected branches or tags;
  • protected environments;
  • deployment approvals;
  • release evidence;
  • rollback references;
  • target-specific concurrency controls.

Add provenance, attestations, and artifact trust

A 2026-ready pipeline should not stop at “build succeeded”. It should also answer:

  • what artifact was produced;
  • from which source revision;
  • by which workflow;
  • with which digest;
  • and whether trust metadata exists for release use.

Separate fast gates from heavy or risky scans

Do not force every scan into the pull-request path.

A practical split is:

  • PR path: lint, secrets, fast SAST, dependency review, light policy checks;
  • main / release path: SBOM, image scanning, provenance, signing, deeper integration tests;
  • scheduled or expert lanes: full DAST, fuzzing, threat-informed review, cloud posture audits.

Treat runtime and cloud posture as part of DevSecOps, not as a separate afterthought

The delivery pipeline should link to the operating model that follows release:

  • runtime alerts;
  • cloud configuration state checks;
  • policy exceptions;
  • evidence retention for audits and post-incident review.

A practical reference architecture for stage-based pipelines

Minimum viable stage set

For many teams, the minimum useful stage set is:

  1. prepare / lint
  2. build
  3. unit + integration
  4. security checks
  5. package + evidence
  6. deploy preview
  7. smoke / authz checks
  8. protected production deploy

Minimum evidence set

A good minimum evidence set is:

  • commit SHA and merge metadata;
  • required job results;
  • artifact digest;
  • SBOM reference;
  • provenance / attestation reference when supported;
  • protected-environment approvals;
  • deployment record and rollback target.

Use with:

Snippets