How Cybersecurity Is Evolving to Become Part of DevOps: The Rise of DevSecOps

This article draws on commentary originally published by securitybrief.asia, featuring insights from Sean Duca, VP and Regional Chief Security Officer for Asia Pacific at Palo Alto Networks.

From DevOps to DevSecOps: Why Security Can No Longer Be an Afterthought

DevOps has spent the better part of a decade breaking down organisational silos, automating repetitive tasks, and accelerating software delivery. Now, security teams are facing the same reckoning: manual, bolt-on security practices are no longer sustainable, especially as more workloads move to the cloud.

The answer, according to practitioners and vendors alike, is DevSecOps — the practice of embedding security principles directly into the DevOps lifecycle rather than treating security as a separate gate at the end of the pipeline.

What Is DevSecOps?

DevSecOps extends the core DevOps philosophy — automate, collaborate, iterate — to include information security as a first-class concern at every stage of the software development lifecycle (SDLC). Rather than security reviews happening only before a release, security checks are integrated into:

• Code commit — static analysis and dependency scanning run automatically on every push
• Build — container image scanning and secrets detection occur during the CI pipeline
• Deployment — infrastructure-as-code policies enforce least-privilege configurations before resources are provisioned
• Runtime — continuous monitoring and threat detection operate in production

The goal is to make security a shared responsibility across development, operations, and security teams — not an external audit performed by a separate group.

Why Cloud Migration Accelerates the Need for DevSecOps

Cloud adoption fundamentally changes the threat model. On-premises environments had a relatively fixed perimeter; cloud environments are dynamic, API-driven, and often provisioned by developers who may have limited security training.

Sean Duca of Palo Alto Networks frames the challenge clearly:

“Developers are writing new code anyway; they should completely rethink and modernise their approach. Developers should no longer be deploying code and installing fixes the way they did when the internet was young. They need a new approach that seamlessly integrates developers, the operational team, and the security team. It’s not just about building an app in the cloud, it’s about building security in from the very beginning.”

Sean Duca, VP & Regional CSO Asia Pacific, Palo Alto Networks

Organisations that understand they retain responsibility for their own data — even when hosted in a cloud provider’s infrastructure — are better positioned to embrace DevSecOps. This is the essence of the shared responsibility model: the cloud provider secures the underlying infrastructure, but the organisation is accountable for everything it builds and stores on top of it.

Three Stages of Cloud Security Maturity

Palo Alto Networks describes a maturity progression that organisations typically move through as they deepen their cloud security practices:

1. Click — Security is applied manually through console interfaces when new servers or services are added. This is error-prone, inconsistent, and does not scale.
2. Command — Security controls are scripted, enabling some repeatability. Teams begin using CLI tools and basic automation to apply configurations.
3. Commit — Security is expressed as code and committed to version control alongside application and infrastructure code. Policy-as-code and infrastructure-as-code tools enforce security rules automatically at every deployment.

Reaching the “commit” stage means security is no longer a human checklist — it is a machine-enforced contract that every deployment must satisfy before it reaches production.

The Role of the Site Reliability Engineer (SRE) in DevSecOps

One structural change that supports DevSecOps is the rise of the Site Reliability Engineer (SRE). Originally conceived at Google to bridge the gap between software development and operations, the SRE role is increasingly relevant to security as well.

Duca explains the broader value:

“To maximise the efficiency, effectiveness, and security of the organisation’s overall operations, businesses need to eliminate separate teams for development, operations, and information security. Instead, they need tighter integration among all these teams, often held together by the SRE. The SRE combines the skills of developers responsible for writing applications with the skills operations engineers use to deploy those applications. SREs help scale operations through automation. Organisations that embrace this role and the DevSecOps model will outperform their competitors that don’t.”

Sean Duca, Palo Alto Networks

In practice, this means SREs who understand both application behaviour and infrastructure can write runbooks, alerting rules, and automated remediation scripts that address security events — not just availability incidents. Security becomes operationalised rather than siloed.

Five Requirements for DevSecOps Success

According to Palo Alto Networks, a mature DevSecOps model needs to satisfy five key requirements:

• Visibility and control — teams must have a clear, real-time view of every workload, container, and API endpoint across all environments
• Segmented applications — micro-segmentation limits lateral movement in the event of a breach, isolating the blast radius of any compromise
• Threat prevention — proactive controls such as web application firewalls, runtime protection, and vulnerability scanning prevent known attack vectors before they can be exploited
• Process automation — manual security tasks are replaced by automated pipelines that enforce policy consistently at machine speed
• Central management — a unified control plane provides audit trails, policy management, and incident response across hybrid and multi-cloud environments

Practical Steps for Teams Starting the DevSecOps Journey

Moving from traditional security practices to DevSecOps does not require a big-bang transformation. Teams can begin incrementally:

1. Add a SAST tool to your CI pipeline — static application security testing tools (e.g., Semgrep, Checkmarx, SonarQube) can surface common vulnerabilities at the code level before a pull request is merged.
2. Scan container images — tools like Trivy or Grype can be added as pipeline steps to detect known CVEs in base images and dependencies.
3. Adopt infrastructure-as-code with policy guardrails — tools such as Open Policy Agent (OPA) or Checkov can enforce security rules on Terraform and Kubernetes manifests before resources are provisioned.
4. Define security acceptance criteria alongside functional tests — treat failed security checks the same way you treat failed unit tests: the build does not proceed.
5. Run blameless post-mortems on security incidents — apply the same learning culture that DevOps uses for availability incidents to security events.

Conclusion

DevSecOps is not a product or a single tool — it is a cultural and technical shift that treats security as a shared engineering responsibility. As cloud adoption accelerates and attack surfaces grow more complex, organisations that embed security into every stage of their development pipeline will be better positioned to respond to threats quickly, reduce remediation costs, and maintain compliance without slowing delivery.

The message from practitioners like Sean Duca is consistent: security natively integrated into code and operations is not just best practice — it is becoming a competitive differentiator.