Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

Zombie APIs are API versions or endpoints that were once known and documented, but were never properly retired. A team ships v2 of an API, tells everyone to migrate, and assumes v1 is dead. In reality, v1 is still running on a server somewhere, still accepting requests, and still connected to production data. This is different from unmanaged APIs, which were never documented in the first place. Zombie APIs were documented once.

Every CISO managing an API estate has heard of Broken Object Level Authorization (BOLA) and Broken Function Level Authorization (BFLA). What is harder to pin down is what these vulnerabilities actually cost the business when they go unaddressed. Board members and finance teams want numbers, not acronyms, and that gap between technical risk and financial risk is where security budgets get lost. BOLA has held the number one spot in the OWASP API Security Top 10 since the list was created in 2019.

Every payment flow your organization runs, from card authorization to ACH transfers to embedded lending to open banking consent, is now an API call. That’s good for velocity. It’s also why payment APIs sit at the top of the attack surface for financial services and enterprise SaaS platforms handling money movement.

APIs are now the primary attack surface for most applications. Industry research consistently shows that the large majority of organizations have experienced an API security issue in the past year, and a significant share have delayed a rollout because of API security concerns.

Every enterprise security leader is being asked the same question by their board: are we secure against AI risk? Most cannot answer it with confidence, and the reason is rarely a lack of tools. It is a lack of visibility. AI has spread through enterprises faster than almost any technology before it. Developers wire large language model APIs into internal tools. Business teams stand up copilots and chat assistants. Data science teams build retrieval pipelines against customer and financial data.

An Australian man named Andrew asked his personal AI agent, built on the open-source OpenClaw framework and powered by Anthropic’s Claude model, to book him into a popular morning gym class. According to ABC News, the class was full, so the agent started looking for a way around that. It found that the gym’s booking API let bookings be pushed far further into the future than the website’s own interface allowed, a limit that turned out to exist only on the front end.

If you’re evaluating API discovery tools right now, you’ve probably already seen a handful of demos that look nearly identical: a clean dashboard, an inventory count, maybe a risk score. What’s harder to see in a 30-minute demo is whether that inventory reflects what’s actually running in production, or just what the vendor’s connectors happened to catch on setup day.

Most coverage of software supply chain attacks focuses on the entry point: the poisoned package, the compromised maintainer account, the malicious commit. That’s the part that makes headlines, but it’s rarely the part that causes the damage. A malicious package sitting on a developer’s machine doesn’t exfiltrate anything by itself.

Framework choice isn’t really about syntax or GitHub stars. It’s a multi-year commitment that shapes architecture, team habits, hiring, and how painful your next migration will be. Frameworks decide your architecture by default, whether you choose it or not. Some frameworks default to synchronous request handling; others assume non-blocking IO from day one. Some nudge you toward a monolith; others push you toward services that split naturally.