# The reachability audit — twelve questions per endpoint **Ships with:** The Assurance Line. **Who this is for:** whoever can read your service definitions and your gateway config. Platform engineers, application security, and the architects who will be asked whether "it's on the internal network" is an answer. **Who this is not for:** anyone looking for a scanner. This is a reading exercise, not a tool. **Time:** an afternoon, for as many endpoints as you can list. --- ## What this looks for One shape: **the system granting on the basis of what reached it, rather than on the basis of who asked.** CVE-2026-9198 is the extreme, published version — a login endpoint that, in the vulnerability record's own wording, mints superuser tokens to any network caller. The record is worth reading in full and it is linked below. But the shape is not rare and it is rarely that obvious. It usually looks like a service that was correct when only one thing could reach it, and is now reachable by an agent that did not exist when the boundary was drawn. **Reachability is not identity.** These twelve questions ask, endpoint by endpoint, whether your system knows the difference. --- ## How to run it List every endpoint an agent in your estate can call. Include internal ones — *especially* internal ones, since that is where the assumption lives. For each, answer the twelve questions. **Answer them from the code and the config, not from memory and not from the design document.** The gap between the design and the deployment is the thing you are looking for. Score each question: **Y** (yes, demonstrably), **N** (no), or **?** (nobody could tell me today). **A "?" counts as an N.** It is not a smaller problem; it is the same problem plus an unknown. --- ## The twelve questions ### Identity — does the system know who is calling? **1. Does this endpoint require a credential at all, or does arrival suffice?** The base case. Include endpoints protected only by network position. **2. If a credential is required, does it identify a unique principal — or a role, a team, or a shared service account?** A credential that four things share does not identify a caller. It identifies a group, and the record you get afterward will say so. **3. Could the calling agent's credential have been obtained by anything else that can reach the network segment?** Static secrets in environment variables, files, or images all fail this. So does anything an agent can read and re-present. **4. Does the endpoint distinguish an agent acting for itself from an agent acting for a user?** If both arrive as the same principal, the delegation is invisible at the point of enforcement, and no downstream record can reconstruct it. ### Authority — does the grant have edges? **5. Is the grant scoped to specific actions, or is it "authenticated therefore permitted"?** **6. Does the grant have a stated expiry enforced at this endpoint** — not just a token TTL set somewhere upstream? **7. Can the caller widen its own grant** by asking for more, re-authenticating, or invoking a second endpoint that issues a broader credential? This is the escalation path most audits miss, because each endpoint is correct on its own. **8. Is the grant attenuating** — can a caller pass a *narrower* authority to something downstream, and does the downstream honor the narrowing? If authority is passed whole or not at all, every hop runs at the widest scope on the chain. ### Evidence — could you reconstruct it afterward? **9. Does a call here produce a record naming the principal, the action, and the authority relied on?** **10. Would that record survive the credential being rotated or the account being deleted?** A record that resolves an identity by lookup, rather than recording it, degrades to nothing. **11. Could you answer "who authorized this?" about a single call from six months ago,** using only what is retained today? ### Revocation — can you stop it? **12. If you revoked this caller's authority right now, what is still in flight that would land anyway?** Cross-reference with the time-to-safe-state protocol in the time-to-safe-state protocol — questions 12 and ① – ④ are the same question asked from two ends. --- ## The scoring sheet | Endpoint | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | N/? count | |---|---|---|---|---|---|---|---|---|---|---|---|---|---| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ### Reading it **Read the columns.** One endpoint failing question 7 is a finding about that endpoint. Question 7 failing everywhere is an architecture. - **Q1–Q4 failing** → the estate has no concept of an agent principal. Everything downstream of that is cosmetic, and this is the only thing worth fixing first. - **Q5–Q8 failing** → you have identity but not authority. Callers are known and unbounded. - **Q9–Q11 failing** → you may be well controlled and unable to demonstrate it. Different problem, different fix, and it usually surfaces at the worst possible moment. - **Q12 failing** → go and measure it rather than estimating it. The time-to-safe-state protocol has the method. **If the honest answer to questions 1 through 4 is "nothing" for any endpoint, you have the shape the CVE describes**, whatever framework you are on and whether or not anyone has published a record about it. --- ## What this audit does not tell you It does not tell you that you are exploitable. It tells you that a class of grant is being made on the basis of reachability, which is a precondition, not an exploit. Treat a failing column as a question to answer, not an incident to declare. It also gives you no rate and no comparison. The five products discussed in the accompanying episode were selected by researchers, not sampled, and nothing here says how common any of this is. It says the shape was reachable in five independent places — which is a different and more useful claim. --- *Vikram Jha · The Assurance Line · vikramjha.work* *Free to use, copy, and adapt inside your organization. No attribution required, nothing gated.*