Radware this week revealed it has acquired Pynt, a provider of a set of tools for testing the security of application programming interfaces (APIs).

Uri Dorot, a senior product marketing manager for Radware, said that capability will continue to be made available as a standalone tool in addition to being more tightly integrated into the existing cybersecurity platform that Radware makes available for securing APIs and thwarting cybersecurity attacks.

The acquisition of Pynt follows the launch of the Radware API Security Service last year, through which it enables cybersecurity teams to both discover APIs and secure them at runtime.

By combining Pynt’s API security testing capabilities with that platform, it now becomes possible to extend the scope of the API security platform to include design and testing workflows that typically occur early in a DevOps workflow, said Dorot.

With the bulk of web traffic now moving between APIs, more cybersecurity teams are moving to address API security within the context of a larger platform that can, for example, also assess risks and thwart distributed denial of service (DDoS) attacks.

The Radware API Security Service provides a means to secure APIs in a way that can be coordinated with response to other types of attacks as the tactics and techniques employed by cybercriminals become more sophisticated, noted Dorot.

The biggest challenge is usually simply discovering the number of APIs an organization has developed, which most of the time is significantly underestimated, he added. The biggest issue most cybersecurity teams have today is they simply lack visibility into core elements of the IT stack, noted Dorot.

It’s not clear to what degree cybersecurity teams are attempting to secure APIs much like any other endpoint or as part of a larger overall strategy. Radware, in effect, is positioning itself to be able to address both of those scenarios, said Dorot.

Hopefully, more cybersecurity teams are assuming responsibility for API security. Historically, many cybersecurity teams tended to assume that the application developers that created an API were also taking steps to secure them. Most application developers, however, lack the expertise and tooling required to secure the APIs they create. As a result, in addition to making it relatively simple for cybercriminals to, for example, invoke an API to exfiltrate data, there also tends to be more rogue APIs that have been deployed than cybersecurity teams realize.

More troubling still, there are also zombie APIs that, while still exposed to the Internet, are no longer being updated and maintained.

Longer term, cybersecurity teams will also soon need to extend the reach of API security tools and platforms to include the Model Context Server (MCP) protocol that is now being widely used to provide artificial intelligence (AI) applications and agents with access to data. MCP, for all intents and purposes, is just another type of API, said Dorot.

Hopefully, there will come a day soon when most organizations have an effective strategy in place for securing all their APIs. In the meantime, however, cybersecurity teams should assume that most of the external-facing APIs they have deployed are to one degree or another have probably been compromised.