OWASP CI/CD Part 6: Insufficient Credential Hygiene

This post, part six of our OWASP CI/CD Top 10 series, looks at some of the common risks associated with Insufficient Credential Hygiene. By better understanding the flaws that affect credential hygiene, we can better understand how even the most sophisticated pipelines were compromised.

What is Insufficient Credential Hygiene?

CI/CD systems rely heavily on credentials (application secrets, tokens, deploy keys, and more) to operate. These secrets move between services, repositories, environments, and human actors, creating a complex web of access points.

When these credentials are:

• poorly managed,
• overly permissive,
• hardcoded in code,
• or left unrotated,

they become prime targets for attackers. Once compromised, these secrets offer lateral movement opportunities to adversaries with the intention of directly accessing your code, infrastructure, and data.

Why is it so hard to get right?

The challenge lies in context and scale.

Secrets live in many places: code repositories, CI/CD configuration files, container images, build logs, and even in the runtime environment. They're used by humans, machines, and processes across different trust boundaries - each with their own associated requirements and risks.

Unlike a centralized authentication system, secrets management is often distributed, ad hoc, and invisible until breached.

Common credential hygiene pitfalls

Here are some of the most pervasive and dangerous practices seen in real-world CI/CD environments.:

1. Secrets accidentally committed to code
   Whether intentional or accidental, secrets committed to version control are a time bomb. Even if deleted from the latest branch, they remain visible in the commit history to anyone with access.
   
2. Overly-permissive credentials in pipelines
   CI/CD pipelines often use credentials to access source code, artifact repositories, cloud resources, and production systems. Without tight scoping (which limits what actions credentials can perform and what resources they can access) and context-aware permissions (which grant access only under specific conditions like IP Address, time of day, or workload identity) these credentials can become open doors for unauthorized access.
   
   Ask yourself:
   - Does each pipeline only access the secrets it needs?
   - Are secrets scoped to specific environments or job steps?
   - Can unreviewed code access production secrets?
   
   Where possible, organizations should enforce the principle of least privilege to credentials.
   
3. Secrets embedded in container image layers
   Build-time secrets (such as API tokens or SSH keys) can inadvertently remain in container image layers. Anyone with access to the image can retrieve them, even if they’re not meant to persist beyond the build.
   
4. Secrets printed to build logs
   Even a secure secret, once printed in plain text during a build, becomes a liability. Logs may be stored indefinitely, aggregated into third-party observability platforms, or exposed through dashboards.
   
5. Unrotated, long-lived credentials
   Static credentials that never expire are dangerous - especially in environments with high personnel turnover or external contractors. Without regular rotation, credentials accumulate risk with every day they remain active. Ephemeral credentials is a production best-practice that ensures credentials are short-lived.
   

Real-world breaches caused by poor credential hygiene

1. Travis CI & Public Repository Exposure

In 2021, Travis CI experienced a security issue where secure environment variables (type of secrets) were exposed during builds triggered by pull requests to public repositories. Even though secrets were encrypted in storage, they were made accessible during build execution, potentially leaving them susceptible to compromise by anonymous users issuing pull requests against public repositories. 

While the Travis CI team quickly patched the issue, it highlighted how even secure systems can leak secrets when trust boundaries are not well-defined. In this scenario, Travis CI has strongly recommended that both Public and Private Repository customers rotate their secrets on a regular basis. If possible, users affected in these scenarios should set expiration dates on those tokens or rotate their secrets regularly; this reduces the risk of old secrets being exploited.

2. Uber’s Double Breach via GitHub

Uber wasn't so fortunate. They experienced two major breaches tied to credential mismanagement.These breaches, detailed in the FTC’s Federal Register, highlighted a harsh reality:

When credentials leak, attackers don’t break in - they log in.

In both breaches, no sophisticated exploitation was needed, just access to secrets that had been mishandled and left vulnerable.

The 2014 Breach: A public repo exposure
In May 2014, attackers discovered an AWS access key that was accidentally committed to a public GitHub repository. The key granted full administrative access to Uber’s Amazon S3 datastore. As a result, the intruder accessed sensitive personal data of over 100,000 drivers, including:

• Unencrypted names and driver’s license numbers
• Bank account and routing numbers
• Social Security numbers

Uber didn’t detect the breach until September 2014 (four months later) and continued uncovering additional impacted users well into 2016.

The 2016 Breach: A private repo with public impact
In a second incident between October and November 2016, attackers gained access to Uber’s private GitHub repositories. This time, the intrusion was facilitated by a combination of weak security controls:

• Credential reuse by engineers across personal and professional accounts
• Lack of multi-factor authentication (MFA)
• No policies to prevent leaked or reused passwords

Attackers used compromised credentials (previously exposed in unrelated breaches) to access Uber’s GitHub repositories, where they found yet another AWS access key. This key unlocked Uber’s S3 storage once again - leading to the theft of:

• 25.6 million names and email addresses
• 22.1 million mobile numbers
• Over 600,000 driver’s license numbers

Most of this data was stored in unencrypted backup files collected prior to 2015.

Recommendations for sufficient credential hygiene in CI/CD

To mitigate these risks, organizations must adopt a proactive and layered approach to secrets management:

1) Map the credential landscape

• Continuous inventory where credentials are stored and used (across code, pipelines, and infrastructure).
• Classify & Tag secrets by sensitivity and exposure risk.

2) Classify secrets by sensitivity and exposure risk

• Scope each secret to the narrowest possible use case (per pipeline, environment, or job).
• Avoid shared credentials across teams or systems.

3) Prefer ephemeral credentials

• Use short-lived, automatically rotated credentials (such as IAM roles, OIDC tokens, Kubernetes Secrets).
• For static secrets, enforce periodic rotation and audit stale secrets.

4) Restrict credential usage context

• Bind secret usage to specific IPs, services, or identities.
• Block secrets from being used outside of intended pipelines or systems.

5) Prevent secret leaks in code

• Use tools like Git hooks, IDE plugins, and secret scanners to catch leaks before they hit the repository.
• Periodically scan historical commits for exposed secrets.

6) Secure console output

• Scrub secrets from build logs.
• Configure pipeline tools to redact or prevent printing sensitive data.

7) Clean artifacts thoroughly

• Inspect container images, binaries, and Helm charts for embedded secrets before deployment.
• Use dependency mapping to identify and visualize all software dependencies within your applications, such as a Docker image within a Helm chart that may contain sensitive credentials.

Download our free eBook

If you found this content helpful and want to dive deeper into securing your CI/CD pipelines, beyond credential hygiene best practices, be sure to check out our free Cloudsmith eBook on the OWASP Top 10 for CI/CD systems - download it here.

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