Traffic-based discovery is best for seeing what production systems actually use, while code-based discovery catches endpoints earlier in development, including ones not yet deployed. Mature programmes use both. Runtime traffic confirms live exposure, and code scanning finds shadow APIs before release. Together they provide a more complete API inventory than either method alone.
Why This Matters for Security Teams
Choosing between traffic-based discovery and code-based discovery is really a question about visibility, timing, and control. Traffic-based methods show what is truly exposed in production, which helps security teams validate attack surface and prioritise risk. Code-based methods surface APIs earlier, including endpoints that have not yet reached production, which makes them valuable for design reviews and pre-release assurance. The practical risk is relying on only one lens and assuming it is complete.
For API-heavy environments, that assumption creates blind spots. Traffic logs miss dormant routes, uncalled branches, and services behind feature flags. Code scans miss runtime differences, environment-specific configuration, and integrations created outside the main repository. That is why current guidance aligns best with the NIST Cybersecurity Framework 2.0 idea of continuous visibility and risk management rather than one-time discovery. Security teams are not choosing a single source of truth so much as deciding which discovery method best fits a given stage of the software lifecycle. In practice, many security teams encounter the biggest gaps only after an undocumented endpoint has already been exposed to production traffic.
How It Works in Practice
Traffic-based discovery inspects live requests flowing through gateways, service meshes, reverse proxies, or API monitoring tools. It is strongest when teams need to answer what is actually in use, who is calling it, and which endpoints receive sensitive data. It also helps identify abandoned or low-use APIs that still remain reachable. Code-based discovery, by contrast, parses source code, OpenAPI files, route definitions, annotations, and infrastructure-as-code to identify what the application is likely to expose. This often finds hidden admin routes, stale test endpoints, and planned APIs before they ship.
The two methods answer different operational questions. Traffic-based discovery is better for runtime exposure, while code-based discovery is better for design-time coverage. In mature programmes, the output is reconciled into a single inventory with ownership, environment, authentication requirements, and data sensitivity attached. That inventory can then support control mapping, threat modelling, and review workflows aligned with API governance and secure development practices. Security teams often pair discovery with schema validation and policy checks so that new endpoints are not merely found, but assessed for authz, rate limits, logging, and data handling.
A practical workflow usually looks like this:
- Scan code repositories and build artefacts for routes, schemas, and secrets exposure.
- Observe live traffic to confirm which endpoints are active in production.
- Compare both sets to find shadow APIs, orphaned routes, and drift.
- Assign business owners and security requirements to each discovered API.
- Feed the results into CI/CD gates, runtime monitoring, and periodic review.
This approach fits the secure design and continuous monitoring principles discussed in the NIST Secure Software Development Framework and the OWASP API guidance. These controls tend to break down in polyglot microservice estates with unmanaged shadow deployments because code and traffic sources no longer share a reliable inventory boundary.
Common Variations and Edge Cases
Tighter discovery coverage often increases operational overhead, requiring organisations to balance completeness against noise, privacy, and engineering effort. That tradeoff becomes more visible in high-change environments where APIs are short-lived, environment-specific, or generated dynamically. There is no universal standard for how often discovery should run, but best practice is evolving toward continuous or near-continuous reconciliation rather than periodic point-in-time scans.
Traffic-based discovery is limited when encryption terminates outside monitored points, when east-west traffic is fragmented, or when workloads communicate through asynchronous queues rather than direct HTTP requests. Code-based discovery is limited when repositories do not reflect what is actually deployed, such as in serverless, third-party managed, or heavily templated environments. Both approaches can also miss APIs embedded in legacy systems, partner integrations, or mobile back ends where source access is incomplete. In those cases, teams often supplement discovery with gateway logs, asset management records, and developer attestations.
For organisations building toward zero trust and stronger identity controls, the most important question is not which method is superior, but which method reveals the most actionable gaps for the current lifecycle stage. That is especially true where API access is mediated by service accounts, tokens, or other non-human identities, because discovery without ownership quickly turns into inventory without accountability. The practical baseline is to treat discovery as an ongoing control, not a one-off project.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-01 | Discovery choice is a risk-management decision tied to visibility and prioritisation. |
| NIST AI RMF | The same governance idea applies to continuous inventory and accountability across systems. | |
| OWASP Agentic AI Top 10 | API discovery often overlaps with tool-using agents that depend on clear endpoint governance. |
Inventory agent-exposed APIs and verify every tool endpoint has owner, purpose, and access constraints.
Related resources from NHI Mgmt Group
- How should security teams decide between certificate-based authentication and MFA?
- How should security teams choose between semantic code analysis and AST-based scanning?
- How should teams decide between token-based and flat-fee security testing?
- How should security teams decide between native ERP controls and a separate governance platform?
