API9:2023 — Improper Inventory Management

Slide 4 · Version Sprawl

APIs accumulate versions the way codebases accumulate dead code.

Each version launch is straightforward. Each version retirement is a project nobody prioritizes.

The lifecycle problem

Launching a new API version is a development project with a deadline, stakeholders, and a release date. Decommissioning an old version requires: identifying all consumers still using it, giving them a migration deadline, monitoring traffic to confirm they’ve migrated, handling the consumers who don’t respond, and then finally shutting down the old version. This is harder, slower, and has no exciting launch date — so it gets deferred indefinitely.

📅

External integrations that can’t be forced to migrate

Partners, third-party developers, and mobile apps using old API versions may not migrate on schedule — or ever. Shutting down v1 while 5% of production traffic still uses it means breaking those integrations. The old version stays alive.

📱

Mobile app versions that can’t be force-updated

Users who haven’t updated their mobile app still send requests to old API versions. You can’t force all users to update. The API must keep supporting old versions as long as old app versions are in circulation — which can be years.

💡

Security patches applied to new versions only

When a vulnerability is found in the API, the patch goes to the current version. Old versions may not receive the patch — especially if they’re maintained by a different team or the codebase has diverged. The old version remains vulnerable indefinitely.

🗄️

No central inventory of what exists

In large organizations with multiple teams, no single person knows all the API versions deployed across all services. When asked “what API versions are live?”, the honest answer is often “we’re not sure.”

← Back Environment exposure →