Notifications
Clear all
Topic starter
02/08/2026 9:42 am
TL;DR: AppSec teams cannot scale DAST when discovery lags development, because undiscovered APIs, outdated specs, and fragmented inventory leave most attack surface untested, according to StackHawk and ESG research. Code-based visibility turns DAST from reactive scanning into continuous coverage management, especially as AI-assisted development accelerates change.
NHIMG editorial — based on content published by StackHawk: Why Source Code Visibility is the Secret Weapon to DAST that Scales
By the numbers:
- 87% of organizations worry about shadow and undiscovered APIs, with 38% calling it a significant concern.
Questions worth separating out
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.
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.
Q: What do security teams get wrong about SAST and DAST coverage?
A: They often treat the tools as substitutes rather than complementary controls.
Practitioner guidance
- Implement code-based asset discovery Connect source control repositories to discovery workflows so applications, APIs, and microservices are identified before production scans begin.
- Separate attack surface from repository noise Classify documentation repos, package libraries, and infrastructure-only code as non-targets unless they contain executable services.
- Track coverage against discovered assets Measure DAST coverage as a percentage of known applications and APIs, not as a count of completed scans.
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
👉 Read StackHawk's analysis of source code visibility for scalable DAST →
Source code visibility for DAST at scale: what teams need to know?
Explore further
02/08/2026 12:36 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Source code visibility is the missing control for scalable DAST
