Modern portfolios change too quickly for manual inventory methods to keep up. AI coding agents, microservices, and frequent releases create new APIs faster than teams can track them, so hidden services and untested endpoints accumulate. Source code based discovery helps security teams map what exists before production exposure, which reduces blind spots and makes testing coverage measurable.
Why This Matters for Security Teams
Application attack surface discovery has become harder because the thing being secured is no longer a stable monolith. Modern portfolios combine microservices, API gateways, ephemeral containers, infrastructure as code, third-party dependencies, and AI-assisted development that can generate new endpoints faster than governance processes can record them. For AppSec, that means the gap is rarely a lack of testing effort. It is usually a lack of reliable inventory, ownership, and change visibility.
That matters because attackers do not need every service. They need one forgotten route, one exposed admin function, or one shadow API that never made it into the asset register. Guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls makes clear that control effectiveness depends on knowing what exists before you can secure it. In practice, modern portfolios turn discovery into a moving target, so teams often test what they believe is live rather than what is actually reachable. In practice, many security teams encounter exposed attack paths only after production telemetry or external scanning reveals them, rather than through intentional pre-release discovery.
How It Works in Practice
Effective discovery now has to combine software supply chain visibility, runtime telemetry, and source-informed analysis. Source code based discovery helps AppSec identify routes, methods, dependencies, and configuration patterns before deployment, while runtime scanning confirms which assets are actually exposed. The goal is not a perfect inventory on day one. The goal is a continuously updated map that is good enough to drive risk-based testing, ownership assignment, and remediation.
In practice, teams usually need to connect several sources of truth:
- Code repositories and build pipelines, to detect new services, endpoints, and framework changes early.
- API specifications and gateway configurations, to compare intended exposure with actual exposure.
- Cloud and container telemetry, to find ephemeral workloads that never appear in traditional CMDBs.
- Attack path intelligence, to prioritize the services most likely to be targeted, using sources such as the MITRE ATT&CK Enterprise Matrix and current CISA cyber threat advisories.
Where AI coding agents are in use, discovery also has to consider generated code, copied patterns, and tool-driven changes that may introduce undocumented endpoints or insecure defaults. That is where AI security overlaps with AppSec: if an agent can create or modify code, it can also expand the attack surface faster than human review cycles can follow. Reports such as Anthropic — first AI-orchestrated cyber espionage campaign report show how rapidly automated tooling can be operationalised in real attack chains, which is why source-aware discovery and validation matter before release. These controls tend to break down when teams rely on static CMDBs in container-heavy environments because ephemeral services disappear before inventory catch-up.
Common Variations and Edge Cases
Tighter discovery often increases engineering overhead, requiring organisations to balance speed of release against the cost of maintaining accurate visibility. That tradeoff is especially sharp in high-change environments such as platform teams, internal developer platforms, and AI-assisted delivery pipelines. Best practice is evolving, but there is no universal standard for how often discovery should run or which system should be treated as the primary source of truth.
One common edge case is short-lived infrastructure. If services scale up and down in minutes, traditional scanners can miss them entirely. Another is shadow API growth inside legacy applications, where a new endpoint is added without corresponding documentation or test coverage. A third is agentic or AI-assisted development, where code is produced faster than architecture review can keep pace. In those cases, the relevant control question is not only whether the application is vulnerable, but whether the organisation can prove it knows the application exists. For deeper analysis of malicious AI-enabled tradecraft, MITRE ATLAS adversarial AI threat matrix is useful for understanding how automation can be abused across the lifecycle.
For NHI Management Group, the practical answer is to treat discovery as a continuous control, not a periodic project. That means aligning code, runtime, and ownership data so testing scope can be measured and updated whenever the portfolio changes.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and MITRE ATLAS address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-01 | Knowing assets and services is foundational to organisational cyber risk management. |
| NIST SP 800-53 Rev 5 | CM-8 | Inventory control directly addresses hidden services and unmanaged endpoints. |
| MITRE ATT&CK | T1190 | Exposed web applications and services are common initial access targets. |
| NIST AI RMF | AI-assisted code creation changes the risk profile of application discovery and governance. | |
| MITRE ATLAS | Adversarial AI techniques can accelerate change and obscure provenance in application pipelines. |
Prioritise discovery of externally reachable applications and validate them against attack-path exposure.
Related resources from NHI Mgmt Group
- Why do modern applications make AppSec and IAM harder to separate?
- Why do default framework settings create hidden attack surface for application teams?
- How should security teams implement attack surface discovery across cloud and development environments?
- How should security teams implement application control in modern AppSec environments?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
