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

Chuck Herrin was building a digital bank in Dallas when he found a vendor relationship that should worry anyone who assumes "the API integration" is a solved problem. The vendor served the US housing market; to support the products Herrin's bank bought, it exposed roughly 30,000 API endpoints to the internet. Of those, 6,000 were relevant to the purchase — Herrin's workflow needed maybe two dozen.

He went back to the vendor: I don't want the other 5,972 endpoints reachable from the outside world, because my data sits behind them — not behind the 28 he used, but all 6,000, because that's how the system was built. Nobody had drawn a smaller door around Herrin's data specifically.

That's the shape of a risk most companies never examine, because it doesn't look like a decision. It looks like a contract you signed and an integration that shipped on schedule.

The assumption nobody states out loud

OWASP added "unsafe consumption of APIs" to its API Security Top 10 for exactly this reason — a pattern common enough to finally get named. Once you've vetted a vendor at procurement, the instinct is to stop treating their interface as a live risk. "I'm sure it's covered in our contract or something," is how Herrin put it. The honest version is I haven't checked.

His sharper line: you expose an interface to exchange data, then you're shocked when data gets exchanged. The vendor's API did exactly what it was built to do — so did the 5,972 endpoints Herrin didn't need, just for whoever else found them. An API working exactly as designed is not evidence of safety. It's a description of the blast radius.

Why "we vetted them" isn't a control

Treating third-party risk as a one-time procurement gate — a questionnaire, a SOC 2 report, a signature — mistakes a point-in-time check for a standing control. Herrin's framing breaks it into questions most vendor relationships never get asked: what third-party APIs is your application actually calling (not what the integration doc says); what data crosses that interface, in both directions; how sensitive is that data; and what else does the vendor expose behind the same door your data sits behind.

The negotiation most companies never have

Herrin's Dallas response — ask the vendor to shrink the surface to what you use — is repeatable, not a one-off. Can the vendor scope your credentials to the 28 endpoints you call, instead of the 6,000 they expose? Can they put you behind a gateway that enforces that scope? A "no" is material information about the vendor's security maturity, and a data point for the next renewal.

This reframes vendor due diligence from a questionnaire into an architecture review: not just whether the vendor is secure, but how large a door they're opening onto your data.