Latest / Cybersecurity Business with Fexingo: Security Companies, Breaches, and Enterprise Defense / Why CISOs Are Moving to Vendor-Native API Security
Transcript
- Lucas: So here's a stat that stopped me this week: by mid-2026, almost sixty percent of enterprises are running more than two hundred APIs in production. But the bigger number is this — only about one in three of those companies has any dedicated API security tool watching those endpoints. That gap is driving a pretty big shift in how CISOs are thinking about API protection. Luna: I've seen that trend too. It used to be you'd buy a standalone API security platform — something from Salt, or Noname, or Wallarm — and bolt it onto your infrastructure. But I'm hearing more security leaders say they're leaning toward the API security features already built into their cloud providers. Lucas: Right. Vendor-native API security. It's not a new concept — AWS has had API Gateway and WAF for years, Azure has API Management with Defender for APIs, Google Cloud has Apigee and their Security Command Center integrations. But what's changed is the maturity of those native controls and the willingness of CISOs to trust them. Luna: What's driving that willingness? Is it just cost savings, or is there a genuine capability leap? Lucas: Both, honestly. On cost, if you're already spending six figures a year on AWS or Azure, adding native API security often comes at a fractional incremental cost compared to a third-party platform that could run you fifty to a hundred grand just to start. But the bigger driver is operational friction. Security teams are stretched thin. Adding another dashboard, another set of alerts, another vendor to manage — that's real overhead. Luna: So native security reduces complexity. But does it actually catch attacks as well as the dedicated tools? Lucas: That's the million-dollar question. I talked to a CISO at a mid-size fintech last month — they moved from a third-party API security tool to AWS's native WAF and Shield Advanced about eighteen months ago. He told me their detection rate for common OWASP Top 10 API threats — things like broken object level authorization, mass assignment, injection — actually improved. But he conceded they lost some visibility into more nuanced threats, like business logic abuse, where the dedicated tool had better behavioral baselines. Luna: So you're trading depth for breadth and simplicity. That sounds like a deliberate trade-off, not a clear win. Lucas: Exactly. And I think the calculus depends on your risk profile. If you're handling highly sensitive data — say, healthcare or payments — you might still want the dedicated platform's advanced machine learning models. But for a lot of enterprises, especially those with less exotic threat models, native controls are getting good enough. And good enough, plus integrated, plus cheaper, is a compelling combination. Luna: Let's talk about a concrete example. Capital One's 2019 breach — that was a misconfigured WAF that exposed an S3 bucket. That wasn't an API attack per se, but it's become the cautionary tale for cloud native security. If they had been using AWS's native API security controls properly, would it have been prevented? Lucas: It's a great case study. The attacker exploited a WAF misconfiguration that allowed a Server-Side Request Forgery — an SSRF — against the internal metadata service. At the time, AWS had WAF but not the kind of api level inspection that could have blocked that specific traffic pattern. Today, AWS's native tools include things like AWS WAF's Bot Control and API Gateway's built-in throttling and validation. A properly configured native stack in 2026 could absolutely block that SSRF vector. The lesson is less about which tool you use and more about whether you've actually configured it to enforce api specific protections. Luna: So the weakness is still human error, not the technology. That makes vendor-native security almost more dangerous in some ways — because it's easier to assume it's working when it's not. Lucas: That's exactly the concern. I've heard that from several analysts. When you buy a dedicated API security platform, part of what you're paying for is the vendor's expertise baked into the product — pre-built detection rules, threat feeds, and a team that lives and breathes API attacks. Native tools tend to be more configurable, which means they're more dependent on your team's skill to set them up correctly. And we know from survey after survey that most organizations don't have enough API security expertise in-house. Luna: That's actually a strong argument for keeping the third-party tool, at least as a complement. But I wonder if the market is already responding. I saw that Salt Security recently launched a 'native-aware' mode that sits alongside AWS API Gateway and just adds analytics — they're trying to compete by integrating with the native control plane rather than replacing it. Lucas: Yeah, that's a smart pivot. And it's happening across the board. Noname has similar integrations with Apigee. The message from the startups is: we don't need to own the enforcement point; we can observe the traffic that the native gateway already sees and augment it. That's a recognition that the cloud providers have won the platform battle. The question is whether there's still room for a overlay analytics layer. Luna: And what about the lock-in risk? If you go all-in on AWS native API security, you're deepening your dependency on that one provider. Is that a concern CISOs are raising? Lucas: Surprisingly, less than you'd think. I surveyed a dozen security leaders for a piece I'm working on, and most said they're already locked into one or two clouds anyway. The marginal lock-in from API security is negligible compared to the lock-in from compute, storage, and databases. One CISO told me, quote: 'I'm not afraid of being stuck with AWS security tools. I'm afraid of having five different security tools that don't talk to each other.' Fragmentation is the bigger enemy. Luna: That's a really honest take. So the trend seems to be: consolidate around the cloud provider's native security for the baseline, and maybe keep one specialist tool for the outliers. That's what I'm seeing in practice too. Lucas: By the way, this kind of deep-dive into evolving security architecture — if these conversations are useful for what you're building or running, know that we keep this show ad-free thanks to listeners who chip in at Buy Me a Coffee. It's a small way to support the research and prep that goes into each episode. The link is buy me a coffee dot com slash fexingo — all one word, lower case. And genuinely, whether you contribute or not, we're glad you're here. Now back to the native vs. bolt-on question — Luna: And we really do appreciate that. It keeps us independent. So Lucas, you were saying fragmentation is the bigger enemy — how does that play out for a company running multiple clouds? Lucas: Right, multi-cloud is where the native approach starts to break down. If you're on AWS and Azure, you'd have to manage two different native security consoles, two sets of policies, two alert formats. That's actually the strongest remaining argument for a third-party API security platform — it gives you a single pane of glass across clouds. A CISO at a large retailer told me they evaluated going native on each cloud and decided against it because their team would need to be experts in three different API security systems instead of one. Luna: So the best fit for native API security is probably the single-cloud organization, especially one that's already heavily invested in that cloud's ecosystem. And the best fit for third-party is multi-cloud or organizations with very specialized security requirements. Lucas: Exactly. And there's a middle path: use the native controls for enforcement — like rate limiting, authentication, schema validation — and route traffic to a third-party analytics engine for detection. That's the architecture I'm seeing more vendors recommend. It keeps enforcement fast and cheap in the cloud, while centralizing detection and response. Luna: That hybrid model seems like the pragmatic answer for 2026. But I wonder how it scales. If you're processing billions of API calls a month, routing every request through an overlay analytics pipeline could get expensive and introduce latency. Lucas: That's a real concern. Some of the overlay tools use sampling or statistical analysis rather than inspecting every request, which reduces cost but obviously reduces coverage. The trade-off between comprehensive visibility and operational cost is going to be a defining debate in API security over the next year or two. I think we'll see more innovation in how to do cost-effective, high-fidelity detection at scale — maybe using lightweight sidecar proxies that only flag anomalies. Luna: It reminds me of the early days of endpoint detection and response. Everyone had an agent, then everyone consolidated onto the os native security features, and now you see a hybrid with Microsoft Defender for Endpoint supplemented by a specialist EDR for the hard cases. API security seems to be following that same maturity curve. Lucas: That's a great parallel. And if that trajectory holds, we'll see the native platforms catch up further over the next few years. The cloud providers have massive R&D budgets and see API security as a competitive differentiator. Google Cloud's Apigee already includes API security analytics that rival some standalone tools. AWS is investing heavily in its API protection capabilities. The gap is closing. Luna: So for a CISO making a decision today, what's the one piece of advice you'd give? Assuming they're not at a high-risk financial institution or a healthcare provider. Lucas: I'd say start by auditing your API inventory — most organizations don't even know how many APIs they have, let alone which ones are exposed to the internet. Then, if you're on a single cloud and your APIs are mostly standard RESTful web APIs, seriously evaluate the native security controls first. They may cover eighty percent of your needs out of the box. Reserve budget for a specialist tool only if you have specific gaps — like protecting GraphQL endpoints, or if you need deep behavioral analytics for business logic attacks. Don't assume the expensive third-party tool is automatically better. Luna: And what about the human factor? The native tools need skilled configuration. Is that a dealbreaker? Lucas: It's a risk, but it's manageable. Most cloud providers offer managed services or professional services to help set up the security baseline. And there's a growing ecosystem of third-party consultants who specialize in cloud-native security configurations. My view is that the configuration risk is declining as the tools get more opinionated and provide better guardrails. AWS, for instance, now ships with a set of recommended API security rules that align with the OWASP API Security Top 10. You can enable them with a few clicks. Luna: That's a big improvement from even two years ago. So the message to listeners: if you haven't looked at your API security posture lately, now might be the time — especially if you're already paying for cloud native security features you're not using. Lucas: Exactly. And that's where we'll leave it. Next episode, we're going to look at something I think is equally overlooked: how enterprise security teams are handling API security in serverless environments. That's a whole different beast. Until then.