# 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](/application-security-and-secure-sdlc/index/threat-modeling-methods-and-workflows.md)                  |
| 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](/devsecops-cicd-and-supply-chain/index/develop.md)                                              |
| 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](/devsecops-cicd-and-supply-chain/index-1/software-supply-chain-foundations.md)                             |
| 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](/devsecops-cicd-and-supply-chain/index/test.md)                      |
| 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](/devsecops-cicd-and-supply-chain/index-1/protected-environments-and-deployment-approvals.md) |
| 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](/attack-paths-testing-detection-and-hardening/index/logging-and-telemetry-strategy.md)                        |

## 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:

* [GitHub, GitLab OIDC, and Cloud Trust Patterns](/architecture-api-crypto-and-identity/index-2/github-gitlab-oidc-and-cloud-trust-patterns.md)
* [GitHub Actions for Product Security](/devsecops-cicd-and-supply-chain/index-1/github-actions-for-product-security.md)

### 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:

* [Compliance-to-Engineering Evidence Pass](/metrics-audit-risk-evidence-and-compliance/index-1/compliance-to-engineering-evidence-pass.md)
* [GitLab Release Evidence](/devsecops-cicd-and-supply-chain/index-1/gitlab-release-evidence.md)

## Snippets

* [Modernized GitHub Actions stage pipeline starter](https://github.com/D3One/Product-Security-Gitbook/blob/main/snippets/ci/github-actions/devsecops-stage-pipeline-modernized.yml)
* [Restricted artifact access and matrix patterns for GitLab](https://github.com/D3One/Product-Security-Gitbook/blob/main/snippets/ci/gitlab/restricted-artifact-access-and-matrix.yml)
* [Secure GitLab pipeline 2026 starter](https://github.com/D3One/Product-Security-Gitbook/blob/main/snippets/ci/gitlab/secure-gitlab-pipeline-2026.yml)

## Related pages

* [Develop Phase — Practical DevSecOps Controls](/devsecops-cicd-and-supply-chain/index/develop.md)
* [Test Phase — Fast Gates, Deep Tests, and What Still Belongs Out of Band](/devsecops-cicd-and-supply-chain/index/test.md)
* [DevSecOps Toolchain — Practical Map, Legacy vs Current](/devsecops-cicd-and-supply-chain/index/devsecops-toolchain-practical-map-legacy-vs-current.md)
* [GitLab CI/CD Modern Security Patterns](/devsecops-cicd-and-supply-chain/index-1/gitlab-ci-cd-modern-security-patterns.md)
* [GitHub Actions for Product Security](/devsecops-cicd-and-supply-chain/index-1/github-actions-for-product-security.md)
* [Runner Isolation and Trust Boundaries](/devsecops-cicd-and-supply-chain/index-1/runner-isolation-and-trust-boundaries.md)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.product-security.expert/devsecops-cicd-and-supply-chain/index/devsecops-stage-map-and-modern-pipeline-patterns.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.