How should security teams operationalize API discovery when source code and runtime behavior do not match?

Security teams should treat API discovery as a lifecycle control, not a one-time inventory task. Scan source code to identify endpoints early, then correlate those findings with runtime traffic to see what is actually exposed, active, or changed in production. This approach reduces blind spots from shadow APIs, zombie APIs, and undocumented endpoints that can evade security review.

Why API Discovery Has to Reconcile Code and Runtime

API discovery breaks down when teams assume source code is the whole truth. Source scans help surface intended routes, handlers, and schema contracts early, but runtime telemetry reveals what is actually reachable, versioned, or left behind after refactors, mergers, or partial deployments. That gap is where shadow APIs, zombie APIs, and undocumented endpoints tend to hide.

A practical discovery program treats code and traffic as complementary evidence. Code shows design intent and helps locate candidates for review, while runtime shows exposure, business usage, and drift. The most useful output is not a static list, but a reconciled view of endpoints that are present in code, present in production, or present in neither but still being called.

Discovery also has to account for the fact that API exposure often tracks broader identity and secret sprawl patterns. If an endpoint is reachable only because a forgotten token, stale integration, or inherited permission still works, the API is operationally live even if no one can find it in the repository. That is why discovery should be paired with lifecycle and control review rather than treated as an isolated scanning exercise. NHIMG’s Ultimate Guide to NHIs is useful background when API access is mediated by machine, service, or application credentials.

How to Operationalize the Discovery Workflow

Start by making discovery continuous and evidence-driven. Scan source repositories, build artifacts, OpenAPI files, gateway configs, and infrastructure-as-code to identify candidate endpoints. Then compare those findings with runtime signals such as API gateway logs, reverse proxy logs, WAF events, service mesh telemetry, and traces to determine what is actually receiving traffic.

The next step is reconciliation. Endpoints should be triaged into four buckets: defined and live, defined but inactive, live but undocumented, and observed in neither source nor current runtime baselines. That last category is especially important, because it often reveals drift, bypass paths, or abandoned test surfaces that have not been removed from production networks.

Make ownership part of the workflow. A discovered endpoint is not actionable until it has a service owner, a business purpose, an expected authentication pattern, and an environment scope. Where code and runtime disagree, the mismatch should trigger validation, not assumptions: either the code is stale, the runtime is shadowed, or the deployment pipeline is introducing behavior that was never reviewed. NHIMG’s NHI Lifecycle Management Guide is a good fit for teams formalizing ownership and change-tracking around exposed services and credentials.

For teams that need a broader operational model, NHIMG’s The State of Non-Human Identity Security reinforces why visibility and monitoring have to be part of the control, not a later audit step.

Risk and Threat Considerations

When source and runtime do not match, the main risk is not just incomplete inventory, it is unreviewed exposure. A stale endpoint may still accept authentication, expose sensitive data, or allow methods that were removed from code but remain enabled in production. Attackers and internal testers alike tend to find these gaps faster than governance processes do, especially when old versions, forgotten test routes, or weakly monitored integrations remain reachable.

Failure mechanism: Teams trust repository scans as the authoritative system of record, while runtime traffic, gateway behavior, or alternate deployment paths continue to expose endpoints that were never formally approved or were supposed to be retired.

Impact: Blind spots in review, authorization, logging, and incident response create opportunities for unauthorized access, data leakage, abuse of deprecated functionality, and persistence through overlooked interfaces.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP Agentic AI Top 10	A3 — Identity and Access Abuse	API discovery gaps can expose unmanaged service access paths.
Recommendation — Correlate exposed endpoints with authenticated access paths and revoke unintended reachability.
CIS Controls v8	6 — Access Control Management	Discovery must identify and remove unauthorized or stale API access paths.
	13 — Network Monitoring and Defense	Runtime correlation depends on logs and traffic telemetry to reveal exposed APIs.
Recommendation — Inventory API entry points and remove access that is not explicitly approved. Use network and application telemetry to detect undocumented or changed API exposure.
NIST CSF 2.0	ID.AM — Asset Management	API discovery is an asset inventory and reconciliation problem across code and runtime.
Recommendation — Maintain a reconciled inventory of API assets from source, gateways, and production traffic.
OWASP Non-Human Identity Top 10	NHI-03 — Visibility and Discovery	Shadow and zombie APIs often persist alongside unmanaged machine-access paths.
	NHI-04 — Secrets and Credential Management	Undocumented APIs often remain reachable through stale tokens or inherited credentials.
Recommendation — Continuously discover, classify, and reconcile APIs that exist in code or production. Tie endpoint review to credential ownership and rotate access that enables unexpected API reachability.

Practitioner Guidance

What to verify: For every discovered endpoint, verify whether it is expected in production, who owns it, what authentication it requires, and whether the runtime path matches the documented route, version, and environment. If a route appears in traffic but not in source, treat it as a control exception until proven otherwise.

Decision rule: If runtime shows traffic to an endpoint that source does not explain, prioritize containment, ownership assignment, and exposure review before deciding whether the endpoint is legitimate. If source shows endpoints that never appear in production, confirm whether they are dead code, dark launches, or a missing telemetry source, then remove or suppress them accordingly.

Practitioner takeaway: API discovery is effective only when it answers two questions at once: what was built, and what is actually reachable. The operational goal is to reconcile intent with exposure often enough that drift becomes visible before it becomes a security event.