DevSecOps means building security into the everyday development workflow instead of checking it once before release. In practice, a DevSecOps workflow is a series of small, automated security checks attached to steps your team already takes: designing a feature, writing code, opening a pull request, building, deploying and running in production.

Our 2024 article explained why teams adopt DevSecOps. This 2026 update covers how to do it: a workflow broken into stages, the checks that belong in each one, and how zero-trust principles apply to your pipelines. Two things have changed since then. Software supply chain attacks are now a mainstream risk, and a growing share of code is written with AI coding assistants and agents, so automated guardrails matter more than they did.

What a DevSecOps workflow looks like

In a secure developer workflow, checks run where developers already work: in the IDE, on commit, in the pull request and in CI. A separate security portal tends to go unopened. Findings come with a location, a severity and a suggested fix, and the noise is tuned down until people trust the alerts. Policies are enforced automatically, so the pipeline blocks a merge or a deploy that breaks an agreed rule and nobody has to remember to check.

The stages below follow a feature from planning to production.

Stage 1: Plan and design

Security work begins before the first line of code. For features that touch authentication, payments, personal data or external integrations, run a lightweight threat model: what are we protecting, who might attack it, and how? Write security requirements into the user story as acceptance criteria, for example "only the account owner can export their data" or "tokens expire after 15 minutes of inactivity". The OWASP Application Security Verification Standard works well as a checklist here.

Stage 2: Code (IDE and pre-commit)

  • Secrets scanning in pre-commit hooks stops API keys, passwords and tokens from reaching the repository at all. Few controls give as much protection for as little effort.
  • Linters and security plugins in the IDE flag risky patterns, such as SQL built from strings or unsafe deserialisation, while the developer is still typing.
  • Templates and shared libraries come with secure defaults. Shared modules for authentication, input validation and logging mean developers don't each reinvent them.
  • AI-generated code follows the same rules. Code from assistants and agents goes through the same checks and review as human code, and agents should never get production credentials.

Stage 3: Pull request and continuous integration

Most of the automated checking happens here. Every pull request triggers a set of scans, and the results show up in the PR itself.

  • SAST (static application security testing) analyses source code for vulnerabilities such as injection, path traversal and insecure cryptography.
  • SCA (software composition analysis) checks open-source dependencies for known vulnerabilities and licence problems. Pair it with automated dependency update pull requests so fixes are easy to merge.
  • Server-side secrets scanning catches what slipped through, since developers can skip pre-commit hooks.
  • IaC scanning checks Terraform, Kubernetes manifests, Helm charts and Dockerfiles for misconfigurations: public storage buckets, open security groups, containers running as root, missing encryption.
  • Container image scanning finds vulnerable packages in base images. Small, minimal base images reduce the attack surface.
  • Code review covers security too, and branch protection requires a second reviewer for sensitive areas.

At first, block merges only on new critical and high findings. Teams that block on the whole backlog of old issues on day one usually end up switching the checks off.

Stage 4: Build and supply chain

Supply chain security protects the path from source code to the artefact you deploy.

  • Builds are reproducible and isolated, run on ephemeral CI runners, with pinned dependency versions and lock files.
  • Every build generates an SBOM (software bill of materials) listing each component and version. When the next widely exploited library vulnerability appears, you can tell within minutes whether you are affected.
  • Container images and packages are signed, with a record of where and how they were built (provenance). The SLSA framework describes maturity levels for this.
  • A private artefact registry is the only source for deployments.

Stage 5: Test and pre-production

  • DAST (dynamic application security testing) probes the running application in a staging environment for missing security headers, injection points and broken authentication flows.
  • API security testing checks authorisation on every endpoint. Broken object-level authorisation, where one user can read another user's data by changing an ID, is still one of the most common API flaws.
  • Specialists run penetration tests periodically, for major releases or high-risk systems, because human attackers try things no scanner will.

Stage 6: Deploy

  • Policy as code lets the deployment platform admit only signed images from your registry that passed the required checks.
  • Secrets come from a secrets manager and are injected at runtime. They are never baked into images or committed in configuration files.
  • Deploy identities have least privilege, are scoped to one environment and use short-lived credentials.
  • Progressive delivery (canary or blue-green) lets you roll back a bad release quickly.

Stage 7: Run and monitor

  • Centralised logs and alerts for authentication failures, privilege changes and unusual traffic.
  • Runtime protection and anomaly detection for containers and cloud workloads.
  • Continuous cloud posture checks that catch configuration drift made outside the pipeline.
  • Continuous vulnerability monitoring of deployed SBOMs, since new vulnerabilities get disclosed in code you haven't touched.
  • An incident response runbook, practised at least once, and blameless post-mortems that feed back into stage 1.

Zero trust in DevSecOps workflows

Under zero trust, a request is never trusted just because it comes from inside the network or from a familiar tool. In development workflows that translates into a few rules:

  • People sign in to source control, CI, cloud consoles and registries through SSO with phishing-resistant multi-factor authentication.
  • Machines get short-lived credentials. CI pipelines use workload identity federation (for example OIDC tokens) to obtain temporary cloud credentials, so no long-lived access keys sit in stored secrets.
  • Each pipeline, service account and AI agent gets only the permissions its job needs.
  • Signatures and provenance of every artefact are checked at deploy time.
  • Development, staging and production live in separate accounts or projects with separate access.
  • The pipeline itself is protected: CI configuration is treated as sensitive code, changes to it are reviewed, and few people can modify it.

Rolling out DevSecOps without slowing the team

  1. Start with secrets scanning, SCA with automatic update PRs, and branch protection. They give the most value for the least friction.
  2. Add SAST and IaC scanning to pull requests, tuned to block only new high-severity issues.
  3. Secure the supply chain with SBOMs, signing and short-lived CI credentials.
  4. Add DAST and runtime monitoring once the product is in production with real users.
  5. Measure progress: track time to fix critical vulnerabilities, the share of builds with SBOMs, and how many secrets were caught before they were pushed.

Tools only go so far without the people around them. Name a security champion in each team, give developers short, practical secure-coding training built on your own stack, and make it easy to ask for a security review. A strong technical leadership function sets the policy, and the pipeline enforces it.

For regulated products such as fintech and healthcare applications, the same workflow produces audit evidence as a by-product: scan results, approvals, SBOMs and deployment records are all generated automatically.

FAQ

What is the difference between DevOps and DevSecOps?

DevOps joins development and operations so teams ship faster and more reliably. DevSecOps makes security a shared responsibility as well, with automated checks at every stage of the same workflow.

What are the most important DevSecOps tools to start with?

Secrets scanning, software composition analysis for dependencies, and SAST in pull requests. After that, add IaC scanning, container scanning, SBOM generation, signing and DAST.

Does DevSecOps slow down development?

Not if the checks are automated, fast and tuned to block only serious new issues. It usually saves time by catching problems before they reach production.

How does zero trust apply to CI/CD?

Every person, pipeline and service proves its identity and gets short-lived, least-privilege access, and every artefact is verified before deployment.

If you want to set up a DevSecOps workflow for a new product or tighten security in an existing one, talk to the EmphaSoft team. We can review your pipeline, close the most serious gaps first and build security checks into the way your developers already work.