Notifications
Clear all
Topic starter
02/08/2026 12:17 pm
TL;DR: API traffic grew 51% while malicious traffic rose 211%, and 91% of respondents in Salt Security’s State of API Security Survey reported a security incident in the last 12 months, underscoring how API abuse has outpaced traditional application security controls. Runtime context, build-time governance, and workflow integration are now the practical differentiators for protecting sensitive services.
NHIMG editorial — based on content published by Salt: a webinar recap on Finastra's API security journey and the shift toward runtime context
By the numbers:
- 91% of those surveyed experienced a security incident in the last 12 months.
- API traffic for our customers has grown 51% while malicious traffic has grown at 211%.
Questions worth separating out
Q: How should security teams govern APIs that support third-party and partner integrations?
A: They should treat partner-facing APIs as governed access paths, not just technical interfaces.
Q: Why do WAFs and gateways fall short for modern API security?
A: Because they mainly see traffic patterns, not business context.
Q: What do security teams get wrong about API security scanning?
A: They often treat API scanning as a vulnerability-only exercise.
Practitioner guidance
- Implement API discovery with data exposure mapping Create an inventory that links each API endpoint to the data classes it can read, write, or expose.
- Correlate build-time findings with runtime behaviour Integrate API security findings into CI/CD so developers and security teams share the same policy model.
- Separate normal change from malicious deviation Define what approved API change looks like for each service, partner, and environment.
What's in the full article
Salt's full webinar recap covers the operational detail this post intentionally leaves for the source:
- Finastra’s API security evaluation criteria, including how the team decided what problem it needed to solve.
- The runtime and CI/CD integration patterns Salt described for supporting detection and response across the API lifecycle.
- The handling of sensitive data within the company’s own environment, including how the hybrid approach supports privacy requirements.
- The Q&A discussion on internal microservices, multi-cloud environments, and the relationship between API gateways and API security tools.
👉 Read Salt's webinar recap on Finastra's API security journey →
API security and runtime context: what IAM teams should be asking?
Explore further
02/08/2026 1:19 pm
API security is becoming a runtime identity problem. The central issue is no longer only whether an API is reachable, but whether the calling identity, request pattern, and data exposure are all governed at runtime. That makes API security closer to identity governance than to traditional perimeter defence. For regulated organisations, the practical conclusion is that API telemetry, authorisation, and lifecycle controls need to be treated as one control plane.
A question worth separating out:
Q: Who should own API security when regulators and partners both depend on the same service layer?
A: Ownership should be shared across security, application, IAM, and platform teams, with clear accountability for discovery, policy, monitoring, and incident response. In regulated environments, the organisation also needs a defensible story for what data each API exposes and how that exposure is controlled over time.
👉 Read our full editorial: API security now depends on runtime context, not just gateway controls
