This deep dive expands on the Loop Asia conversation with Chuck Herrin, Field Chief Information Security Officer at F5.

Ask a CTO how many web applications the company runs, and they'll answer in minutes — there's an ingress point, a load balancer, a DNS record, something visible. Ask how many APIs the company exposes, and the honest answer is usually: nobody knows. Chuck Herrin, Field CISO at F5, described a friend at a financial services firm who insisted his company didn't really have any APIs. Herrin held up his phone and pointed at three of the friend's own mobile apps. Every one talks to a backend through an API. The friend hadn't lied — he'd just never connected "we have mobile apps" to "we have an API attack surface."

That gap, between what an organisation believes it exposes and what it actually exposes, is the real subject here. For a Technical Champion building a governance case, "we don't have full visibility" doesn't survive a board conversation.

Why there's no single lens

Herrin resists the instinct to buy one tool and call discovery solved. He described three lenses, each catching a different slice of the problem and blind to the others.

Code-level discovery finds APIs defined in your own codebase — the most complete picture of intentional architecture. It only sees what your internal teams built. Anything wired in through a third-party SDK, or a team that bypassed the standard build pipeline, doesn't show up.

Traffic-level discovery watches what's actually moving across the wire. This is where attacks happen, so it's also where protection lives: schema validation, rate limiting, anomaly detection. But it only sees what's actively being called. A deployed, reachable API that's simply not in current use is invisible here.

External/outside-in discovery scans from an attacker's perspective on the internet, finding what's reachable regardless of whether it's documented or intended to be public. This is the lens that catches shadow APIs and forgotten endpoints nobody remembers standing up.

No single lens gives you the full inventory; you need a methodology for reconciling all three, not a product that claims to solve discovery alone.

The zombie version problem

One failure mode is worth isolating: organisations version their APIs — v3, v4, v5, v6 — and publicise the current one, but v3 through v5 often stay deployed and listening because nobody scheduled the decommissioning work. Traffic monitoring won't flag them; legitimate business isn't calling them. They sit dormant until reconnaissance — not a legitimate user — finds the old door still unlocked. As Herrin put it, "your perimeter becomes your first line of defence instead of your last." The fix is a decommissioning discipline, not an afterthought nobody owns.

The complexity multiplier: environment sprawl

Herrin cited an F5 statistic: roughly 38% of F5's customers operate across six or more environments — on-premises, multiple public clouds, private cloud, in combination. A decade ago "going to the cloud" meant picking one; now it's all of them at once, usually separate teams making separate decisions over years, not one deliberate architecture. Every additional environment is another place APIs get stood up outside whichever team thinks it owns "the API inventory." Discovery can't be a one-time audit here — it has to run continuously, because the ground truth changes weekly.

Governance problem, not just a technical one

Herrin's definition of threat modelling doubles as a checklist: understand your assets, your actors, your interfaces, and your actions. Most security programmes handle assets and actors reasonably well. Few have a complete answer for interfaces — and an incomplete interface inventory means an incomplete threat model.

The tooling and methodology already exist. What's missing is someone senior who owns reconciling three lenses into one inventory and refuses to accept "we don't fully know what we're exposed to" as a steady state.