This article draws on findings from CyberArk’s Threat Landscape Report 2018, which surveyed more than 1,000 IT security leaders, line-of-business owners, and DevOps specialists across seven countries, as well as commentary from Elizabeth Lawler, then VP of DevOps Security at CyberArk and founder of the open-source security service Conjur. Original coverage appeared on diginomica.com.
The Security Blind Spot Inside Your DevOps Pipeline
The shift toward continuous delivery and DevOps has delivered genuine speed and agility to software organizations. But it has also quietly created one of the most underappreciated attack surfaces in the modern enterprise: the sprawl of machine identities, privileged credentials, and automation secrets that power CI/CD pipelines, cloud environments, and containerized workloads.
Unlike a compromised human account, a compromised automation credential can be replicated and exploited at machine speed — across every system the automation touches. Traditional security programs, designed around human-operated systems, have simply not kept pace.
What Are DevOps “Secrets” — and Why Do They Matter?
In DevOps contexts, a secret is any credential or token that grants programmatic access to a system. Common examples include:
- Privileged account passwords used by automation scripts to access servers or databases
- SSH keys that authenticate machine-to-machine connections
- API keys and tokens used by microservices, CI/CD tools, and third-party integrations
- Service account credentials embedded in configuration management tools like Ansible, Chef, or Puppet
As organizations adopt cloud environments and DevOps pipelines, these secrets multiply rapidly. Automation tools enable machine-to-machine interactions without human intervention, relying on machine identities rather than human ones. Every new service, container, or microservice potentially introduces new credentials — and new attack vectors.
While this further helps accelerate the pace and agility of compute environments, it also increases and dynamically creates credentials, secrets and access points – expanding the attack surface, with increased numbers of privileges and credentials, while also enabling vulnerabilities to potentially be more rapidly exploited.
CyberArk, Threat Landscape Report 2018
The Scale of the Problem: What the Data Shows
CyberArk’s survey data paints a stark picture of how far security practice lags behind DevOps adoption:
- 38% of respondents did not identify cloud environments, containers, CI/CD tools, microservices, or source code repositories as locations where secrets exist in their organization — despite nearly every component of a DevOps ecosystem relying on them.
- 75% of security respondents reported that their organization had not implemented a privileged account security solution for DevOps.
- 60% of DevOps respondents admitted to storing privileged account or administrative passwords in a document on a company PC or laptop — unmanaged, unsecured, and high-value targets.
- Fewer than half (46%) of DevOps respondents said their security and DevOps teams were well integrated throughout the development process.
- 43% said the security team is brought in only at the end of each development cycle.
These figures highlight a systemic gap: organizations are automating faster than they are securing.
Why Automation Amplifies Security Risk
The core danger is a force multiplier effect. Elizabeth Lawler, then VP of DevOps Security at CyberArk, framed it plainly:
The fundamental shift that we recognised early on was that we saw the role of the privileged or super user change. That is the super-powerful system administrator of yore is now a set of coded scripts, and you have very little insight or ability to control it. This often leads to things like embedded passwords in these scripts, or privileges and access tokens… If they become compromised, then you have a very large attack surface for a malicious hacker. That is fundamentally the risk that people are taking on now when they’re doing DevOps.
Elizabeth Lawler, VP of DevOps Security, CyberArk
Three structural factors make the problem especially difficult to manage:
- Workloads are moving to the cloud. Critical and regulated workloads increasingly run in environments where the traditional network perimeter no longer applies, adding complexity to access control.
- Containers and microservices scale faster than humans can monitor. Ephemeral workloads spin up and down so quickly that manual oversight is impractical — yet each instance may carry its own credentials.
- Automation fills gaps humans used to occupy. Configuration management tools, deployment scripts, and orchestration platforms perform tasks previously done by people — and if those tools are compromised, attackers inherit everything they could do.
Industry Variation: Who Is Most at Risk?
The CyberArk report found significant variation in how well DevOps and security teams collaborate across industries — with some counterintuitive results:
- Consumer services, technology, and telecommunications showed the closest partnerships between DevOps and security teams.
- Financial services — arguably among the most security-sensitive sectors — reported slightly below-average collaboration.
- Healthcare was the most concerning: only 16% of healthcare respondents believed their security and DevOps teams were well integrated, despite operating under strict regulatory requirements around data protection.
The implication is clear: heavy regulation alone does not produce good security integration. Culture, tooling, and process changes are also required.
What Good DevOps Security Actually Looks Like
Lawler argues that the answer is not to bolt security on at the end of the pipeline, nor to embed it invisibly within other tools. Instead, organizations need a dedicated, purpose-built approach to secrets management that is explicitly separate from the automation it governs:
There needs to be a bridge between this desire for velocity – for high-velocity software development and scaling – and security compliance, knowledge, and transparency. And those two don’t have to be a mismatch if you can get the foundational technologies right. With the administrator, which could be code, and the security that watches the administrator, which can also be code, there need to be checks and balances against each other, and therefore they need to be separated via privileged account and secrets management.
Elizabeth Lawler, VP of DevOps Security, CyberArk
In practical terms, this means:
- Adopt a dedicated secrets management solution (such as HashiCorp Vault, CyberArk Conjur, or AWS Secrets Manager) rather than relying on embedded credentials in scripts or configuration files.
- Rotate credentials automatically so that even if a secret is exposed, its useful lifetime is short.
- Audit and inventory all secrets across cloud environments, containers, CI/CD tools, microservices, and source code repositories — the 38% of organizations that have not done this are flying blind.
- Integrate security into the pipeline from day one, not as a final gate before deployment. This is the foundational principle of DevSecOps.
- Ensure security and DevOps teams collaborate continuously throughout design, development, testing, and deployment — not just at the end of a release cycle.
The Bottom Line
DevOps automation is not inherently insecure — but it demands a fundamentally different security model than traditional IT environments. The combination of machine-speed propagation, ephemeral infrastructure, and widespread secrets sprawl creates an attack surface that grows faster than most security teams recognize.
The organizations that will navigate this best are those that treat secrets management as a first-class engineering concern from the start, integrate security deeply into their DevOps culture and toolchain, and resist the temptation to treat a password in a text file as an acceptable solution just because it is convenient.
As Lawler put it, velocity and security do not have to be in conflict — but only if you get the foundational technologies right.