How to Build a DevSecOps Pipeline: Step-by-Step Guide (2026)
Security can no longer be a gate at the end of the development cycle. DevSecOps embeds security testing into every stage of your CI/CD pipeline — from code commit to production runtime. This guide walks you through building a pipeline that catches vulnerabilities early without slowing down your team.
What Is DevSecOps?
DevSecOps is the practice of integrating security into every phase of the software development lifecycle (SDLC) rather than treating it as a separate phase. Instead of a security team reviewing code after it is written, DevSecOps automates security checks directly in the CI/CD pipeline — making security a shared responsibility between development, operations, and security teams.
The goal is not to replace security teams, but to give developers fast, actionable feedback about vulnerabilities while the code is still fresh in their minds. A well-designed DevSecOps pipeline catches critical issues before they reach production, reduces remediation costs by 10–100x compared to post-deployment fixes, and maintains development velocity.
Why DevSecOps Matters in 2026
of breaches involve a human element or misconfiguration that automated scanning would have caught
more expensive to fix a vulnerability in production vs. during development
average cost of a data breach in 2025, up 15% over three years
Modern applications depend on hundreds of open-source packages, deploy to multi-cloud infrastructure, and ship multiple times per day. Manual security reviews cannot keep pace. DevSecOps pipelines automate the repetitive scanning work, surface only actionable findings, and enforce security policies as code.
Building the Pipeline: 6 Security Stages
A comprehensive DevSecOps pipeline integrates security at six key stages. Each stage catches a different class of vulnerability, and together they provide defense in depth from code to cloud.
Stage 1: Pre-Commit: Secret Scanning
Scan for hardcoded secrets, API keys, and credentials before code is committed. Use git pre-commit hooks to prevent secrets from entering version control.
Stage 2: SAST: Static Application Security Testing
Analyze source code for security vulnerabilities like SQL injection, XSS, and command injection. Runs on every pull request and blocks merges for critical findings.
Stage 3: SCA: Software Composition Analysis
Scan open-source dependencies for known CVEs, license violations, and malicious packages. Generate SBOM for supply chain visibility.
Stage 4: Container & IaC Scanning
Scan container images for OS and application vulnerabilities. Check Terraform, CloudFormation, and Kubernetes manifests for misconfigurations before deployment.
Stage 5: DAST: Dynamic Application Security Testing
Test the running application for vulnerabilities by sending crafted requests. Catches issues that static analysis misses, like authentication bypass and business logic flaws.
Stage 6: Runtime Monitoring & Enforcement
Monitor production workloads for anomalous behavior, privilege escalation, and network anomalies using eBPF. Enforce security policies at the kernel level.
Pipeline Integration: What to Run Where
Not every scan needs to run at every stage. The key is balancing thoroughness with speed — fast scans on every commit, deeper scans on pull requests, and comprehensive scans before deployment.
| Scan Type | Pre-Commit | PR / MR | Main Branch | Pre-Deploy |
|---|---|---|---|---|
| Secret Scanning | Yes | Yes | Yes | — |
| SAST | — | Yes (diff only) | Full scan | — |
| SCA | — | Yes | Yes | — |
| IaC Scanning | — | Yes | Yes | Yes |
| Container Scan | — | — | Yes | Yes (gate) |
| DAST | — | — | — | Yes (staging) |
| Runtime Monitoring | — | — | — | Continuous |
Common DevSecOps Pitfalls
Alert Fatigue
Surfacing every low-severity finding on every PR burns developer trust. Start with critical and high severity only. Tune rules over time.
Blocking Without Context
A hard gate that fails the build with no remediation guidance frustrates developers. Always provide fix suggestions and documentation links.
Scanning Too Late
Running security scans only before deployment means developers discover issues days after writing the code. Shift scans to the PR stage.
Ignoring Runtime
Pre-deployment scanning cannot catch zero-day exploits, misuse of stolen credentials, or configuration drift. Runtime monitoring completes the picture.
Designing Security Gates That Developers Accept
The difference between a DevSecOps pipeline that sticks and one that gets bypassed is gate design. A gate is a policy decision — under what conditions does the pipeline stop a change? Get it wrong in either direction and you lose: gates that block on every medium-severity finding teach developers to route around security, while purely advisory gates teach them to ignore it. The proven pattern is graduated enforcement.
Block Only on New, Critical, Reachable Issues
Gate on findings introduced by the change itself (diff-aware scanning), at critical or high severity, with evidence of exploitability — a reachable code path or a known exploited CVE. Pre-existing backlog issues belong in a tracked remediation queue, not in someone else's pull request.
Give Every Block an Escape Hatch
Real deadlines exist. Allow documented, time-boxed exceptions with a required approver and an automatic expiry that reopens the finding. An auditable override is far safer than developers force-merging around a broken check.
Express Policy as Code
Keep gate thresholds in version-controlled policy files (OPA/Rego, or your platform's policy DSL) rather than per-repo CI configuration. Policy changes then go through review like any other code, and every repository inherits updates without pipeline edits.
Set a Latency Budget
PR-stage checks should complete in under five minutes; anything slower migrates to merge or nightly scans. Diff-aware SAST, cached dependency databases, and parallel scan execution keep the budget honest — a slow gate is a disabled gate within a quarter.
Roll gates out in audit mode first: run the scan, post the results, block nothing. After two to four weeks of tuning false positives, flip criticals to blocking, then highs. This sequencing builds the trust that makes enforcement politically possible.
Securing the Pipeline Itself: Supply Chain Hardening
A DevSecOps pipeline scans your software — but the pipeline is itself software, and attackers know it. SolarWinds, Codecov, and the 2025 wave of compromised GitHub Actions all followed the same logic: subvert the build system and you inherit the trust of everything it ships. Frameworks like SLSA (Supply-chain Levels for Software Artifacts) formalize the defenses, and most of them are practical for ordinary teams today.
Treat these as pipeline stages too: SBOM generation and image signing slot naturally into the container build step, and signature verification becomes one more pre-deploy gate.
Measuring Your DevSecOps Pipeline
You cannot tune what you do not measure. Raw finding counts are a vanity metric — they reward scanning more, not securing more. The metrics that actually predict risk reduction measure flow: how fast vulnerabilities move from introduction to remediation, and how little the pipeline costs developers along the way.
Mean Time to Remediate (MTTR)
Days from first detection to verified fix, segmented by severity. Critical findings should trend toward days, not months. This is the single best health indicator for the whole program.
Escape Rate
Vulnerabilities found in production (by DAST, runtime monitoring, pentests, or bug bounty) that a pipeline stage should have caught earlier. Every escape is a tuning signal for a specific gate.
Pipeline Latency Added
Median seconds security checks add to a PR build. Track it like a performance SLO — when it creeps past your budget, invest in diff-aware scanning and caching before developers revolt.
False Positive Rate
Percentage of findings triaged as not-an-issue. Above roughly 20%, developers stop reading results. Measure per rule and disable or rewrite the worst offenders.
Coverage
Percentage of repositories, images, and cloud accounts actually onboarded to each scan type. A pristine pipeline covering 40% of services is a false sense of security.
Gate Override Frequency
How often exceptions are used and by whom. Rising overrides signal either miscalibrated thresholds or deadline pressure worth surfacing to leadership.
A unified platform makes these metrics cheap to compute because findings from every stage share one data model — TigerGate, for example, reports MTTR and coverage across SAST, SCA, container, cloud, and runtime findings from a single dashboard rather than six exported CSVs.
A 90-Day Rollout Plan
Teams that try to enable all six stages simultaneously across every repository usually stall in tuning purgatory. A phased rollout gets to durable coverage faster:
Days 1–15: Secrets and Baseline
Enable secret scanning everywhere immediately — it has near-zero false positives and the highest payoff per hour invested. In parallel, run SAST and SCA in report-only mode on your three most critical services to build a finding baseline.
Days 16–45: PR Feedback Loop
Turn on diff-aware SAST and SCA comments on pull requests for the pilot services. Triage the baseline backlog into a tracked queue with owners and SLAs. Tune the noisiest rules before expanding scope.
Days 46–70: Gates and Containers
Flip critical-severity findings to blocking on pilot repos, add container and IaC scanning to image builds, and expand PR scanning to the wider repository fleet in report-only mode.
Days 71–90: Runtime and Review
Deploy runtime monitoring agents to one production cluster in audit mode, add DAST against staging on a nightly schedule, and hold a retrospective: review MTTR, false positive rate, and latency budget, then set thresholds for the next quarter's expansion.
Frequently Asked Questions
Should security checks block the build or just warn?
Both, staged by severity and age. New critical findings introduced by the change should block; new highs should block after a tuning period; everything else should be visible but non-blocking, flowing into a remediation queue with SLAs. Blocking on pre-existing backlog issues in unrelated PRs is the fastest way to lose developer support.
Where should we start if we have no security tooling at all?
Secret scanning first — it is fast, accurate, and a leaked credential is the most directly exploitable finding class. SCA second, because dependency CVEs are abundant and fixes are usually just version bumps. SAST third, once you have the triage muscle to handle findings that require code changes.
How is DevSecOps different from just running scanners in CI?
Scanners in CI are the mechanism; DevSecOps is the operating model around them: findings routed to owners with SLAs, policy expressed as reviewable code, metrics that track remediation flow, and runtime feedback that tells you which pre-deployment gates are leaking. A scanner without a remediation loop just produces reports.
Do we still need penetration tests with a full pipeline?
Yes. Automated stages catch known vulnerability classes at scale, but business logic flaws, authorization design errors, and chained attacks still need human creativity. The pipeline makes pentests more valuable — testers skip the low-hanging fruit and spend their time on what automation cannot find.
Build Your DevSecOps Pipeline with TigerGate
TigerGate unifies SAST, SCA, container scanning, DAST, cloud security, and eBPF runtime monitoring in a single platform. One integration, full pipeline coverage.