OWASP CI/CD Top 10: Inadequate IAM

In the race to ship software faster, many teams have turned to automation, decentralised tools, and powerful pipelines. But lurking under the surface of these streamlined processes is a growing and often invisible Identity and Access Management (IAM) threat vector. — a core vulnerability in modern CI/CD security.

This post is Part 2 in our ongoing blog series exploring the OWASP Top 10 CI/CD Security Risks, based on insights from Cloudsmith’s free OWASP eBook, which is a must-read for anyone serious about pipeline security. Today, we shine a light on OWASP CICD-SEC-2: Inadequate Identity and Access Management.

Principle of Least Privileged Access in CI/CD

Modern software delivery pipelines span dozens (if not hundreds) of interconnected systems. From source control to build agents to artifact repositories and deployment targets, each component relies on a web of human and machine identities to function.

But managing all these identities (especially ensuring they follow the principle of least privilege) is no small feat. IAM often ends up inconsistent, outdated, or overly permissive, creating significant vulnerabilities across your CI/CD toolchain.

Common IAM Pitfalls in CI/CD Systems

Through research and real-world incident response, several recurring IAM security issues emerge when it comes to identity and access management in CI/CD environments:

Overly Permissive Identities

In most organisations, engineers are given broad access to systems like Git, CI tools, or artifact registries (oftentimes with far more access than they need). This makes compromise of a single identity disproportionately dangerous.

When a single identity, for example an AWS IAM role, holds excessive permissions, it becomes a high-value target. An attacker who compromises that AWS identity doesn't just gain access to one part of the cloud provider - they gain a foothold in many, and in some cases, nearly all other connected systems such as CI systems. This lateral movement potential amplifies the blast radius of what could have been a contained incident.

Stale IAM Accounts

In many businesses, user accounts (especially those of former employees or outdated systems) are often overlooked once they're no longer actively used. These are referred to as stale accounts. They pose a serious security risk if not regularly audited and removed.

When an employee leaves or a service account becomes obsolete, the account should be disabled or deleted promptly. However, due to oversight, lack of automation, or unclear off-boarding procedures, these accounts can linger in the system. Even if they're not in active use, they can still have valid credentials and potentially high levels of access to sensitive data or internal systems.

Local Identities

When individual tools or systems manage their own user accounts (commonly referred to as local identities) rather than integrating with a centralised Identity Provider (IdP), it significantly undermines the ability to enforce uniform security policies. This fragmented approach creates operational silos, where critical security practices such as Multi-Factor Authentication (MFA), password complexity and rotation policies, or standardised de-provisioning processes become inconsistent or are entirely absent. As a result, the business is now exposed to greater risk, with increased chances of credential sprawl, orphaned accounts, and compliance gaps.

Shared Credentials

Not only do shared credentials violate security best practices, but they also break accountability and audit trails. This would be a real nightmare scenario during incident investigations. When multiple people log in under the same account, it becomes nearly impossible to determine who did what, when, and why. This lack of traceability destroys accountability and renders audit logs practically useless. 

During a security incident or forensic investigation, this can turn an already stressful situation into chaos. Not knowing who accessed sensitive data or executed a risky command is a major obstacle to containment and remediation. Simply put, shared IAM accounts turn manageable risks into security blind spots.

External and Self-Registered Users

Accounts associated with personal or untrusted email domains (such as @gmail.com) introduce a heightened level of risk, particularly when they’re granted access to internal systems. These external collaborators often fall outside the scope of centralised identity and access management, making it harder to enforce consistent security policies, monitor activity, or revoke access when necessary. 

Even more concerning are self-registration features, which allow users to create their own accounts without vetting or approval. This can open the door to impersonation, fraud, or other unauthorised activities. Combined, these scenarios significantly widen your development team's attack surface, increasing the likelihood of data leaks, unauthorised access, or compliance violations.

Case Study: New York State’s GitLab Exposure

To highlight how real these risks are, let’s look at a stark example.

A real-world example of CI/CD IAM mismanagement occurred when a self-managed GitLab instance operated by New York State’s IT department was left exposed to the internet, configured to allow open self-registration. Anyone, from anywhere, could create an account and access repositories that contained secret keys, passwords, and other sensitive data.

Discovered by cybersecurity firm SpiderSilk, the breach exposed the state’s infrastructure to potentially catastrophic consequences. It’s still unclear how long the server was exposed, but the lack of proper IAM (including no registration restrictions, stale secrets, and unrestricted access) created a perfect storm.

IAM Best Practices for Secure CI/CD

IAM doesn’t have to be a liability. With the right processes and tools, organisations can regain control over identity management in CI/CD. Here are some key recommendations:

• Map All Identities: Continuously inventory every identity across SCM, CI, CD, and artifact systems. (whether they’re human or machine identities). Gartner estimates that machine identities outnumber human identities by a ratio of 45 to 1 ratio. Similar to human identities, machine identities require authentication to access critical resources, and this is often done through shared secrets such as OAuth tokens and access keys.
• Audit External Users: Set expiry dates for access and ensure external collaborators only receive what’s absolutely necessary. This leads on to the topic of the principle of least privilege. Do not provision accounts with the intention of them being used as “shared accounts”. This makes auditing employee-specific behaviour almost impossible.
• Enforce Least Privilege access: Review actual usage vs. granted permissions and dial down access accordingly.Optimising permissions for IAM users, roles, and policies across various cloud and CI services isn’t easy, but it's required to align with the principle of least privilege.Check out Github’s blog on implementing least privilege access for secrets in Github Actions.
• Eliminate Stale Access: Define inactivity thresholds and routinely disable or remove dormant accounts.By establishing an acceptable timeframe for disabling or removing inactive IAM identities within your cloud providers and CI/CD platforms, you can better enforce the deactivation of identities that surpass this predetermined period of inactivity.There are lots of unique ways to approach the issue of deleting inactive identities in the cloud, such as this automated approach from AWS Identity Center.
• Federate Identity Management: Use centralised IdPs wherever possible; avoid local user accounts.Ensure that users no longer requiring access are disabled or removed and that IAM security policies align with the organisation’s standards.
• Disable Self-Registration: Leaving self-registration enabled is like leaving the front door unlocked. Anyone can walk in, and they might bring trouble with them. Many platforms, by default, grant new users baseline permissions that could expose sensitive features or data. Unless your application is explicitly designed for open user access, always disable self-registration. This reduces the attack surface and ensures only vetted users can create accounts, maintaining tighter control over who gets in and what they can access.

The Bigger Picture: IAM as a Security Priority in CI/CD

We’ve established that Identity & Access Management isn’t just a backend concern. IAM is a core part of securing your software delivery pipeline. As CI/CD systems continue to evolve, a single misconfigured credential from a year ago, or an overly permissive role for a junior engineer, could open the door to serious breaches, often with immediate impact.

This post is just a glimpse into what’s covered in Cloudsmith’s OWASP CI/CD Security Guide. Inside, we break down each control in depth, discussing the practical CI/CD risk mitigation strategies, as well as exploring any real-world case studies to help you strengthen your software delivery process from the inside out.

Download your free copy of the OWASP CI/CD Security Guide today and take the next step toward securing your CI/CD pipeline from the inside out.

Liked this article? Don\'t be selfish (:-), share with others:   Tweet