This article is based on an interview with Elizabeth Lawler, then Vice President of DevOps Security at CyberArk, originally published by securitybrief.com.au in May 2018. Lawler was previously CEO of Conjur, a DevOps security startup acquired by CyberArk.
The DevOps Security Gap
DevOps has fundamentally changed how software is built and shipped. Faster release cycles, automated pipelines, and infrastructure-as-code have made development teams more productive than ever. But speed has a side effect: security often gets deferred to the end of the delivery cycle, bolted on rather than built in.
This is the problem DevSecOps is designed to solve. Rather than treating security as a gate at the end of a pipeline, DevSecOps embeds security thinking, tooling, and accountability into every phase of software development and delivery.
“The DevOps train is unstoppable right now,” said Lawler. “A lot of organisations are thinking about how they can move fast, and deliver value to their customers faster through software delivery.” The challenge is ensuring that speed doesn’t come at the expense of a defensible security posture.
Privileged Access: The Overlooked Risk in DevOps
One of the most underappreciated attack surfaces in DevOps environments is privileged access. Automation tools, orchestration platforms, CI/CD pipelines, and container schedulers all require credentials and permissions to function. Mismanaged, those credentials become high-value targets.
According to CyberArk’s Global Advanced Threat Landscape Survey (referenced in the original interview), 82% of organisations lacked a privileged account security strategy for their DevOps environments at the time. That figure underscores how far behind security practice has lagged behind DevOps adoption.
Lawler frames privileged access management (PAM) not as a compliance checkbox but as a foundational operational concern: “CyberArk focuses on privileged access management as a holistic process of managing powerful users or powerful systems that are working inside IT and DevOps environments.”
Real-World Consequences: The Tesla Kubernetes Incident
The risks of poorly secured DevOps infrastructure are not theoretical. Lawler cited the widely reported case in which Tesla’s Kubernetes environment was compromised and used for cryptocurrency mining.
“Someone got into the Kubernetes administrative console, probably by phishing Kubernetes admins. They got on the console and launched a bunch of IT resources to mine cryptocurrency,” she explained.
She noted that this type of attack is not an isolated event: “Things like that hit everybody and it happens multiple times a day to all kinds of organisations. Anyone who accidentally uploads an Amazon credential to GitHub – in five minutes a bot will max out your Amazon account and start cryptocurrency mining.”
The underlying problem in both cases is the same: powerful systems—Kubernetes, cloud provider APIs, configuration management platforms—were not treated with the same level of access governance as a human system administrator with equivalent permissions would be.
“Kubernetes, configuration management, and orchestration tools are powerful system administrators. They need to be managed or overseen the same as with any person who had that kind of power,” Lawler said.
Secure Innovation by the Numbers
Lawler’s concept of “secure innovation by the numbers” is a pragmatic reframe of DevSecOps for engineering teams. The idea is that security improvement should be measured, incremental, and visible—treated the same way engineering teams already treat delivery metrics.
“DevOps teams love to run on metrics. If it’s a language and construct they can work in, and then having security teams as part owners of that, you can break down organisational barriers,” she said.
In practice, this means defining KPIs that security and DevOps teams share jointly—such as time to remediate a known vulnerability, number of secrets stored in plaintext, or coverage of least-privilege policies across pipeline stages. When both teams are accountable for the same numbers, the historical tension between “ship fast” and “ship securely” starts to dissolve.
“It’s one thing to say, ‘I’ve secured this platform’, but there are different tools coming in. It’s an entire process problem where we see breakdowns,” Lawler noted. The implication is that point-in-time security assessments are insufficient; continuous measurement is required.
Organisational and Cultural Change
Technical tooling alone won’t close the DevOps security gap. Lawler argues that the mandate for integrating security early must come from leadership—not just engineering management, but boards and C-suite executives.
“It should be coming from the senior levels and even down to the board and management to say DevOps and security teams need to start working together at the earliest possible moment,” she said. Board members with governance or cybersecurity oversight responsibilities, she suggested, should be asking management to surface and report on these issues explicitly.
From an engineering culture perspective, the key is removing historical silos—the inherited separation between development teams, operations teams, and security teams that causes security to be treated as someone else’s problem until something breaks.
Practical Steps: Applying Security Without Disrupting Workflow
A recurring concern in DevOps organisations is that security controls will slow down delivery. Lawler’s response is that well-implemented security need not interrupt workflow at all.
“The thing organisations can’t do is compromise ability to deliver by applying security policies. What companies like CyberArk are doing is to apply security without interrupting workflow,” she said.
Concretely, CyberArk at the time offered a 30-day “Cyber Hygiene” sprint program designed to help organisations identify and remediate the most common privileged access security issues in their DevOps environments. The programme also helped teams establish patterns such as least privilege and separation of duties directly in the CI/CD pipeline.
Lawler’s closing advice captures the incremental philosophy well: “If you improve application design by one percent per day every day rather than trying to deal with a pile of problems at the end, you’ll be in a much better position if something happens to go awry—and you’ll have a much smaller threat surface.”
Key Takeaways for DevOps and Platform Engineers
- Treat automation credentials as privileged accounts. CI/CD service accounts, orchestration tools, and cloud API keys carry significant blast radius if compromised. Apply the same access governance you would to a human admin.
- Never commit credentials to version control. Automated bots actively scan public repositories for cloud provider keys. Use secrets managers and pre-commit hooks to prevent accidental exposure.
- Define shared security KPIs. When development and security teams own the same metrics, cultural friction decreases and security work gets prioritised alongside feature delivery.
- Involve security from the design phase. Retrofitting security controls onto an existing system is significantly more expensive and error-prone than building them in from the start.
- Implement least privilege in the pipeline. Each stage of a CI/CD pipeline should have only the permissions it needs for that specific task—nothing more.
- Make improvements incremental and measurable. Small, continuous improvements to your security posture compound over time and are far easier to sustain than periodic large-scale remediation efforts.
Original interview published May 2018 via securitybrief.com.au. Product and programme details reflect CyberArk’s offerings at the time of publication.