Topic starter
02/08/2026 12:24 pm
TL;DR: Shadow APIs and deprecated endpoints widen the attack surface even when documentation looks complete, according to Salt. API governance has to keep inventory, posture, and runtime signals aligned or exposed paths can stay reachable long enough for reconnaissance to turn into 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: 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.
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.
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.
Glossary terms: API Discovery, API posture governance, Runtime API Protection, Shadow API
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 2 days ago by NHI Mgmt Group
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