Originally based on analysis published at informationsecuritybuzz.com (2018). The trends and observations below reflect the security landscape of that period and have been rewritten for technical clarity.
Introduction: DevOps Velocity Without Security Maturity
In the face of relentless competitive pressure, organisations increasingly adopted DevOps to improve delivery speed and operational efficiency. But many of those same organisations failed to invest proportionally in the security practices, tooling, and talent needed to protect their new automated workflows. The result: faster delivery of potentially vulnerable software, with credentials, secrets, and privileged access scattered across repositories, scripts, and pipeline configurations.
Drawing on incidents and threat landscape data from 2017, three security trends emerged that every DevOps engineering team needed to understand heading into 2018—and that remain directly relevant today.
Trend 1: Credential Sprawl in Source Repositories Is a Systemic Risk
The Uber Breach as a Warning Sign
The 2017 Uber data breach exposed personal data belonging to approximately 57 million customers and drivers. Investigators found that Uber developers had stored credentials in a software repository using an informal workaround—one that gave attackers access to privileged cloud storage accounts. The breach was not the result of a sophisticated exploit; it was the result of developers working around a process that had no convenient, secure alternative.
This pattern is not unique to Uber. Developers are accountable for features and functionality, not for designing secure credential management workflows. When organisations provide no standard, developer-friendly way to handle secrets, individuals improvise—and those improvisations create exploitable gaps.
The Underlying Problem: No Standard for Secure Collaboration on Secrets
At the time, a significant proportion of organisations surveyed in threat landscape research could not identify all the locations where credentials were stored across their environments—including informal workarounds in repositories and configuration files. Many organisations also lacked any documented strategy for managing privileged account security within DevOps pipelines specifically.
The same research found that roughly half of organisations did not fully disclose to affected customers when personal data was compromised in a cyber attack, compounding the breach’s damage to consumer trust.
What Good Looks Like: Secrets Management Integration
The solution is not to retrain every developer as a security engineer—it is to make secure practices the path of least resistance. This means:
- Integrating dedicated secrets management tools (such as HashiCorp Vault or cloud-native equivalents) directly into CI/CD pipelines.
- Enforcing pre-commit hooks or repository scanning to detect accidentally committed credentials before they reach version control.
- Providing developers with clearly documented, easy-to-use workflows for credential injection at runtime rather than at rest in configuration files.
- Rotating credentials automatically so that any exposure has a bounded blast radius.
Security embedded in the developer experience is far more effective than security bolted on after the fact.
Trend 2: DevSecOps Is a Distinct Discipline—and the Talent Gap Is Real
The Problem With Assigning Security to DevOps Teams by Default
Many organisations responded to growing security concerns by assigning security responsibilities to existing DevOps practitioners—engineers who were already fully occupied with pipeline reliability, infrastructure automation, and release velocity. This approach treats security as an additive responsibility rather than a dedicated function, and it consistently produces gaps.
DevOps practitioners are expert in the tooling and workflows of continuous delivery. They are not, by default, expert in threat modelling, access control design, audit log review, or privileged identity governance. Asking one group to fully own both domains without additional time, training, or headcount is a structural problem, not a skills problem.
What DevSecOps Practitioners Actually Do
A DevSecOps engineer sits at the intersection of software delivery and security engineering. Their responsibilities typically include:
- Embedding security controls—static analysis, dependency scanning, secrets detection—as gates in CI/CD pipelines.
- Designing and maintaining identity and access management (IAM) policies for both human operators and automated systems (machine identities).
- Performing threat modelling on pipeline architectures and automated workflows.
- Monitoring runtime behaviour of containerised workloads and detecting anomalous access patterns.
- Owning the privileged access management (PAM) strategy for pipeline service accounts, deployment keys, and API tokens.
This is a full-time role. Organisations that treat it as a part-time addition to an existing job description will continue to accumulate unmanaged risk.
Addressing the Talent Gap Practically
Given the genuine scarcity of professionals with deep competency in both DevOps tooling and security engineering, organisations need to invest in upskilling existing staff, establishing clear security champions within teams, and using automated tooling to enforce policy rather than relying solely on human vigilance.
Trend 3: Least Privilege Must Extend to Machine Identities
The Identity Problem in Highly Automated Environments
The principle of least privilege—granting any actor only the permissions required to perform its defined function—is well established for human users. In 2018, organisations were only beginning to apply it systematically to the non-human actors in their environments: virtual machines, containers, pipeline agents, deployment scripts, and orchestration platforms.
Modern DevOps environments are composed of dozens of interacting components, each of which may hold credentials or tokens granting access to production systems. There was no common standard for machine identity, access control, or audit across this stack. Each layer—VM, container runtime, orchestrator, artifact registry, cloud API—could represent the weakest link in an otherwise carefully managed environment.
Applying Human IAM Concepts to Machines
The practical application of least privilege to machine identities requires asking the same questions used in human access reviews:
- Who are you? — Does this machine identity have a verified, auditable identity? Is it using a short-lived certificate or a long-lived static credential?
- What are you? — Is this a pipeline agent, a microservice, a scheduled job? The role should define the permission scope.
- What are you asking for? — Is this request consistent with the expected behaviour of this identity at this point in the workflow? Anomalies should trigger alerts.
Applying these controls consistently—using workload identity federation, short-lived tokens, just-in-time access provisioning, and continuous audit—reduces the blast radius of any single compromised component.
The Toolchain Is Also an Attack Surface
A critical insight from the 2017–2018 period is that the DevOps toolchain itself—the very tools used to build and deploy software—is part of the attack surface. Compromising a single tool in the pipeline can yield access to the systems that tool is authorised to reach. A phishing attack or credential theft targeting a pipeline agent, deployment key, or CI server can cascade into full production access.
This means that security reviews must include the pipeline and its components, not only the application being delivered through it. Tools such as Terraform, Ansible, and GitHub Actions are not security tools in themselves—they are high-privilege actors that require the same access governance applied to any other privileged system.
What DevOps Practitioners Often Miss
A useful diagnostic exercise is to ask a DevOps engineer which security tools they use. A typical answer names the automation and infrastructure tools in their stack: Terraform, GitHub, Ansible, Kubernetes. These are delivery tools, not security controls—though they can be configured with security in mind.
What is often absent from that answer is any mention of access control, privileged identity management, secrets rotation, audit logging, or anomaly detection. These are the controls that govern who and what can reach sensitive systems—and they are frequently outside the scope that DevOps practitioners consider their security responsibility.
Closing that gap requires organisational clarity about who owns each security domain, tooling that enforces controls without requiring developers to become security specialists, and a shared understanding that the pipeline is as important to protect as the application it delivers.
Summary
| Trend | Core Risk | Practical Response |
|---|---|---|
| Credential sprawl in repositories | Hardcoded secrets enable lateral movement after initial compromise | Secrets management tooling integrated into pipelines; pre-commit scanning |
| DevSecOps talent gap | Security responsibilities assigned to teams without security expertise or capacity | Dedicated DevSecOps roles; automated policy enforcement; security champions |
| Machine identity and least privilege | Non-human actors hold excessive, unaudited permissions across pipeline layers | Workload identity; short-lived tokens; just-in-time access; pipeline audit logs |
These challenges did not disappear after 2018. Credential mismanagement, understaffed security functions, and ungoverned machine identities remain among the most commonly exploited weaknesses in modern software delivery environments. The principles outlined here—embed security in developer workflows, define clear ownership, and apply least privilege to every actor in the pipeline—are as applicable now as they were when these trends first emerged.