Salt Security this week extended its core platform to make it easier to discover and govern application programming interfaces (APIs).

For example, Salt Security is now leveraging extended Berkley Packet Filtering (eBPF) in the kernel of operating systems, to discover API traffic and vulnerabilities in addition to sensitive and encrypted data.

Eric Schwake, director of cybersecurity strategy for Salt Security, said this Panoramic Discovery with eBPF and Salt Surface extension to the Salt Security API Protection Platform makes it simpler for cybersecurity teams to discover what API endpoints need to be secured across increasingly complex application environments.

Additionally, Salt Security has added a Salt Posture Governance Policy Hub through which controls can be enforced across the application lifecycle, including now in the design phase of an API.

Salt Security has also extended the generative artificial intelligence (AI) capabilities it provides, by adding a custom-built large language model (LLM) that summarizes complex attack patterns into clear, concise, actionable insights.

Finally, it can now also detect traffic abnormalities originating from automated scanners, bots and human attackers in a way that makes it easier to distinguish between malicious and benign activity.

While the debate over whether organizations require a dedicated API security platform versus relying on, for example, a web application firewall (WAF) or gateway to secure APIs, the one certain thing is APIs are the foundation upon which most web traffic is being generated. As such, APIs are endpoints that need to be secured much like any other, said Schwake.

A recent Salt Security survey found that almost all (95%) survey respondents experienced security issues involving APIs running in a production environment, with 23% suffering breaches.

API Attack Surface is Expanding

The API attack surface is also expanding, with Salt Security customers increasing API counts by 167% over the past 12 months, with nearly two-thirds (66%) of survey respondents indicating that they are managing more than 100 APIs.

As with any kind of software, the fundamental security issue with building APIs is that most developers have limited cybersecurity expertise. It’s also not always clear who in an organization is responsible for securing those APIs, once they are exposed.

Fortunately, the bulk of these APIs are internally facing, so the immediate crux of the issue is the security of the APIs that are externally accessible. While there are fewer of these APIs, cybersecurity teams should not overlook the security of internally facing APIs. It doesn’t take much for development teams to make an internal API accessible to external users, so what may seem secure enough today, can tomorrow become a very big issue when some business unit decides to, for whatever reason, make an existing API accessible to some entity outside the company.

Theoretically, at least, developers are assuming more responsibility for API security as part of the general shift left of responsibility for application security via the adoption of DevSecOps best practices. The challenge is organizations are now routinely deploying thousands of APIs, which means the probability there will be a security incident involving APIs is all but certain.