You Don't Actually Know What's Running In Your Own Environment

The average organization has 613 API endpoints running in production, according to a 2023 Imperva report. Ask most technology leaders how many APIs their organization has, and the number they give you will come from an inventory their developers submitted. Whether those two numbers match is a question most organizations have never seriously tested and probably never will.

The process that produces an API inventory is straightforward enough. Developers build APIs, teams document what they build, someone consolidates that documentation into a registry, and the registry becomes the organization's working picture of its API surface.

It informs penetration testing scopes. It gets presented to auditors. Security decisions get made against it. The problem is not the process. It never has been. The problem is the assumption embedded in it, which is that what developers submitted reflects what is actually running in production.

It rarely does.

Software moves faster than documentation today. APIs get created to solve immediate problems and registered later, or not at all. Third-party integrations introduce endpoints that nobody catalogued internally. Services get deprecated on the roadmap and quietly persist in production. Developers leave, and the institutional knowledge of what they built leaves with them.

None of this is negligence. It is the natural output of organizations that are optimizing for delivery speed without equivalent investment in visibility. The result is an inventory that is accurate to the degree that every developer, across every team, at every point in your delivery cycle, kept their documentation current. That is not a reasonable baseline to build a security program on.

Research from Noname Security found that 78% of organizations experienced an API security incident in the prior twelve months, with a significant portion involving APIs that were not in their known inventory. These are not sophisticated attack techniques, these are endpoints the organization itself did not know it had. We see this scenario play out a lot in the wild.

The consequences of this are practical. The auditor reviews what you show them. The penetration tester works within the scope you define. Both produce accurate assessments of the picture you presented. Neither can account for what was not in the picture. So you get a clean audit, a favorable pen test report, and an attack surface that has never been fully examined.

The more reliable approach is discovery that does not depend on developer memory or documentation discipline. Something that runs continuously, works from the outside in as well as the inside out, and treats the inventory as something to be verified rather than trusted at face value.

That conversation is coming. But before it does, the simpler question is whether the inventory you are working from today is something you actually trust, or something you have been treating as trustworthy because you had no way to challenge it.

There is a difference. And that difference is where most of the real risk lives.

If your organization is ready to get serious about API visibility, let's talk here.

👉You can also reach me on LinkedIn

Have questions? You can respond to this newsletter and I’ll be in touch,

See you in the next one. 🔥

Talk soon,
Damilola