This article is based on a perspective piece originally published on csoonline.com, drawing on experiences from the ATARC DevOps Summit and related industry discussions.
A Community Divided: Should Security Be in the DevOps Name?
At the Advanced Technology Academic Research Center (ATARC) DevOps Summit, Tom Suder — President of ATARC — posed an informal question to an audience of more than 200 federal, commercial, and public-sector participants: should security be formally incorporated into the DevOps name?
The responses illustrated a genuine fault line in the community. One group argued strongly that security is now so fundamental to software delivery that it must be embedded in how we label and think about the discipline. Another group pushed back equally hard, contending that DevOps is fundamentally a cultural movement centered on automation and breaking down silos — and that grafting a security label onto it risks reducing a broad philosophy to a narrower compliance exercise. A third thread suggested DevOps itself should be folded into the wider discipline of change management.
None of those positions is obviously wrong, which is what makes the debate worth having.
DevSecOps vs SecDevOps: What’s in a Name?
Two competing terms have emerged as shorthand for security-integrated DevOps:
- DevSecOps — places security between Dev and Ops, implying it is layered into an existing Dev→Ops pipeline.
- SecDevOps — places security first, conveying a Security First mindset in which security is a foundational concern before a single line of code is written or a pipeline stage is designed.
Advocates of the SecDevOps framing argue that positioning security at the front of the acronym reflects a genuinely proactive posture — security requirements inform architecture decisions, threat modelling happens before sprint planning, and compliance gates are designed into the pipeline rather than bolted on at the end. Critics of both terms argue that the naming debate is largely cosmetic and that the real question is implementation: where exactly does security sit in your CI/CD pipeline, and who owns it?
Gene Kim, author of The Phoenix Project, has continued to explore DevOps evolution in his subsequent work. Adrian Cockcroft and other practitioners have demonstrated how large organisations can transform their delivery pipelines using cloud, microservices, and automation. These voices share a common theme: DevOps culture is a continuous evolution, not a fixed destination.
Why Security Can No Longer Be a Bolt-On
The pressure to integrate security into DevOps pipelines is no longer theoretical. Several converging forces are driving this:
- Rising breach frequency and impact — high-profile incidents have demonstrated the cost of discovering vulnerabilities late in the delivery cycle.
- Growing compliance obligations — frameworks such as NIST SP 800-171, the Department of Defense DFARS clause 252.204-7012, and GDPR impose specific requirements on how organisations protect and handle data. Non-compliance carries financial and reputational penalties.
- The shift-left principle — fixing a defect in production is significantly more expensive than catching it during code review or in a pre-deployment scan. The same economics apply to security vulnerabilities.
Treating security as a final-stage gate — a single penetration test before go-live — is no longer operationally viable at the delivery cadences modern DevOps pipelines require.
Security Practices That Belong Inside the CI/CD Pipeline
A mature SecDevOps or DevSecOps implementation embeds discrete security activities at multiple stages of the pipeline rather than treating security as a single checkpoint. Common examples include:
Static Application Security Testing (SAST)
SAST tools analyse source code or compiled binaries without executing the application. They catch common vulnerability classes — injection flaws, insecure deserialization, hardcoded credentials — early in the build process. Both open-source and commercial tools exist in this space (examples cited in the original source include Yasca and Checkmarx).
Dynamic Application Security Testing (DAST)
DAST tools interact with a running application to find vulnerabilities that only manifest at runtime — authentication bypass, session management flaws, injection vulnerabilities exposed through the HTTP layer. Solutions such as Veracode are used in this category.
Vulnerability and Infrastructure Scanning
Tools such as Nessus scan hosts, containers, and network configurations for known CVEs and misconfigurations. In a containerised environment, this extends to scanning Docker images before they are pushed to a registry or deployed.
Fuzz Testing
Fuzzing feeds malformed, unexpected, or random input to an application to surface non-obvious defects — edge cases that structured test suites rarely exercise. It is particularly valuable for APIs, parsers, and any component that processes external input.
Automated Compliance Reporting
Rather than producing compliance evidence manually at audit time, automated tooling can continuously generate artefacts — scan reports, configuration baselines, access-control snapshots — that satisfy requirements under HIPAA, FedRAMP, GDPR, and NIST frameworks. This reduces compliance cost and provides a real-time view of posture rather than a point-in-time snapshot.
Integrating the CISO Function Into the Delivery Pipeline
The SecDevOps philosophy extends beyond tooling. It calls for the Chief Information Security Officer (CISO) function to be represented as a genuine stakeholder in the development pipeline — not an external auditor who reviews deliverables at the end, but a participant in architectural decisions, threat modelling sessions, and pipeline design.
When security teams are isolated from delivery teams, security feedback arrives too late to be acted on cheaply, and developers have no mechanism to build security intuition over time. Embedding security engineers within delivery squads — or at minimum creating structured touchpoints between security and engineering at each pipeline stage — addresses both problems.
What Comes After DevOps? Serverless and Low-Code Platforms
Two technology categories are already pushing the boundaries of what DevOps means in practice:
Serverless Computing
Serverless platforms (AWS Lambda, Azure Functions, Google Cloud Functions) abstract away infrastructure management entirely. Developers deploy functions rather than servers. This changes the DevOps operational model: there is no OS to patch, no server to provision, but there are new attack surfaces — function permissions, event-source injection, dependency supply chains — that security tooling must adapt to cover.
Low-Code Platforms
Low-code platforms (examples cited in the original source include Mendix and OutSystems) allow business analysts and domain experts to build and deploy applications using visual, component-based tools rather than hand-written code. Just as Docker containers raised the abstraction level above raw VMs to enable microservices, low-code platforms raise it above individual lines of code to enable a larger community of contributors to participate in software delivery.
This has meaningful implications for DevSecOps: when the people creating applications are not traditional developers, the security controls that relied on code review, linting, and SAST need to be reconsidered. Security must move further upstream — into the platform itself, its default configurations, and its approved component library.
Key Takeaways
- The naming debate between DevSecOps and SecDevOps matters less than where security actually sits in your pipeline and who owns it.
- Compliance pressure (NIST 800-171, DFARS, GDPR, FedRAMP, HIPAA) is a practical forcing function for embedding security into CI/CD pipelines, not just a philosophical choice.
- Effective integration combines tooling (SAST, DAST, vulnerability scanning, fuzzing) with organisational change (CISO involvement, shared responsibility, automated compliance evidence).
- Serverless and low-code platforms are already requiring the DevOps community to rethink what security integration means when infrastructure and code are increasingly abstracted away.
- The goal in any framing — DevSecOps, SecDevOps, or DevOps NG — is the same: make security a fast, automated, and continuous part of delivery rather than a slow, manual gate that is applied too late to be cost-effective.