This article summarises key takeaways from an episode of the Continuous Discussions (#c9d9) podcast, originally published on DevOps.com. The panel included Alan Shimel (Editor in Chief, DevOps.com), Chenxi Wang (Managing General Partner, Rain Capital), Derek E. Weeks (VP and DevOps Advocate, Sonatype), Paula Thrasher (Chief Architect, National Security Division, GDIT), Geetika Tandon (Director of Technology, Federal Civilian CTO Group), and Electric Cloud’s Sam Fell and Anders Wallgren.
Why DevSecOps?
DevSecOps is often dismissed as a rebranding exercise, but practitioners on the panel were clear: the distinction exists because security was systematically left out of early DevOps transformations. Understanding why the term matters is the first step toward making it real.
Security Is a Cultural Problem First
Alan Shimel framed DevSecOps as an extension of the broader DevOps cultural shift rather than a separate discipline:
“DevOps is DevOps. It’s not just about Dev and Ops, though. DevOps is about the whole organisation adapting a common cultural way of interacting—including security—and bringing security into that culture, into that software delivery assembly line.”
Alan Shimel, DevOps.com
Paula Thrasher echoed this, arguing that the “DevSecOps” label exists precisely because security teams were excluded from DevOps transformations to begin with:
“I think ‘DevSecOps’ exists because either we’ve left security out or they’ve stayed outside this transformation that’s happening.”
Paula Thrasher, GDIT
The Speed Mismatch Between Security and Development
One of the most persistent friction points is the mismatch between traditional security review cycles and modern release cadences. Chenxi Wang described the challenge bluntly:
“When you have a security testing process that takes days to complete from input to output, and you have developer teams releasing 500 releases a day, those are two very different cultures. It’s usually an iterative process, but it takes a lot of team communication—a lot of sitting down, figuring things out—for security to be part of it.”
Chenxi Wang, Rain Capital
Geetika Tandon made the same point from an operational angle, questioning why a practice as fundamental as security scanning was ever treated as an afterthought in continuous delivery pipelines:
“I don’t even understand how security has been left out. I don’t understand how we have these huge pipelines, we’re releasing a hundred code releases a day, and then, boom, we’re stopped for scanning.”
Geetika Tandon, Federal Civilian CTO Group
Security and Quality Are the Same Thing
Anders Wallgren offered a longer-term vision: collapsing the distinction between security and quality entirely.
“I long for the day when we don’t distinguish between security and quality because, yes, there are different disciplines to them in some extent, but as far as the end user is concerned a bug is a bug.”
Anders Wallgren, Electric Cloud
Derek Weeks reinforced that DevSecOps is demonstrably real and scaling across organisations of all sizes:
“DevOps and security can integrate with each other and integrate successfully at scale. There are organisations of a couple of hundred or even a couple of thousand people that have a DevSecOps practice in place and are continuously improving it, adding automated security—so it’s definitely gone beyond buzzword status.”
Derek E. Weeks, Sonatype
Common Barriers to DevSecOps Adoption
Alert Fatigue and Ignored Findings
One of the most damaging failure modes is treating security scanning as a checkbox exercise. Tandon described a scenario many practitioners will recognise:
“I’ve seen a situation where we were about to go to production—it was DevOps with security toward the end—and we got 4,000 hits and we had to go to production; most of them were ignored. So are we really securing our system, or are we making it even more insecure by doing that?”
Geetika Tandon, Federal Civilian CTO Group
Bolting security onto the end of a pipeline—rather than integrating it earlier—leads to exactly this outcome: a flood of findings that cannot be actioned before a release deadline, so they are dismissed wholesale.
Developers and Ops Teams Are Not Trained to Respond to Security Incidents
Thrasher highlighted an underappreciated readiness gap: security teams know how to respond to vulnerabilities, but the developers and operators who own the systems often do not.
“The people that need to practice responding to vulnerabilities the most actually aren’t the security people—they’re used to responding to security issues. It’s the ops and the developers who aren’t used to responding to security incidents and aren’t equipped or trained on how to respond. So when your vulnerability happens, it’s a bad-news story.”
Paula Thrasher, GDIT
Building incident-response runbooks, conducting game days, and including security scenarios in on-call rotations are practical ways to close this gap.
Most Exploits Target Known, Long-Standing Vulnerabilities
Wallgren noted that the majority of real-world exploits do not rely on novel zero-days—they target well-documented, long-standing vulnerabilities that organisations have simply failed to patch.
“Where are most of the exploits coming from? The vast majority, as I understand it, are coming from well-known, longstanding security issues that have been out there for a long time—at least long by technology standards. A lot of it is just simple stuff that we need to be better at.”
Anders Wallgren, Electric Cloud
This suggests that disciplined dependency management—keeping libraries, base images, and system packages up to date—delivers outsized security value relative to its effort.
Patterns for DevSecOps Success
Automate the Gate: The Bronze/Gold Registry Pattern
Wang described a concrete automation pattern used by a container-focused organisation to enforce security gates without slowing developers down:
“They have what they call a Bronze registry. Code assembled by the development team goes into the Bronze registry. No other code can get into the Bronze registry unless it’s from their own team. Then from that Bronze registry the security team automatically goes in and scans it, and only those that pass the scan get put into what they call a Gold registry. From there they can deploy to the server.”
Chenxi Wang, Rain Capital
This pattern enforces a clean separation of concerns:
- Bronze registry — developer-owned; unvalidated artefacts only.
- Automated scan — triggered by promotion into Bronze; no human bottleneck.
- Gold registry — security-approved artefacts only; the only source from which production deployments are permitted.
The approach maps well to supply-chain security requirements and is consistent with concepts like trusted build pipelines and artefact signing.
Encode Policy as Code, Not as Documentation
Weeks identified a critical maturity gap in many organisations: security rules exist, but only as written policies that developers are expected to follow manually rather than as automated enforcement in the pipeline.
“I said, ‘That’s really cool. Any of those rules or policies instrumented as code?’ And he responded cross-eyed: ‘What? Code?'”
Derek E. Weeks, Sonatype
Security as code means expressing compliance requirements, vulnerability thresholds, and approved dependency lists as machine-readable policy that the CI/CD pipeline can evaluate automatically—failing a build the moment a violation is detected rather than discovering it in a quarterly audit. Tools in this space include Open Policy Agent (OPA), HashiCorp Sentinel, and native policy features in platforms such as GitHub Actions and GitLab CI.
Incremental Progress Over Perfection
Shimel cautioned against letting the scale of the problem become an excuse for inaction:
“We’re not going to boil the ocean or change the world in a day, but we will change the world and we will change the way software is delivered so that software and security is synonymous with quality.”
Alan Shimel, DevOps.com
Practical starting points for teams beginning their DevSecOps journey include:
- Shift dependency scanning left — add software composition analysis (SCA) to pull-request checks so developers see vulnerable dependencies before code is merged.
- Define a minimal viable policy — agree on a short list of high-severity rules that will automatically fail a build; resist the urge to enable everything at once.
- Run security incident drills — include developers and ops staff, not just the security team.
- Promote security champions — embed at least one security-aware engineer in each product team to act as a liaison to the security organisation.
- Review and tighten gates iteratively — once teams are comfortable with the first policy set, expand scope and lower acceptable thresholds over successive quarters.
Summary
The core message from this panel is straightforward: DevSecOps is not a product category or a job title—it is the outcome of deliberately embedding security thinking, tooling, and responsibility throughout the entire software delivery lifecycle. The cultural and organisational barriers are real, but so are proven patterns for overcoming them. Starting small, automating gates, encoding policy as code, and training the whole team—not just security specialists—to respond to incidents are concrete steps any organisation can take today.
Original episode: Continuous Discussions (#c9d9) podcast, via DevOps.com.