Source code visibility is the missing control for scalable DAST

At a glance

What this is: This is an AppSec analysis of why source code visibility is becoming the gating control for scalable DAST coverage.

Why it matters: It matters to IAM and security teams because undiscovered applications, APIs, and authentication paths create unmanaged access surfaces that can undermine identity controls, testing, and governance.

By the numbers:

• 87% of organizations worry about shadow and undiscovered APIs, with 38% calling it a significant concern.

👉 Read StackHawk's analysis of source code visibility for scalable DAST

Context

Source code visibility is the practice of using repository and build-time analysis to identify applications, APIs, and related runtime components before they reach production. In AppSec, the problem is not only test coverage, but discovery coverage, because teams cannot secure or test assets they have not mapped. The primary issue here is attack surface drift, which accelerates when AI coding tools and fast release pipelines outpace manual inventory processes.

For IAM practitioners, the relevant intersection is authentication and access surface governance. Every undiscovered API or microservice may carry its own auth scheme, service account, token flow, or privilege boundary, which means identity controls are only as complete as the asset inventory behind them. That makes source code visibility a practical dependency for both DAST and identity-adjacent control assurance.

This is a typical scaling failure in modern engineering environments, not an edge case. The article describes a common pattern in fast-moving development teams: testing capacity exists, but the organisation lacks a reliable way to know what should be tested.

Key questions

Q: How should security teams scale DAST across many application teams?

A: They should standardise onboarding, choose a clear scaling model, and remove manual dependency wherever possible. A pilot can prove technical value, but enterprise scale only happens when teams can self-onboard, scan fast enough for delivery, and resolve findings through a predictable workflow. If adoption requires constant security intervention, the programme will stall.

Q: Why does undiscovered API sprawl create a governance problem for AppSec?

A: Because every undiscovered API is both untested attack surface and an untracked authentication boundary. Security teams may believe they have coverage, but the real issue is missing asset truth. Without a reliable inventory, access controls, testing, and exception handling all rest on incomplete assumptions.

Q: What do security teams get wrong about SAST and DAST coverage?

A: They often treat the tools as substitutes rather than complementary controls. That leads to blind spots, either by missing design flaws that static analysis could catch or by missing live exploitation paths that only dynamic testing can expose. Coverage should be measured by phase and risk surface, not by vendor count.

Q: How do developers and security teams keep API specifications current?

A: Automate spec generation from code and trigger refreshes when endpoints or authentication logic change. Manual upkeep breaks down quickly in fast release environments, especially when AI-assisted development increases the pace of change. Continuous regeneration keeps DAST configurations aligned with reality.

Technical breakdown

Why discovery is the real bottleneck in DAST

Dynamic application security testing depends on knowing two things for every target: where it runs and how it authenticates. In modern environments, that information is often incomplete, stale, or spread across spreadsheets and tribal knowledge. When discovery happens only after deployment, DAST is forced into a lagging posture, testing yesterday's inventory while new endpoints and services are already live. Code-based discovery moves the control point earlier, allowing teams to identify APIs, web apps, and service components as they are committed.

Practical implication: shift discovery left so DAST targets come from source control rather than manual inventories.

How code analysis generates the specs DAST needs

DAST is more effective when it can work from accurate OpenAPI specifications, but many teams either do not have specs or cannot keep them current. Code analysis can infer endpoint structure, request patterns, and authentication schemes directly from repositories, then generate or refresh specifications as the code changes. That matters because API contracts can drift faster than security teams can review them, especially in AI-accelerated delivery pipelines. The technical value is not just automation, but reducing the configuration tax that makes testing fail before it starts.

Practical implication: automate spec generation and refresh so testing does not stall on missing or stale API documentation.

Why coverage metrics matter more than scan counts

A scan count tells you how many tests ran, but not whether the organisation actually tested its full attack surface. Coverage metrics compare the number of known applications and APIs with the portion under active DAST, which exposes hidden risk and wasted effort side by side. This is especially useful when teams need to separate high-risk internet-facing services from internal or non-application repositories. The governance insight is simple: security leaders need inventory-backed coverage, not tool activity, to understand DAST effectiveness.

Practical implication: report DAST coverage against discovered assets, not against scan volume alone.

NHI Mgmt Group analysis

Source code visibility is now a control requirement, not a convenience feature. DAST programmes fail first at discovery, then at configuration, then at reporting. When applications and APIs proliferate faster than they can be inventoried, testing becomes selective by accident instead of by risk. The control lesson is that coverage depends on asset truth, and practitioners should treat discovery quality as part of AppSec governance.

Code-based discovery creates a clearer boundary between real attack surface and repository noise. Not every repository needs runtime testing, and that distinction matters because false targets consume scarce security time. The article points to a named issue we can call attack surface ambiguity: the inability to distinguish applications from documentation, libraries, and infrastructure code at scale. Practitioners should use that concept to tighten testing scope and reduce wasted effort.

AI-accelerated development is making configuration debt a security issue. As code ships more frequently, manual inventory methods age out faster and OpenAPI specs drift almost immediately. That creates a governance gap where the security team thinks coverage exists, but the underlying application map is already stale. Practitioners should assume that development velocity now determines the reliability of DAST planning.

Identity and application security are meeting at the authentication boundary. Every discovered API carries an auth model, and every missed API may bypass the controls that teams believe are enforced. That makes source code visibility relevant to IAM teams as well as AppSec teams, because the asset inventory determines which identities, tokens, and service accounts are even in scope. Practitioners should align inventory and authentication governance instead of treating them as separate problems.

What this signals

Code-based discovery will increasingly sit alongside inventory and access governance as a prerequisite for trustworthy security operations. When the application map is wrong, identity controls, runtime testing, and exception management all inherit the same blind spot, which is why asset truth is becoming a programme-level control rather than a tooling preference.

Attack surface ambiguity: teams are now spending more effort separating test-worthy applications from code that merely supports delivery. That pressure will intensify as AI coding assistants expand the number of generated services, endpoints, and authentication paths that need classification. The practical response is tighter connection between repository metadata, runtime inventories, and control ownership.

For identity-led programmes, the next planning step is to treat service authentication, secret handling, and API discovery as one governance chain. If the source code is the earliest reliable record of a service, then it should also be the earliest point at which identity, access, and test coverage expectations are established.

For practitioners

• Implement code-based asset discovery Connect source control repositories to discovery workflows so applications, APIs, and microservices are identified before production scans begin. Prioritise repositories that ship frequently and contain externally reachable endpoints.
• Separate attack surface from repository noise Classify documentation repos, package libraries, and infrastructure-only code as non-targets unless they contain executable services. This reduces wasted DAST configuration work and keeps testing capacity focused on real runtime exposure.
• Track coverage against discovered assets Measure DAST coverage as a percentage of known applications and APIs, not as a count of completed scans. Use the discovered asset inventory to identify high-risk services that remain untested.
• Automate OpenAPI generation and refresh Generate API specifications from source code and refresh them whenever authentication schemes or endpoints change. That keeps test configurations aligned with the current codebase and reduces manual maintenance overhead.

Key takeaways

• Source code visibility is becoming the control that determines whether DAST can scale beyond a narrow slice of the real attack surface.
• Undiscovered APIs and stale specifications create both testing blind spots and governance blind spots, especially in fast-moving AI-assisted development environments.
• Teams should measure coverage against discovered assets, automate spec generation, and align API discovery with identity and access governance.

Key terms

• Source Code Visibility: The ability to identify applications, APIs, services, and security-relevant configuration from source repositories before they reach production. It turns code into an inventory signal, giving security teams earlier and more accurate knowledge of what exists, what is exposed, and what should be tested.
• Attack Surface Discovery: The process of finding and classifying assets that can be reached, tested, or abused by an attacker. In modern AppSec, discovery must be continuous because build pipelines, AI-assisted code, and microservice sprawl can change the attack surface faster than manual review can track.
• OpenAPI Specification: A machine-readable format for describing REST APIs, including endpoints, parameters, responses, and authentication methods. It helps developers document interfaces and helps security teams understand intended behaviour, but it only reflects reality when the specification is kept aligned with the live service.
• DAST Coverage: The proportion of discovered applications and APIs that are actually being tested by dynamic application security testing. It is a governance metric, not a scan count, because it shows whether the security programme is reaching the full attack surface or only a visible subset.

What's in the full article

StackHawk's full blog covers the operational detail this post intentionally leaves for the source:

• Step-by-step code-based discovery workflow for identifying APIs and web applications from source repositories
• Operational guidance for generating and refreshing OpenAPI specifications as code changes
• Coverage reporting examples that compare discovered assets with DAST-tested assets for leadership reporting
• Implementation detail on separating documentation, libraries, and infrastructure code from real attack surface

👉 StackHawk's full post covers code-based discovery, OpenAPI generation, and DAST coverage reporting in more operational detail.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course, the industry's only accredited NHI security programme. Explore the course if your programme needs a stronger foundation in IAM, machine identity security, and secrets management.