SmartBear today added capabilities to its platform for designing and managing application programming interfaces (APIs) that make it easier to both keep track of them and detect drift.
A revamped Swagger Catalog, in addition to providing a unified view of APIs, also makes it possible to govern them.
At the same time, SmartBear is adding Swagger Contract Testing with drift detection that verifies the API is behaving as specified in a contract.
Additionally, SmartBear later this quarter plans to revamp its API editor along with artificial intelligence (AI) tools for generating APIs, a context-aware ability to create documentation, Spectral-based governance enforcement, a Model Context Protocol (MCP) Server and expanded multi-protocol support, including OpenAPI 3.1. AsyncAPI 3.0, and GraphQL.
Laura Kennedy, director of product management for SmartBear, said both additions extend the API lifecycle management capabilities of the company’s platform.
For example, Swagger Catalog combines centralized visibility, automated governance and policy enforcement that spans API design to the runtime environment, noted Kennedy.
Swagger Contract Testing with drift detection continuously verifies that real API behavior matches OpenAPI contracts to ensure that business logic in the API hasn’t been modified, she added.
API lifecycle management issues are coming to a head now more than ever because AI agents are dependent on them to access data. The challenge is that not only are there more types of APIs than ever, but they are also being updated more regularly after being initially deployed. As a result, there is a much greater chance that an API is likely to have been misconfigured.
More challenging still, it is also more likely that as the pace of application development accelerates, it becomes more likely that a rogue API will have been deployed that no one in IT is aware exists. In the absence of any visibility, it’s also probable that the API is fundamentally insecure.
Finally, there are also zombie APIs that, after being created, are no longer being updated and maintained. Those APIs then become prime targets for cybercriminals looking to exploit any API weakness they can discover.
It’s not clear to what degree software engineering teams are proactively managing APIs. However, as the sheer number of API strewn across the enterprise only continues to increase, it’s only a matter of time before the issue is forced.
In the meantime, DevSecOps teams especially should be at the forefront of creating an inventory of APIs. While the bulk of APIs tend to be internally facing, it’s not uncommon for an API that no one ever thought would be exposed to the internet to have, for one unexplained reason or another, been made accessible.
Ideally, APIs should be just one more software artifact to be managed and secured within the context of a larger DevOps workflow. The challenge, as always, is finding a way to keep track of who created which API for what business purpose. Any API that exists without that level of credible explanation warrants immediate further investigation.