Blast radius analysis
Blast radius analysis answers "if this resource is compromised, what else is reachable?" It is the inverse of attack path analysis. Teams reach for it after supply chain compromises (axios, xz, Trivy) to answer the first question of response: where are we exposed? A useful blast radius tool returns every affected pod, namespace, cluster, and tenant in seconds, ordered by severity. The same mental model works for change management: "if we remove this ClusterRoleBinding, what breaks?"
Blast radius and attack path
Attack path: "what paths lead to cluster-admin?" (incoming).
Blast radius: "if this compromised pod is the entry, what is downstream?" (outgoing).
Same graph, opposite direction. Both are foundational queries in a graph-based KSPM platform.
When blast radius is the right question
- Supply chain compromise. A popular image or package is reported as malicious. How many pods pull it?
- Credential leak. A service account token was posted in a Slack channel. What can that token do?
- Suspicious runtime behavior. A pod shell-spawns. If compromised, what can it reach?
- Change planning. We want to delete a ClusterRoleBinding. What currently uses it?
- Tenant isolation audit. A pod in tenant A crashes. Could it reach tenant B's data?
What a useful blast radius report contains
- Every pod affected by the event (image, credential, role).
- The namespaces and clusters those pods live in.
- For each pod, the privileges reachable from that foothold (secrets, other pods, the cluster API).
- For each pod, the customers or tenants exposed (for multi-tenant platforms).
- A prioritized remediation list: which pods to stop first, which secrets to rotate next.
Blast radius in Juliet
Every resource in Juliet's graph has a blast radius query endpoint. When the axios npm compromise was disclosed, customers ran one query and received the full list of affected pods across every cluster they operate. Without graph-based blast radius the same answer comes from hours of kubectl plus scanner correlation.
Frequently asked about blast radius analysis
How is blast radius computed?
Graph traversal from the source node outward, following every edge type that represents a "reachable" relationship: runs, mounts, reads-secret-of, assumes-sa, can-create-pod, and so on. Neo4j and similar property-graph databases do this efficiently.
Does blast radius include network connectivity?
The good implementations do. A complete blast radius factors in NetworkPolicies, Services, Ingresses, and service-mesh authorization, since compromise of pod A does not matter if pod B is network-isolated from it.
Can blast radius be too conservative?
Yes. A raw graph shows every theoretical path. A tuned platform weights paths by exploitability, since some capabilities ("can create pod with arbitrary ServiceAccount") are trivially exploitable while others ("can impersonate user if webhook allows") are conditional.
What is the first query to run after a supply chain incident?
"Which running pods pull image X (or package Y)?" That is the starting set. From there, expand outward to permissions and data.
Can blast radius span clusters?
If the platform ingests every cluster into one tenant graph, yes. Cross-cluster blast radius is useful for shared registries, shared Vault instances, and multi-cluster service meshes.
See this in your clusters
Juliet maps your Kubernetes security posture as a graph and ranks findings by reachable attack paths, not just CVSS. Free tier, five-minute setup, no credit card.