Topic starter
02/08/2026 12:24 pm
TL;DR: API defence must combine continuous discovery, posture governance, and runtime threat protection because static, signature-led controls miss novel attack patterns, shadow APIs, and exposed sensitive data, according to Salt. The real issue is not just detection but whether organisations can govern the full API lifecycle before reconnaissance becomes data loss.
Editorial analysis by NHI Mgmt Group, based on content published by Salt: “Salt Security: Focused on Solving Real Business Problems”.
Key questions
Q: What fails when API discovery and runtime protection are not connected?
A: Teams lose the ability to connect what exists with what is being abused.
Q: When does API posture governance become a compliance problem?
A: It becomes a compliance problem when the live API estate no longer matches the documented one.
Q: What do teams get wrong about API discovery and runtime protection?
A: A common mistake is treating API security as a post deployment scan problem.
Practitioner guidance
- Implement continuous API discovery Maintain a live inventory of public, internal, shadow, and deprecated APIs, and reconcile it against design documentation and ownership records.
- Bind posture checks to exposed data Review response payloads and configuration drift for fields or functions that expose sensitive data beyond intended use, especially on older endpoints.
- Correlate runtime traffic with reconnaissance patterns Tune detections for probing sequences, unusual request-response combinations, and endpoint enumeration that precede exfiltration attempts.
Bottom line: API security fails when discovery, posture governance, and runtime detection are managed separately, because each one covers a different part of the attack path.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 1:23 pm
API security governance fails when inventory, policy, and runtime are treated as separate problems. Discovery without posture leaves teams knowing what exists but not what is exposed. Posture without runtime leaves them with policy documents that do not see live abuse. The governing assumption is that each control can compensate for the others, but API attack paths exploit the seams between them. Practitioners should evaluate API security as a single lifecycle control, not a set of disconnected tools.
A question worth separating out:
Q: How should organisations govern shadow APIs and deprecated endpoints?
A: They should treat them as unmanaged access paths that require ownership, inventory, and retirement, not as harmless leftovers. If an endpoint is still reachable, it is still part of the attack surface, regardless of whether the business considers it obsolete. Governance should assign accountability and remove access, routing, and credentials when the API is no longer needed.
👉 Read our full editorial: API security fails when discovery, posture, and runtime are split