This article is based on survey findings reported by CyberArk at the RSA security conference, as originally summarized by networksasia.net (2017). Statistics cited reflect that survey’s results.
DevOps Adoption Is Outpacing Security Readiness
DevOps has become the dominant model for software delivery, promising faster release cycles, tighter team collaboration, and more reliable deployments. But adoption speed has come at a cost: security practices are failing to keep pace. According to a survey conducted by CyberArk at the RSA security conference, 70% of organizations either already use or plan to implement DevOps—yet the security infrastructure to support it safely is lagging far behind.
This disconnect is not a theoretical risk. It creates concrete vulnerabilities at every stage of the software development lifecycle (SDLC), from source code management to deployment pipelines and runtime environments.
Key Findings: Security Is Not Integrated Into DevOps
The CyberArk survey data paints a clear picture of how organizations are approaching—or failing to approach—DevOps security:
- 66% of organizations believe DevOps introduces new security obstacles.
- 47% acknowledge those obstacles are not yet fully understood internally.
- Only 38% of organizations with a dedicated DevOps team report that team is fully integrated with their security practice.
- 46% only involve the security team at the end of each development cycle—a pattern often called “bolting security on” rather than building it in.
Involving security only at the end of a sprint or release cycle is a structural problem. Vulnerabilities introduced early in development—insecure defaults, hardcoded credentials, misconfigured infrastructure-as-code—are exponentially more expensive and disruptive to fix after the fact. This is precisely what the “shift left” security model is designed to prevent.
What “Shift Left” Security Actually Means in a DevOps Context
“Shift left” refers to moving security testing and validation earlier in the development pipeline—closer to where code is written, rather than treating it as a final gate before production. In practice, this means:
- Integrating static application security testing (SAST) tools into the CI pipeline so developers receive immediate feedback on insecure code patterns.
- Scanning container images and infrastructure-as-code templates for known vulnerabilities before deployment.
- Embedding secrets management (e.g., HashiCorp Vault, AWS Secrets Manager) so credentials are never stored in source code or environment variables.
- Running dynamic application security testing (DAST) against staging environments as part of the CD pipeline.
- Ensuring security engineers participate in sprint planning and architecture reviews, not just post-release audits.
The survey data suggests most organizations have not yet operationalized any of these practices consistently. Without structural integration, security remains a reactive function rather than a built-in property of the system.
Cloud Security Gaps Compound the Problem
DevOps and cloud adoption typically go hand in hand, which means cloud security posture is directly relevant to DevOps risk. The survey found significant weaknesses here as well:
- 13% of organizations rely solely on their public cloud vendor’s built-in security controls—without layering additional controls or maintaining visibility into credential usage.
- 14% are still in the planning or early implementation stage of their cloud security strategy, meaning they are operating cloud workloads without a mature security posture.
- 33% do not secure, rotate, control, or monitor access to the privileged credentials used to authenticate to cloud management consoles.
The last point is particularly significant. Privileged access to cloud management consoles—AWS IAM roles, Azure Active Directory service principals, GCP service accounts—is one of the highest-value targets for attackers. Failing to rotate these credentials, enforce least-privilege policies, or monitor their use creates a large and largely invisible attack surface.
Shared responsibility is a foundational principle of cloud security: the cloud provider secures the infrastructure, but the customer is responsible for securing everything running on top of it. Relying entirely on vendor-native controls without additional monitoring or access governance misunderstands this model.
Ransomware Attacks Forced a Reckoning
The survey coincided with the aftermath of the WannaCry and NotPetya ransomware campaigns, which caused widespread operational disruption across industries globally. The impact was measurable in organizations’ attitudes toward security investment:
- 61% of organizations said those attacks prompted them to rethink their endpoint security strategy.
- 78% reported that cybersecurity is now a top-level board consideration.
Board-level awareness is a necessary precondition for security investment, but it is not sufficient on its own. The challenge is translating that awareness into funded, prioritized programs that reach development teams where they operate—inside CI/CD pipelines, container orchestration platforms, and cloud-native environments.
The Southeast Asia Context: Regulatory and Cultural Factors
The original report focused on Southeast Asia, which at the time had the world’s fourth-largest internet population but relatively underdeveloped data protection legislation. The rapid technology adoption curve—compressed timelines for cloud migration and DevOps transformation—meant organizations were acquiring technical risk faster than they were building the governance structures to manage it.
The survey noted that 50% of respondents in Singapore supported the aims of the then-proposed Singapore Cybersecurity Bill, which indicated growing regulatory appetite for formal security obligations. Regulatory frameworks, when well-designed, can serve as a forcing function for organizations that have otherwise not prioritized security investment.
Practical Steps to Close the DevOps Security Gap
Whether or not your organization participated in this survey, the patterns it identifies are broadly recognizable. The following practices directly address the gaps the data exposes:
1. Integrate Security Into Your CI/CD Pipeline
Add automated security scanning as a pipeline stage, not a manual post-deployment step. Tools such as Snyk, Trivy, Checkov, or Semgrep can scan code, containers, and infrastructure templates on every commit.
2. Adopt a Secrets Management Solution
Never store credentials, API keys, or certificates in source code, CI environment variables, or container images. Use a dedicated secrets management tool and enforce this through automated secret scanning in your pipeline.
3. Enforce Privileged Access Management for Cloud Accounts
Apply least-privilege IAM policies to all service accounts and human users. Rotate credentials on a defined schedule. Enable audit logging and alerting on privileged actions across all cloud management consoles.
4. Embed Security Engineers in DevOps Teams
The “security at the end” pattern persists partly because security teams are organizationally siloed. Embedding security engineers as active participants in development squads—sometimes called a DevSecOps model—changes this dynamic structurally.
5. Run Security Tabletop Exercises
Regularly simulate breach scenarios specific to your DevOps environment—compromised build server, leaked service account key, malicious dependency injection—so teams understand the attack surface and response procedures before an incident occurs.
Conclusion
The gap between DevOps adoption and security maturity is not inevitable—it is a product of organizational structure, prioritization, and tooling choices. Survey data from CyberArk illustrates that a large majority of organizations were, at least as of 2017, treating security as an afterthought in their DevOps programs. The underlying structural issues those findings describe—late-stage security involvement, unmanaged privileged credentials, cloud security blind spots—remain relevant challenges for engineering teams today.
Closing the gap requires treating security as a first-class engineering concern: automated, measurable, and integrated from the first line of code to production monitoring. That is not a cultural aspiration—it is an engineering discipline that can be designed, built, and continuously improved.