Topic starter
02/08/2026 12:32 pm
TL;DR: A survey of 300 security leaders finds 73% of CISOs rate API security as top or critical, yet only 17% say they have a comprehensive implemented strategy, while 74% are surprised by new undocumented APIs and 16% feel adequately staffed to triage alerts, according to Salt. The gap is operational, not aspirational, and it leaves shadow APIs, legacy tooling, and business logic abuse outside practical governance.
Editorial analysis by NHI Mgmt Group, based on content published by Salt: “The CISO's API Security Paradox: High Priority, Huge Blind Spots”.
By the numbers:
- 73% of CISOs consider API security a top or critical concern.
- Only 17% of CISOs report having a comprehensive and implemented API security strategy.
- 74% of security leaders are often surprised by the discovery of new, undocumented APIs in their environments.
Key questions
Q: What breaks when API discovery only happens on a monthly or quarterly audit cycle?
A: Unknown APIs can exist long enough for teams to lose control of ownership, data exposure, and access paths.
Q: Why do legacy API tools miss business logic attacks?
A: Legacy perimeter tools are built to spot known malicious signatures and coarse policy violations, not requests that are technically valid but operationally abusive.
Q: What are the signs that API governance is failing at runtime?
A: Common signs include undocumented endpoints, duplicated ownership, inconsistent responses, rising retry loops, and frequent discovery of APIs that are not in the catalogue.
Practitioner guidance
- Build continuous API discovery into change workflows Trigger discovery when applications, integrations, or versions change so shadow and unmanaged APIs are identified as part of release governance, not after the fact.
- Map every API to an accountable owner Require each API to have a business owner, technical owner, and access decision record so unknown endpoints cannot persist without clear responsibility.
- Test for business-logic abuse paths Add authorization and workflow abuse tests that verify whether valid requests can still reach data, functions, or objects outside intended use.
Bottom line: API security programmes are failing less because teams ignore the risk and more because discovery, ownership, and response cannot keep pace with API change.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 1:29 pm
API discovery debt is now a governance failure, not a tooling inconvenience. When 74% of leaders are surprised by new undocumented APIs, the organisation no longer has a reliable asset boundary. That means access policy, testing, and incident response are all operating against an incomplete map. The practical conclusion is that API inventory must be treated as a control plane, not a reporting exercise.
A few things that frame the scale:
- Secrets management is a top five cybersecurity priority for only 33% of organisations, behind cloud security (45%), API security (42%), and endpoint security (36%), according to the 2024 State of Secrets Management Survey.
- 96% of security operations teams report critical blind spots, most commonly in cloud infrastructure (74%) and identity and access behaviour (67%).
A question worth separating out:
Q: Should teams prioritise API discovery or enforcement first?
A: Discovery comes first when shadow endpoints or incomplete inventories exist, because enforcement cannot protect what the team has not identified. Once the exposed surface is known, prioritise the most sensitive and most attacked APIs for schema validation, bot controls, and runtime enforcement.
👉 Read our full editorial: API security strategy is lagging behind discovery and response needs