TL;DR: Unosecur’s analysis of the 2016 Uber breach finds that hardcoded AWS credentials in GitHub code let attackers reach S3 and steal sensitive user data. IAM fails when credential lifecycle governance stops at login and never extends into code, secrets, and revocation.
At a glance
What this is: This is an IAM analysis of the 2016 Uber breach showing that hardcoded cloud credentials turned code into an access path to sensitive data.
Why it matters: It matters because IAM teams must govern secrets lifecycle, not just authentication and roles, or credentials embedded in code can bypass the controls they assume are in place.
👉 Read Unosecur's analysis of IAM failures when credentials are embedded in code
Context
Identity and access management is usually treated as a control plane for users, but this article shows how that model breaks down when access credentials are embedded in source code. In that situation, the identity boundary shifts from login to repository, and the real governance problem becomes secrets handling across the development and deployment lifecycle.
The 2016 Uber breach is the concrete example used in the article: attackers found hardcoded AWS credentials in GitHub code and used them to access Amazon S3 data. That pattern is typical of weak IAM practice, not an edge case, because the control failure sits in credential storage, privilege scope, and revocation discipline.
Key questions
Q: What breaks when hardcoded credentials are left in code or configuration files?
A: Hardcoded credentials break the assumption that access can be rotated, revoked, and audited on demand. Once a secret is embedded in code or config, it is easy to copy, hard to trace, and often reused across environments. That turns a single secret into a durable access path that is difficult to contain after exposure.
Q: Why do hardcoded credentials create more risk than many teams expect?
A: Hardcoded credentials create risk because they are easy to copy, hard to inventory, and often survive long after the system that used them changes. Once embedded in code or scripts, they can be reused outside intended scope and are difficult to revoke everywhere at once. That makes the real problem lifecycle persistence, not just initial exposure.
Q: What are the signs that an IAM program is not keeping pace with governance needs?
A: Common signs include frequent manual access reviews, slow deprovisioning, inconsistent permissions across systems, and weak visibility into who still has access. If role changes do not reliably trigger permission updates, or if audit evidence is assembled manually, the program is likely operating as fragmented point controls rather than a governed identity lifecycle.
Q: Should organisations treat secrets scanning as part of IAM or AppSec governance?
A: Both. Secrets scanning is an AppSec control because it finds leaks in code and pipelines, but it is also an identity control because the artifact being exposed is a credential. Organisations get better outcomes when they tie scanning to ownership, rotation, and revocation workflows instead of treating it as a standalone developer tool.
Technical breakdown
Why hardcoded credentials turn code into an access path
Hardcoded credentials collapse the separation between application code and identity proof. Once a secret is written into a repository, the repository becomes a credential distribution channel, whether the code is public, shared internally, or copied into build artefacts. The important security failure is not the code itself, but the fact that the credential now exists outside governed secret storage and can be reused wherever the token or key is trusted. That bypasses normal IAM intent because authentication still succeeds, but the wrong place now holds the authenticator.
Practical implication: Treat source code as an untrusted secret sink and block credential storage before it reaches repositories.
How IAM scope and revocation failures amplify exposure
IAM risk grows sharply when embedded credentials are tied to broad permissions and no tight expiry or revocation process exists. A credential with access to storage, APIs, or administrative functions turns a single leak into a large blast radius. In practice, the problem is lifecycle mismatch: code changes slowly, but secrets can be copied instantly and remain valid until someone notices and replaces them. That means traditional account administration is not enough if the credential outlives the context in which it was created.
Practical implication: Bound each credential to the smallest possible scope and revoke or replace it as soon as it appears outside approved storage.
Why auditing and detection have to extend beyond authentication
Authentication logs alone do not explain how a credential escaped governance. Teams need visibility into secret creation, storage, reuse, and exposure in repositories, CI pipelines, and deployment artefacts. In this pattern, the meaningful audit question is not only who authenticated, but where the authenticator was copied, referenced, and consumed. Without that visibility, the organisation discovers misuse only after the secret has already become a valid access path for an attacker.
Practical implication: Correlate code scanning, secret discovery, and access logs so exposed credentials can be identified before they are exercised.
Threat narrative
Attacker objective: The attacker’s objective was to use leaked cloud credentials to reach sensitive customer data stored in Uber’s cloud environment.
- Entry occurred when attackers obtained access to Uber’s GitHub code repository and located hardcoded AWS credentials inside source code.
- Credential access followed because the embedded access keys were valid authenticators tied to a broad cloud identity with usable permissions.
- Impact came when those credentials were used to reach Amazon S3 and steal sensitive user data from the storage environment.
Breaches seen in the wild
- Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
- Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Hardcoded credentials create a governance boundary collapse, not just a coding mistake. The article shows that IAM controls fail when the secret is placed in code because the credential leaves the managed identity plane and enters an uncontrolled distribution path. That breaks the assumption that secrets live only in governed systems, and it makes source control a security boundary whether teams intend it or not. Practitioners should treat code repositories as part of the IAM attack surface.
Secrets lifecycle governance is the missing control layer in many IAM programmes. Authentication and authorization can be sound while still leaving long-lived keys in places that no access review will ever inspect. The result is an identity control gap where a valid credential outlives the intent behind it, which is why lifecycle management must cover issuance, storage, rotation, and revocation together. The practitioner conclusion is that IAM scope must include secret placement, not just login flows.
The most dangerous part of embedded credentials is the mismatch between change speed and revocation speed. Code can be copied, branched, and deployed faster than most governance processes can respond, so exposure often exists before anyone notices it. That is why the real risk is blast radius, not merely leakage. Teams need to assume that once a key is written into code, it may already be operationally compromised.
Runtime trust should never depend on a static secret hidden in source code. Cloud access tied to a plaintext key is structurally fragile because it cannot express context, ownership change, or immediate offboarding. The article’s breach example reinforces that secrets should be treated as disposable access instruments, not durable identity artefacts. Practitioners should reframe credential management as continuous governance over where trust can exist.
Auditability must extend to secret presence, not just secret use. A control framework that only records successful authentication misses the earlier failure point where the credential was first exposed. The useful governance question is whether the organisation can prove where credentials are stored, who can retrieve them, and how fast they are invalidated when discovered. That is the minimum bar for credible IAM accountability.
What this signals
Secrets lifecycle is now an IAM control, not an adjacent hygiene task. When credentials can be copied into code, IAM must govern where authenticators may exist, how they are stored, and how quickly they are invalidated. Programmes that stop at authentication and role assignment will keep missing the real leakage point.
Hardcoded credentials create identity blast radius. A single embedded key can connect source control to cloud storage, deployment pipelines, and data access in one failure path. The practical consequence is that teams need a tighter relationship between repository scanning, secret revocation, and cloud permission review.
For practitioners
- Enforce secret-free source control Block commits that contain access keys, tokens, certificates, or other secrets, and scan repositories continuously for hardcoded credentials before code is merged.
- Move credentials into governed secret storage Store sensitive credentials outside application code and use controlled retrieval patterns so developers never need to embed live keys in source files.
- Shorten the lifespan of cloud credentials Replace durable access keys with short-lived credentials wherever possible, and define explicit expiry and revocation steps for every secret type.
- Limit each credential to narrowly scoped access Assign the smallest feasible permissions to every machine or application credential so a leaked key cannot reach broad storage or administrative resources.
- Correlate repository and access telemetry Combine secret scanning, code review, cloud audit logs, and IAM events so exposure is detected when a credential appears in code, not only after it is used.
Key takeaways
- Hardcoded credentials move the IAM failure point into code, where they are harder to govern and easier to reuse.
- The Uber example shows how a single embedded AWS key can expose cloud storage and sensitive customer data.
- The control that matters most is secrets lifecycle governance, including storage, scope, rotation, and rapid revocation.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Hardcoded secrets in code are a direct secret leakage problem. |
| NHI-07 — Long-Lived Secrets | The breach pattern depends on durable credentials that remain valid after exposure. | |
| NHI-10 — Human Use of NHI | Humans placing or reusing machine secrets in code creates the control failure described here. | |
| Recommendation — Scan repositories for exposed secrets and revoke any credential found in code immediately. Replace long-lived keys with short-lived credentials and enforce expiry by default. Prevent developers from handling production secrets directly in application source and build paths. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | IA-5 covers authenticator issuance, storage, and revocation for leaked cloud credentials. |
| Recommendation — Apply authenticator management controls to rotate, revoke, and store cloud secrets securely. | ||
| CIS Controls v8 | CIS-5 — Account Management | Account and credential governance is central when exposed keys can still authenticate. |
| Recommendation — Track every machine credential under account management and remove unused or exposed access promptly. | ||
| MITRE ATT&CK | TA0006; TA0010 — Credential Access; Exfiltration | The breach path moves from exposed credentials to data theft. |
| Recommendation — Map hardcoded secret exposure to credential access and exfiltration detections in your monitoring stack. | ||
Key terms
- Hardcoded Credential: A secret such as a password, API key, or token embedded directly in source code rather than retrieved from a secure vault at runtime. Hardcoded credentials are one of the most common and dangerous NHI vulnerabilities.
- Secrets Lifecycle: Secrets lifecycle is the management of credentials from issuance through rotation, revocation, and offboarding. It matters because a secret that is technically valid can still be operationally unsafe if its owner, purpose, or downstream access paths are no longer current.
- Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
- Authenticator Lifecycle Management: Authenticator lifecycle management is the governance of a credential from issuance to renewal, replacement, and retirement. For human identity programmes, it ensures that keys, smart cards, and certificates stay tied to the right user and are removed when the user, role, or device is no longer trusted.
What's in the full article
Unosecur's full article covers the operational detail this post intentionally leaves for the source:
- The specific Uber breach sequence, including how hardcoded AWS credentials were discovered in GitHub code
- The credential management changes the article associates with avoiding plaintext secrets in code
- The IAM and monitoring practices discussed as follow-on controls after exposed credentials are found
- The article's full explanation of why secrets management belongs inside IAM governance
Deepen your knowledge
NHI governance, identity lifecycle management, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on May 31, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org