This article is based on commentary originally published by Computer Weekly, drawing on analysis from Elizabeth Lawler, then Vice-President of DevOps Security at CyberArk.
DevOps Speed Without Security Is a Risk Multiplier
DevOps practices deliver measurable improvements in deployment frequency, lead time for changes, and overall business agility. However, the same speed and automation that makes DevOps valuable can also introduce — or revive — serious security vulnerabilities when security is treated as an afterthought.
According to Elizabeth Lawler, speaking with Computer Weekly, many organisations pursue rapid innovation without adequately training staff in security best practices. The result is a widening gap between what DevOps teams deliver and the security posture those deliverables require.
“This failure leaves organisations vulnerable to both internal and external threats.”
Elizabeth Lawler, then VP of DevOps Security, CyberArk
Three DevOps Security Trends Every Organisation Should Track
Lawler identified three key trends — grounded in real incidents and research data — that highlight why the DevOps-to-DevSecOps transition is urgent.
1. Credential Exposure in Source Repositories Is Systemic
The 2017 Uber data breach became a defining case study in DevOps security failure. Developers stored credentials in a software repository as a workaround for managing access across tools. Attackers discovered those credentials and used them to access privileged accounts, ultimately exposing the personal data of 57 million customers.
Lawler argued this was not an isolated mistake specific to Uber — it reflected a common and widespread practice:
“Those developers aren’t alone, and this is a peek behind the curtain of a common practice among developers. There is no obvious way to collaborate securely across tools.”
Elizabeth Lawler
CyberArk research cited by Lawler found that 73% of organisations had no strategy at all to address privileged account security for DevOps pipelines. Most organisations also could not identify all the locations where credentials were stored across their environments.
The core problem is role misalignment. Developers are responsible for features and functionality, not secrets management. When organisations expect developers to fill a security function without training, tooling, or clear process, gaps are inevitable. The long-term fix, according to Lawler, is automation that makes secure credential handling part of the developer’s native workflow — not a separate burden.
Separately, CyberArk research also found that 50% of organisations did not fully disclose to customers when personal data was compromised — suggesting the Uber decision to conceal the breach was not an outlier either.
2. DevSecOps Is a Distinct Discipline — Not a Side Responsibility
A common organisational response to DevOps security concerns is to ask existing DevOps practitioners — often with little or no security background — to take on security responsibilities in addition to their existing workload. Lawler argued this approach is no longer adequate.
The attack surface in a modern DevOps workflow is significant. It spans scripts, CI/CD pipelines, container orchestration platforms, cloud infrastructure APIs, and the secrets embedded across all of them. Securing this surface requires dedicated expertise — not a part-time assignment.
“Security will become a full-time job focused on DevOps workflows, and there will be few practitioners to fill that role available in the market.”
Elizabeth Lawler
The talent gap for DevSecOps practitioners — engineers who genuinely understand both continuous delivery pipelines and security engineering — was identified as a critical emerging constraint. Organisations that invested in tooling without investing in the people to operate it securely were seen as particularly exposed.
3. Machine Identity and Least Privilege Must Extend to Automated Systems
In traditional IT environments, access control and identity management frameworks were built around human users. Modern DevOps environments introduce a large number of non-human identities: virtual machines, containers, service accounts, CI/CD agents, and API integrations. Each of these can request and receive privileged access — often with far less oversight than human accounts.
Lawler observed that there is no widely adopted common standard for machine identity, access control, or audit across the many platform layers that make up a modern infrastructure stack:
“Organisations are only as safe as their weakest link. The weak link could be a VM, container or any of the dozens of platform layers that now exist across the network. As these matrices expand, they become substantially harder to control.”
Elizabeth Lawler
The proposed direction is to apply the same least-privilege principles used in human access management to machine identities — enforcing that every system component can only access what it needs, when it needs it, and with a full audit trail. Continuous delivery of least privilege, applied consistently across the DevOps toolchain, is what Lawler described as the practical goal of DevSecOps.
The Blind Spot: Secrets Management vs. Vulnerability Scanning
DevOps teams typically frame security in terms of vulnerability scanning and patch management. Tools like Terraform and Ansible are widely used in this context. However, Lawler pointed out that these tools address software vulnerabilities — not access control, privilege escalation, or secrets management.
“Secrets management is simply not on their radar.”
Elizabeth Lawler
This is precisely why the Uber breach bypassed typical DevOps security controls. The compromised asset was not a vulnerable application — it was a credential stored in a source repository, which is a security tool failure, not an application vulnerability. An attacker who compromises one DevOps tool with broad access can effectively own the entire connected system.
What the Shift to DevSecOps Requires in Practice
Moving from DevOps to DevSecOps is not simply a rebranding exercise. Based on Lawler’s analysis, it requires changes across people, process, and tooling:
- Dedicated security expertise embedded in DevOps teams — not shared, part-time responsibilities bolted on to existing roles.
- Automated secrets management — credentials and keys should never be stored manually in repositories; secrets vaults and dynamic credential injection should be standard.
- Machine identity governance — every non-human identity in the pipeline should be inventoried, assigned least-privilege access, and audited.
- Cross-team collaboration — IT, DevOps, and security teams need shared visibility into threat models, toolchain risks, and access policies.
- Attacker-perspective thinking — security posture should be evaluated by asking what an attacker could do if they compromised a single DevOps tool, then designing controls accordingly.
Key Takeaway
DevOps without security discipline does not eliminate risk — it accelerates the delivery of risk into production. DevSecOps is not a product or a single tool; it is a practice that embeds security into every stage of the software delivery lifecycle, with the people, processes, and automation required to sustain it. For organisations that have invested in DevOps maturity, addressing the security gap is the logical and necessary next step.
Original reporting by Computer Weekly. Commentary attributed to Elizabeth Lawler, then VP of DevOps Security at CyberArk, circa early 2018.