This article draws on a panel discussion featuring Ilkka Turunen (Head of Solutions Architecture, Sonatype), Zane Lackey (Founder, Signal Sciences), and Margo Cronin (Senior Solution Architect, Amazon Web Services) at the DevOps Enterprise Summit 2018 (DOES18) in London. The original source was published on devops.com.
From DevOps to DevSecOps: A Decade of Evolution
The DevOps methodology has roots stretching back to roughly 2009, when Patrick Debois coined the term by naming a Belgian software conference “devopsdays.” In the years since, DevOps has become the dominant engineering culture for organizations seeking to accelerate delivery and improve product quality. As the practice matured, a natural—and necessary—evolution emerged: DevSecOps, the intentional integration of security practices throughout the entire DevOps lifecycle.
Rather than treating security as a gate at the end of the pipeline, DevSecOps embeds security thinking into every phase: planning, development, testing, deployment, and operations. The goal is to eliminate the old model where security was a separate team that reviewed software only at release time, replacing it with shared ownership across the entire engineering organization.
Security Is Not an Afterthought—It’s “Job Zero”
One of the most important points raised at DOES18 was a concern about the very name “DevSecOps.” Ilkka Turunen, Head of Solutions Architecture at Sonatype, voiced a widely felt tension:
“I’ve never been crazy about the term DevSecOps, because it’s like ‘Sec’ is an afterthought. You know, we were squeezing it in between Dev and Ops, the last kid that got on the bus, and we’re like, go on, just sit in there. For all of us, security is the first priority, the top job—’job zero,’ we sometimes call it. And therefore, for DevOps, it actually understands that security is key, and is the first thing that you do.”
— Ilkka Turunen, Sonatype
The term “job zero” is a useful mental model: before you write a single line of code or define a pipeline stage, security considerations should already be in play. This includes threat modeling during design, dependency scanning during development, and automated policy enforcement at build time.
GDPR and Privacy by Design
The GDPR regulation, which came into full effect in May 2018—shortly before the DOES18 London event—gave the DevSecOps conversation additional urgency. Turunen noted that GDPR moves well beyond data portability and breach notification requirements. Its broader principle of “privacy by design” requires that data protection be architected into systems from the outset, not retrofitted afterward.
For DevOps teams, this translates into concrete engineering decisions:
- Encrypting sensitive data at rest and in transit by default
- Minimizing data collection to only what is strictly necessary
- Implementing access controls and audit logging as infrastructure-as-code
- Running automated compliance checks as part of CI/CD pipelines
Privacy by design is not a checkbox; it is a cultural and architectural commitment that aligns directly with the DevSecOps philosophy.
Making Security Everyone’s Responsibility
A central challenge in DevSecOps adoption is cultural: how do you build an organization where every engineer thinks of themselves as a security practitioner? Turunen drew a parallel to how testing evolved over the past decade:
“So if you think about testing 10 years ago, it was literally people running from test execution plans, and gradually they changed from that to becoming writers of tests, people that write the automatic-execution, help people, help the floor become more efficient at testing for themselves. Teaching them unit testing, all these other frameworks. So I feel like we’re at the brink of a similar kind of change. I think it’s a mixture of both incentives and psychology, and just changing roles.”
— Ilkka Turunen, Sonatype
The analogy is instructive. Testing was once a specialized, siloed function. The shift-left testing movement brought it into the hands of developers, supported by tooling (unit test frameworks, CI integration, code coverage reporting) that made it practical. DevSecOps is following the same arc:
- Security training for developers — secure coding practices, OWASP Top 10 awareness, threat modeling basics
- Security tooling integrated into developer workflows — SAST, DAST, SCA tools running in IDEs and CI pipelines
- Clear feedback loops — surfacing security findings at the point in the workflow where developers can act on them immediately
- Incentive alignment — measuring and rewarding secure engineering behavior, not just shipping velocity
Security as a Subset of Good Engineering
Zane Lackey, founder of Signal Sciences, offered perhaps the clearest framing of the DevSecOps philosophy:
“The best way I’ve ever seen, like the highest performing organizations view it, is security is a subset of good engineering. In the way that resiliency is, reliability is, quality is, performance is, is a subset of good engineering.”
— Zane Lackey, Signal Sciences
This framing removes the adversarial dynamic that often exists between security and engineering teams. When security is understood as an engineering quality—on par with performance, reliability, and maintainability—it stops being an external audit function and becomes an intrinsic property of the software being built.
Practically, this means:
- Security requirements are written alongside functional requirements in user stories
- Secure defaults are baked into internal libraries and platform services
- Security findings are treated with the same severity as bugs and performance regressions
- Architecture reviews include threat modeling as a standard component
The Role of Cloud Providers and Machine Learning in Security
Margo Cronin, Senior Solution Architect at AWS, highlighted the growing role of cloud-native security services and machine learning in automating security at scale:
“You now have services that can scan your landscape and say do you know these large files contain client identifying data, do you know you have keys there? And then you have services where you can then change that behavior automatically. But I think that’s where we’re going to see cloud service providers become a lot more active. You know, using machine learning to harden your production landscape before you actually even go to the security operators.”
— Margo Cronin, AWS
Cloud providers now offer a broad portfolio of security services that DevOps teams can integrate directly into their pipelines and infrastructure. Common categories include:
- Data classification and discovery — automatically identifying sensitive data (PII, credentials, keys) stored in cloud resources
- Threat detection — continuously monitoring API calls, network flows, and account behavior for anomalies
- Configuration compliance — continuously evaluating cloud resource configurations against security benchmarks and organizational policies
- Automated remediation — triggering automated responses (quarantining resources, revoking credentials) when violations are detected
The promise Cronin describes—using machine learning to harden production environments proactively rather than reactively—reflects the broader direction of cloud security tooling, which increasingly operates continuously rather than on a scheduled audit basis.
Key Takeaways for DevOps Teams Adopting DevSecOps
The discussion at DOES18 surfaces several actionable principles for engineering organizations looking to mature their DevSecOps practice:
- Reframe security as “job zero” — position it as the first concern, not a final gate.
- Embed security tooling in the developer experience — SAST, SCA, secrets scanning, and IaC policy checks should run in CI/CD, not in a separate security pipeline.
- Build the cultural change incrementally — mirror the path testing took: start with training, add tooling, measure outcomes, adjust incentives.
- Treat security as an engineering quality attribute — give it the same weight as reliability, performance, and code quality in design and review processes.
- Leverage cloud-native security services — use continuous compliance, data classification, and threat detection capabilities offered by your cloud provider to achieve security at scale.
- Design for compliance from day one — regulations like GDPR require privacy and security to be architected in, not bolted on.
Further Viewing
The full DOES18 panel discussion, along with Margo Cronin’s presentation on “Security Automation at Scale” and Zane Lackey’s presentation on “How You Can Use DevOps to Make You More Secure,” were made available on DevOps TV following the event. Search the DevOps Enterprise Summit archive or the IT Revolution YouTube channel for these sessions.