The speed and automation that define DevOps are genuine competitive advantages — but they also introduce serious security risks if privileged access is handled carelessly. When DevOps toolchain misconfigurations lead to breaches, overprivileged accounts are frequently at the root cause. According to a study by security vendor BeyondTrust, 52 percent of IT practitioners identified overprivileged users as a primary driver of DevOps and next-generation technology breaches.
To capture the benefits of DevOps without exposing critical infrastructure and data, organizations need a deliberate strategy around Privileged Access Management (PAM). The following three best practices — drawn from guidance by Morey Haber, CTO at BeyondTrust, as reported by DevOps.com — provide a practical starting point for teams building security into their continuous delivery pipelines.
1. Discover and Inventory All Privileged Accounts and Assets
Effective PAM starts with visibility. You cannot manage or protect privileged accounts that you do not know exist. In a DevOps environment, this is easier said than done: automation scripts, compiled executables, CI/CD tools, and infrastructure-as-code all accumulate credentials in ways that are difficult to track.
“If it’s embedded in other runtimes or it’s hard-coded into compiled executables, that discovery is the hardest,” said Haber. Despite the difficulty, a complete inventory is non-negotiable. Teams need clear answers to questions such as:
- Which tools are executing automation, and what privileges have been assigned to them?
- Is the automation running as a PowerShell script, embedded in Jenkins, or somewhere else entirely?
- Who is running each process, and when?
- Where are automation scripts stored, and where are their embedded credentials stored?
That last point matters because wherever credentials are stored determines how easily they can be tampered with or exfiltrated. The audit must cover the full lifecycle of a privileged credential: how it is edited, stored, retrieved, and used at runtime. Without this foundation, all other PAM controls are incomplete.
2. Manage Shared Secrets and Hard-Coded Passwords
Hard-coded passwords are one of the most dangerous anti-patterns in credential management. Development teams may rigorously eliminate hard-coded credentials from production application code, yet leave them scattered throughout the supporting infrastructure — build servers, deployment pipelines, configuration files — simply because it is faster to do so.
Similarly, shared accounts are a common shortcut: a single set of credentials is used by multiple developers or automation processes to reduce friction. The trade-off is severe — shared credentials destroy auditability. When multiple actors use the same account, there is no reliable way to attribute a specific action to a specific person or process.
“Whether that is using some type of proxy technology, a VDI environment — anything — you don’t want people logging in directly with shared accounts because you can’t trace that,” Haber explained.
The remedy is a control plane that enforces unique credentials for both human users and automated processes. Every action — whether taken by a developer or by a CI/CD pipeline — should be traceable back to a unique identity. This is essential for:
- Compliance: Regulatory frameworks typically require demonstrable audit trails for privileged access.
- Forensics: In the event of an incident, investigators need to reconstruct exactly what happened and who or what caused it.
- Pipeline integrity: Knowing which automated process triggered a change is fundamental to maintaining a trustworthy software delivery “factory.”
Secrets management tools (such as HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault) can help teams retire hard-coded passwords and rotate credentials automatically without breaking automation workflows.
3. Enforce the Principle of Least Privilege
Even when credentials are properly inventoried and uniquely assigned, over-provisioning remains a serious risk. The principle of least privilege holds that every user account and every automated process should have only the minimum level of access required to perform its specific function — nothing more.
“We see credentials being given to DevOps teams all the time that are way, way overprivileged,” said Haber. “It should come down to the least privileged model — that you’re giving enough privileges for the DevOps process to work, but not overprovisioning so that if any process or account is compromised, it doesn’t jeopardize the rest of the environment.”
In practice, this means:
- Scoping service accounts tightly: A deployment pipeline that only needs to push artifacts to a specific repository should not have write access to the entire infrastructure.
- Using just-in-time (JIT) access: Grant elevated privileges only when needed, for a defined time window, then revoke them automatically.
- Auditing privilege assignments regularly: Access needs change as teams and pipelines evolve; periodic reviews catch permissions that have become unnecessarily broad over time.
- Applying least privilege to non-human identities: Automation accounts, service accounts, and CI/CD pipeline identities need the same scrutiny as human user accounts.
Putting It Together: PAM as a DevSecOps Foundation
These three practices — discovery and inventory, elimination of shared secrets and hard-coded passwords, and enforcement of least privilege — form an interconnected foundation. Discovery tells you what you need to protect. Eliminating shared secrets ensures each identity is traceable. Least privilege limits the blast radius if any credential is compromised.
Building PAM controls into the continuous delivery pipeline from the start is far less costly than retrofitting them after a breach. For DevOps teams pursuing a DevSecOps posture, privileged access management is not a compliance checkbox — it is a core engineering concern.
Original reporting by DevOps.com, based on an interview with Morey Haber, CTO at BeyondTrust.