This article is based on reporting originally published by TechTarget (techtarget.com).
Why Security Keeps Getting Skipped in DevOps
DevOps has reshaped how software is built and delivered, reducing costs, accelerating deployments, and improving organizational agility. Yet that same speed has been cited as a contributing factor in high-profile security breaches—when teams move fast, security reviews are the first thing cut.
“DevOps teams that deploy software are responsible for maintaining security by design,” said Craig Lurey, CTO and co-founder of Keeper Security. In practice, though, security is too often bolted on at the last moment—or skipped entirely until an incident forces the issue.
The response to this pattern is SecDevOps (also written as DevSecOps or DevOpsSec, each implying a slightly different philosophical emphasis): the practice of building security controls into every phase of the software development lifecycle rather than treating them as a post-deployment concern.
What SecDevOps Actually Means—and Why Naming Matters
The terminology is still contested. SecDevOps, DevSecOps, and DevOpsSec each imply a different answer to the question: at what point does security take ownership? Former McAfee CTO Jamie Tischart captured the difficulty wryly: “Maybe what we need is SecDevSecOpsSec. Here, security is a continuous activity in itself that needs to be incorporated into all stages of the product lifecycle.”
Regardless of what you call it, the underlying goal is the same: make security a first-class, continuous concern—not a gate at the end of the pipeline.
According to Konstantin Rychkov, an analyst at IDC, organizations that have embedded security into their product delivery systems include Adobe, Amazon, Etsy, General Electric, Google, Facebook, Fidelity, Intuit, Home Depot, Netflix, and Nordstrom. Even so, he noted, genuinely successful SecDevOps implementations remain relatively rare.
How Teams Are Integrating Security Today
J. Wolfgang Goerlich, cybersecurity strategist at Creative Breakthroughs Inc., observed two common structural patterns among teams that have made progress:
- Embedded security architects — A dedicated security professional sits within the DevOps team and participates in daily work.
- Security champions — A developer or engineer within the DevOps team is designated as the bridge to the security organization, carrying security requirements back into sprint planning and code review.
“In both cases, the partnership is a means to introduce security concepts while maintaining DevOps velocity,” Goerlich said.
Goerlich estimated that roughly one in four DevOps teams automate some level of security controls—typically static code analysis, application-layer scanning, and infrastructure composition checks. The challenge is keeping those automated checks fast enough to be useful. Traditional static analysis scans can take days to complete. “That’s not effective when DevOps is changing the code on a daily or even hourly basis,” he said.
Effective SecDevOps, in Goerlich’s framing, is “paradoxically fast and slow”—security controls are introduced incrementally and carefully, but once in place they execute very quickly so they don’t block the pipeline.
Two Main Approaches to IT Application Security
1. Security by Design
Security by design means continuously checking code in development environments to minimize attack surfaces and close protection gaps before software ever reaches production. Rychkov describes it with a concrete analogy: DevOps is like wet cement, and SecDevOps is like concrete—cement mixed with additional aggregates to make it stronger. “The moment wet cement gets dry, you’ll need to break it to add aggregates,” he said. Trying to retrofit security into an already-settled DevOps process is similarly disruptive and expensive.
This is why Rychkov argues that transitioning an existing DevOps organization to SecDevOps takes roughly twice as long as building a SecDevOps culture from scratch. Three areas must align simultaneously: culture, process, and tools. Missing any one of them undermines the others.
2. Runtime Application Self-Protection (RASP)
The second approach, RASP, inserts security logic directly into a running application so it can detect and block attacks at runtime without requiring changes to the surrounding DevOps process. Rychkov describes it as “a cheat that DevOps [teams] can use when the will to collaborate is missing.”
RASP is typically delivered by third-party vendors whose code is injected into the application at deployment time. However, Rychkov identifies three significant drawbacks:
- Long-term sustainability risk. Relying on a third-party vendor to keep pace with the speed of attacks introduces dependency risk. Liability for a breach stays with the organization, not the vendor.
- Performance overhead. RASP adds processing to every request path. If the instrumentation hooks are poorly chosen, the impact on user experience can be significant.
- Integration gaps. Hooks must cover every relevant execution path. A single missed gap can leave the application exposed.
“In the end, the best place to begin is the beginning—when there is no solid DevOps structure,” Rychkov concluded.
Security Is a Priority—Sometimes
Ben Rockwood, then director of IT and operations at Chef Software, offered a blunter assessment: SecDevOps isn’t working. In most organizations, security practices rather than security people were nominally built into the process—but under the pressure of feature deadlines and delivery targets, those practices get quietly sidelined.
“Most companies aren’t really investing in security, and they are trying to pepper it around. SecDevOps sounds like a movement; it gives them cover for their bad behavior,” Rockwood said.
Testing, Prioritization, and the Red Team Mindset
Rychkov argued that holistic testing is one of the most important levers available—but it requires a change in how security teams think about their role inside a CI/CD cycle.
Red teams—those responsible for adversarial testing and challenge—cannot expect to find and fix every vulnerability within a single pipeline iteration. Instead, they must accept prioritization: address the most critical, fixable issues in the current cycle, then carry the rest forward into a structured remediation backlog for future cycles.
“This way of thinking can be beneficial for security specialists, even outside of SecDevOps boundaries,” Rychkov said.
Compliance as a SecDevOps Driver
One area where a SecDevOps approach delivers clear, measurable value is regulatory compliance. Rychkov highlighted the EU’s General Data Protection Regulation (GDPR), which explicitly enshrines the concept of “data protection by design and by default.” For global enterprises subject to GDPR, SecDevOps is not just a best practice—it is an architectural requirement.
The Cultural Shift Is the Hard Part
Ultimately, Rychkov argued, process and tooling changes are not sufficient on their own. The security team’s mindset must evolve alongside them—moving from an absolutist stance (“everything must be perfectly secure before it ships”) to a relativist one (“we improve security continuously, accepting managed risk in each cycle”).
“That’s a journey from absolutism to relativism—the most painful one for a security team,” he said.
Success in SecDevOps comes from balancing two things simultaneously: protecting the product the DevOps team is building, and protecting the productivity of the team building it.
Original reporting: TechTarget. This article summarizes and expands on the source material for a DevOps engineering audience.