A leaked credential is also a topology problem

A leaked credential creates risk beyond the identity itself. Its real impact depends on the services and resources connected to what that credential can access.

Identity-local signals answer the first question: how risky is this credential or machine identity on its own? Is it plaintext? Guessable? Stale? Overprivileged? Production-exposed? Tied to an admin identity? Those signals matter because they identify the secrets and machine identities most likely to be abused.

But they do not answer the next question: what breaks if that credential is used?

That answer lives in the topology around the credential. A database credential may sit on one pod and unlock one datastore, but the operational blast radius extends to every service that depends on that datastore. Some of those services never hold the credential at all. Some may not even have a secret signal to score.

That is where identity-local signals and topology signals become two layers of the same blast radius: one tells you why the credential is dangerous, and the other tells you how far the damage can travel.

The Temporal cluster example

We built a small Temporal cluster to walk through the difference.

In that cluster, a Postgres credential was sitting in plain text on the temporal-server pod:

POSTGRES_USER=temporal
POSTGRES_PWD=temporal

It was the default credential that shipped with the environment and was never rotated.

Point a secret scanner at that setup and GitGuardian catches it immediately, correctly. It identifies the exposed credential and maps the secret's direct neighbors: the temporal-server pod that consumes the credential and the postgresql database it unlocks.

That is the identity-local view. It is accurate, and it is necessary. The credential is guessable, plaintext, and unrotated. It deserves a high-risk score before you know anything else about the environment.

But the blast radius does not stop at the pod and the database.

Go one hop further and order-worker can no longer advance a single order once temporal-server loses access to Postgres. temporal-ui also goes dark for anyone trying to observe or debug the incident. Neither service holds the credential, but both depend on the resource the credential unlocks.

A secret-centric view can show the exposed credential and its immediate relationships. The topology view shows the downstream services that fail because of it.

Why the identity score is still right

A scanner scores an identity by what the identity is and how risky it looks in context.

GitGuardian's NHI Governance walks AWS IAM, Entra, Okta, and Kubernetes. It finds the machine identities and secret managers behind them, then ranks those identities based on factors like admin rights, overprivilege, production exposure, and staleness.

That matters because machine identities now vastly outnumber human identities. By GitGuardian's own count, machine identities can outnumber humans by as much as 100 to 1. In a real environment, a few thousand machine identities can quickly become hundreds that are admin, stale, overprivileged, production-exposed, or tied to exposed secrets.

In the Temporal example, the Postgres credential earns its high score honestly. It is guessable, plaintext, and never rotated. All of that is true before you know anything about what depends on the database it opens.

The point is not that the identity-local score is wrong. It is that it is only one layer of the risk.

Where the two layers disagree

Most of the time, identity-local risk and topology risk point in the same direction. A plaintext admin credential is usually dangerous on its own and connected to something that matters.

The two layers split when a resource has a wide downstream blast radius but carries a weak secret signal, or no secret signal at all.

That creates a prioritization gap. A severity ranking has plenty to say about the exposed Postgres credential because there is a credential to score. It has far less to say about a load-bearing resource that does not have a leaked secret attached to it.

The only way to find that second kind of risk is to follow each identity out to the services leaning on what it reaches.

Walking the credential downstream

Anyshift keeps a versioned graph of cloud, Kubernetes, IaC, code, and the edges between them. For the Temporal cluster, we asked the graph to keep going past the secret's direct neighbors.

The direct path was straightforward: the plaintext Postgres credential sits on temporal-server, and temporal-server uses it to reach the postgresql database.

The downstream path is where the blast radius appears.

order-worker runs the durable order-fulfillment workflows. If the state store is unavailable, orders customers already placed stop moving. temporal-ui is also affected, which means the interface an on-call team may use during the incident becomes unavailable too.

Neither order-worker nor temporal-ui touches the credential directly. A secret-centric view does not list either one as a direct neighbor. But both are part of the operational blast radius because they depend on the service and datastore the credential unlocks.

There is also a second-order problem. Rotating the leaked credential is the correct response. But in this setup, the value lives in a plaintext environment variable with nothing in front of it. Rotating it restarts temporal-server, which can then restart or disrupt every pod down the chain.

In other words, the fix has its own blast radius.

Example: Redis-cart and the checkout blast radius

The Temporal cluster is intentionally small. Order fulfillment is the durable back half of a store, and in our demo cluster that back half runs only two services deep.

The customer-facing front half is where a datastore compromise can fan out more widely.

To show that difference, we ran the same walk on a second cluster: the Online Boutique demo. This time, we followed the cart store downstream from redis-cart.

The result was more differentiated.

checkoutservice calls cartservice first. When the cart goes down, checkout goes down with it, and customers cannot complete a purchase.

frontend is affected too, but it degrades differently. It talks to six other services on its own, so browsing, currency, ads, and recommendations can keep serving even while the cart page is broken.

recommendationservice and adservice never notice.

The result is not a single flat outage. It is four services down hard, four degraded, and two untouched. No single number on the credential carries that split.

That is the value of the topology layer. It shows not only that a resource matters, but how failure propagates across the application.

The low-severity identity with the widest blast radius

We then ran that ranking across every flagged identity in both clusters. First, we scored each one the way a secret or identity scanner would. Then we scored each one by what its resource actually reaches downstream.

Most of the rankings lined up.

The admin token, the bootstrap token, and the Postgres credential all rank high either way. They are risky as identities, and they are connected to important resources.

Then there is redis-cart.

A secret scanner has almost nothing to flag on it because the cart store ships without a password. There is no leaked credential to rotate. There is no secret sitting on the resource to score. From a secret-centric view, it belongs near the bottom of the queue.

But by downstream reach, redis-cart is the widest application-layer failure in either cluster. It drives the checkout cascade described above. The identity with nothing to steal opens the most services, and it is the one a severity score alone sends to the bottom of the queue.

That is where identity-local scoring and topology scoring disagree most clearly.

The honest limits of the graph

The graph only reaches as far as what it has ingested.

On the Temporal cluster, the blast radius stops at two services because two services are all that cluster has. If another workload reaches the database over a path the graph has not mapped, that workload is invisible to the topology view, just as it is invisible to the scanner.

That limitation matters. The graph is not guessing at the rest of the environment. It ranks based on what it has actually traced across cloud, Kubernetes, IaC, code, and dependency edges.

That makes the topology score useful, but not magical. Its accuracy depends on the completeness of the graph.

How the two scores work together

Neither score replaces the other.

The scanner puts real credentials and risky machine identities on the list. It ranks them by exposure, privilege, staleness, and other identity-local signals. For most of the queue, that is the right starting point.

The graph adds what the scanner cannot see on its own: how far a compromise travels once an identity reaches a resource, and which load-bearing resources matter even when no secret is present.

On the Temporal cluster, that means the plaintext Postgres credential is both a high-risk secret and a source of downstream service failure. On the Online Boutique cluster, it means redis-cart becomes visible as the widest application-layer blast radius even though there is no credential for a secret scanner to flag.

Together, the two layers give teams a better priority order: fix the credentials that are dangerous, and understand which identities and resources can break the most when they fail.