Secrets Tend to Live Longer Than the Systems They Belong To

Credentials have a habit of surviving longer than the systems, projects, and people they were originally created for.

We see this repeatedly during penetration tests.

API keys in old configuration files.

Cloud credentials in deployment scripts.

Database passwords in application settings.

Tokens embedded in JavaScript bundles.

Connection strings inside CI/CD pipelines.

Secrets committed to Git years ago and later removed from the current version of the code.

The application may have changed.

The developer may have left.

The project may have been retired.

But the credential can still work.

That’s where things get interesting.

Deleting a secret isn’t the same as invalidating it

One of the easiest mistakes to make is assuming that removing a credential from source code fixes the problem.

It doesn’t.

If a secret was ever exposed, the safest assumption is that it may have been copied.

Removing it from the latest commit only removes the visible reference.

The credential itself still exists unless it has been rotated or revoked.

Git makes this especially important because repositories preserve history.

A developer may remove an API key today, but an attacker who gains repository access may simply look through previous commits and find the original value.

The same principle applies to

• Build logs

• Deployment artifacts

• Container images

• Backups

• Shared drives

• Old tickets

• Documentation

• Chat messages

• Configuration archives

Once a credential has been copied into another system, tracking every location becomes difficult.

Rotation is usually safer than trying to prove every copy has been deleted.

Client-side applications create another problem

Web and mobile applications can also expose secrets unintentionally.

Anything delivered to the browser should generally be treated as accessible to the user.

If an API key, token, or credential is included in JavaScript sent to the browser, a user can inspect it.

Obfuscation doesn’t fundamentally change that.

The same issue applies to mobile applications.

APK and IPA files can be analyzed.

Strings can be extracted.

Configuration files can be inspected.

Network traffic can be observed.

Hardcoded credentials inside a mobile application should be considered recoverable.

The real question then becomes what that credential can do.

A key restricted to a narrow public API may have limited impact.

A cloud credential with broad IAM permissions is a very different story.

CI/CD systems are especially valuable targets

Modern deployment pipelines often sit in the middle of everything.

They need access to source code.

They may hold cloud credentials.

They deploy applications.

They interact with registries.

They can access production environments.

That makes CI/CD platforms extremely useful to an attacker.

If a pipeline contains long-lived credentials with broad permissions, compromising that pipeline can become a path into production even if production itself is well protected.

The same risk exists with automation accounts.

A credential created to make deployment easier can quietly become one of the most powerful identities in the environment.

Secrets should have a limited blast radius

The goal shouldn’t just be hiding credentials better.

Assume a secret will eventually leak.

Then ask what happens.

Can the credential access one service or twenty?

Can it read data or modify it?

Can it create new credentials?

Can it reach production?

Can it assume another role?

Does it expire?

Can its use be monitored?

That’s where short-lived credentials, scoped permissions, workload identities, and proper secret-management systems help.

The less authority a credential has, and the shorter its lifetime, the less useful it becomes after compromise.

The key question

When we find exposed credentials during a pentest, one of the first questions isn’t simply

“Where was this secret stored?”

It’s

“What does this credential still give us access to?”

Because a five-year-old password in a forgotten repository isn’t particularly interesting if it was disabled four years ago.

A five-year-old password that still provides production access is a completely different situation.

That’s why secret management isn’t just about preventing credentials from appearing in source code.

It’s also about lifecycle.

Creation.

Storage.

Permissions.

Rotation.

Monitoring.

And eventually, revocation.

A secret that no longer has a legitimate reason to exist shouldn’t continue working simply because nobody remembered to turn it off.