DevSecOps in 2026: Security Teams Now Sit in Sprint Planning—Is This Progress or Process Bloat?

General
1

Our security team started joining sprint planning six months ago. The good news: we’re catching issues earlier. The weird news: our meetings ballooned from 45 minutes to 90 minutes, and I’m hearing grumbles about “security theater” from my developers.

I lead engineering at a high-growth EdTech startup. We bought into the DevSecOps vision—security as everyone’s responsibility, not a gate at the end. By 2026, that vision has become concrete: security engineers physically sitting in our sprint planning, stand-ups, and retrospectives.

The Progress We’ve Made

I’ll be honest—there are real wins:

  • Catching misconfigurations early: We used to waste 2-3 days per sprint on security rework when issues surfaced in staging. Now we catch them during planning.
  • Better context for security decisions: Our security team understands product context and can make smarter trade-off decisions instead of blanket “no.”
  • Prevented real incidents: Threat modeling during planning has stopped 3 major security issues we can clearly identify (and probably more we’ll never know about).

The shift-left promise is real when it works. Security folks who understand our goals can be incredible partners.

The Bloat We’re Seeing

But here’s what’s got me concerned:

  • Security criteria for everything: Every user story now needs “security acceptance criteria”—even minor UI tweaks. It feels like box-checking, not risk management.
  • We kept the old gates: We still have our pre-production security review. So we didn’t replace the waterfall security process—we added agile security on top of it. Double the overhead.
  • Developer sentiment: My engineers feel like they’re being watched, not supported. The energy has shifted from collaboration to compliance.
  • Unmeasurable impact: A 2026 Forrester study found that 55% of companies can’t quantify the impact of their shift-left efforts. We’re in that camp.

The Paradox Nobody Talks About

Here’s what keeps me up at night: we measure developers on shipping features, not on security.

When my engineers have limited learning time each week, security has to compete with:

  • New AI coding tools that make them faster
  • Evolving frameworks they need for their jobs
  • The languages and techniques that directly impact their performance reviews

Security loses that competition every time. We’re asking people to care deeply about something we don’t actually reward them for.

Is “shift left” actually shifting responsibility without shifting incentives?

My Questions for This Community

  1. Has your org integrated security into agile ceremonies? Did it improve outcomes or just add process overhead?

  2. How do you balance shift-left with developer velocity? Have you found a way to make security feel like an enabler instead of a tax?

  3. Did you deprecate old security gates? Or did you also end up with double the process?

  4. How do you measure DevSecOps success? If we can’t quantify impact, how do we know we’re building better vs. just having more meetings?

I believe in DevSecOps principles. I just want to make sure we’re implementing them in a way that genuinely improves security outcomes without burning out our teams.

What’s working for you?

Cross-posted from a discussion at my leadership team. Would love to hear from other engineering leaders, security practitioners, and anyone who’s navigated this shift.

2

The measurement problem you mentioned is absolutely real—we can’t tell if our DevSecOps investments are actually working.

At our FinTech company, we added security tools to our CI/CD pipeline 18 months ago. We have dashboards showing “vulnerabilities blocked” and “security issues caught,” but here’s the thing: we can’t prove any of those issues would have actually reached production anyway.

Are we catching real problems or just creating metrics that make us feel productive?

The Hidden Cost of Process Debt

Here’s what really resonates with your post: we kept our legacy Change Approval Board (CAB) process “just in case.” Management wasn’t comfortable removing the manual security sign-off, even with automated scans in place.

So now we have:

  • Automated security scans in CI/CD (shift left)
  • Manual security review before production (old waterfall gate)

Double the gates, unclear if we’re actually safer. And just like you described—every security finding still requires manual CAB approval, creating bottlenecks. The tool’s value is negated by our process debt—outdated workflows that assume security happens at the end of the pipeline.

The Question Nobody Can Answer

In financial services, we’re particularly risk-averse. But even with our regulatory requirements, I wonder: has anyone successfully deprecated old security gates while adding shift-left practices?

How did you build confidence to remove the manual checkpoints? What would convince a risk committee that automated gates are sufficient?

Because right now, we’re paying for DevSecOps transformation but keeping all our old processes. That’s not transformation—that’s just accumulation.

3

We went a different direction, and I’m curious if it’s scalable beyond our specific context.

Instead of asking developers to think about security at every step, we made insecure deployments technologically impossible.

The Platform Engineering Approach

Our platform team spent 8 months building what we call “golden paths”—hardened service templates with security baked in:

  • Policy-as-Code: Infrastructure-level enforcement. You literally can’t deploy a service that violates our security policies.
  • Auto-injected security controls: TLS, secrets management, RBAC configurations—all automatically applied to every service.
  • Pre-configured compliance: SOC2 and ISO requirements enforced at the infrastructure layer, not through manual audits.

What This Looks Like in Practice

Developers interact with our internal platform, not raw Kubernetes or cloud APIs. When they scaffold a new service, it comes with:

  • Secure-by-default configurations
  • Required security controls already applied
  • Guardrails that prevent common vulnerabilities

The security team focuses on building the platform, not reviewing every deployment. We review platform changes, not individual service deploys.

The Results

  • Developers can’t accidentally deploy insecure services (it’s blocked at the infrastructure layer)
  • Security team isn’t a bottleneck for every release
  • Compliance becomes automatic, not aspirational
  • We’ve seen zero production security incidents related to misconfigurations in 14 months

The Catch

This required:

  • Dedicated platform engineering team (we have 8 people)
  • 8-month initial build time before we could enforce it
  • Significant upfront investment that our CFO questioned multiple times
  • We still need security champions for edge cases and architectural reviews

And honestly, 2026 trends suggest platform engineering will fundamentally change how compliance is enforced. But this doesn’t eliminate the need for security expertise—it just changes where expertise sits.

My Question to the Group

Is this approach accessible for teams without dedicated platform engineering orgs?

Or is this only viable at scale? Can a 30-person engineering team build these kinds of guardrails, or does this require platform engineering as a separate function?

Luis—your point about process debt resonates. We essentially deprecated manual security reviews by making them unnecessary. But it took significant architectural investment to get there.

4

Coming at this from the design side, and I work closely enough with engineers to have strong opinions about the security-in-sprints experience.

The Good: Early Involvement Actually Helps Design

Our security team joining design reviews has been genuinely valuable. They help me think through:

  • Auth flows and permission models before we build UI
  • Data privacy considerations during wireframing
  • GDPR and compliance implications before we commit to features

We caught a major GDPR issue during design phase—would’ve been a nightmare to retrofit after implementation. So early security input = real value.

The Friction: Checklists That Feel Like Theater

But here’s where it gets weird: every design review now has a security checklist. Some questions matter:

  • “Where does this user data go?”
  • “Who can access this information?”
  • “How do we handle deletion requests?”

Some feel like box-checking:

  • “Did you document the threat model?”
  • “Have you completed the security impact assessment form?”

When the checklist becomes more important than the conversation, we’ve lost the plot.

What Developers Are Actually Feeling

The engineers I work with describe security involvement as something being done to them, not with them.

The “shift left” idea was supposed to make security collaborative—developers and security working together earlier. But the implementation often feels like surveillance:

Michelle’s platform engineering approach is interesting because it shifts the model: instead of reviewing every decision, you make the wrong decision impossible.

A Suggestion: Async for Low-Risk, Real-Time for High-Risk

What if security teams:

  • Built tools and guardrails (like Michelle’s golden paths)
  • Did async reviews for low-risk changes (UI tweaks, copy changes)
  • Paired in real-time for high-risk stuff (auth, payments, data handling)

The best DevSecOps orgs I’ve seen treat security like design systems—infrastructure that makes the right thing easy, not gatekeepers who approve every decision.

My Question

How do we make security feel like an enabler, not a blocker?

Because right now, a lot of developers see security folks as people who slow them down, not people who help them ship safely. And that’s a culture problem, not a technical one.

5

From a product strategy perspective, this thread is fascinating—security is becoming a first-class feature, not just risk management.

Security as Competitive Differentiation

Our enterprise customers now ask about DevSecOps maturity in sales calls. Not just “are you SOC2 compliant?” but “what’s your security SDLC? How do you handle vulnerability management?”

Security posture is literally part of competitive differentiation in B2B SaaS. Companies with mature DevSecOps can close deals that less mature competitors lose.

The Product Trade-Off

But here’s the tension: every sprint hour spent on security is an hour not spent on features. And product velocity is also how we win deals.

A security incident definitely costs us deals (one ransomware attack and we’d be done). But so does shipping slower than competitors.

How do we balance these when they compete for the same engineering capacity?

What I’ve Seen Work: Security as Product Requirements

The teams that handle this best treat security requirements like any other product requirement:

  • Prioritized in the backlog alongside features
  • Estimated in story points
  • Measured in sprint velocity
  • Part of definition of done, not separate overhead

The teams that struggle add security as overhead—“build the feature, PLUS security review, PLUS penetration testing.” That’s why it feels like bloat.

The Business Case Problem

Keisha mentioned that 55% of companies can’t quantify DevSecOps impact. This is a huge problem for product leaders.

When CFOs are already deferring 25% of AI investments to 2027, how do we justify DevSecOps spending if we can’t measure ROI?

Michelle’s platform engineering approach is compelling because it has clear metrics:

  • Zero production security incidents in 14 months
  • Reduced manual security review bottlenecks
  • Faster time-to-production (no security gate delays)

Those are numbers that resonate with executives.

My Questions

  1. Has anyone built a business case for DevSecOps that resonated with non-technical executives? What metrics actually moved the needle?

  2. How do you prioritize security work against feature work? Do you allocate a percentage of sprint capacity? Treat security as tech debt? Something else?

  3. Maya’s point about security as enabler vs blocker—has anyone successfully reframed security this way with their team? What changed?

This is one of those cross-functional challenges where engineering, security, and product need to be tightly aligned. But the incentives aren’t aligned by default, which creates the friction we’re all describing.