Customized scan discovery changes how DAST reaches hidden paths

At a glance

What this is: This is a tooling guide on customized scan discovery for HawkScan, showing how spidering, HAR files, seed paths, and custom commands can expand web application coverage.

Why it matters: It matters because application security teams need dependable discovery coverage for authenticated, hidden, and API-driven paths, and those same workflows often intersect with secrets handling and pipeline governance.

By the numbers:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.

👉 Read StackHawk's guide to customized and configurable scan discovery

Context

Application discovery is a control problem as much as a scanning problem. If a scanner cannot enumerate the routes, authenticated flows, and hidden endpoints that a real attacker can reach, the test only proves partial coverage. In practice, teams need discovery methods that match how modern web applications are actually exercised, including browser-driven sessions and explicit path targeting.

This topic has a real identity-adjacent angle because discovery workflows often depend on secrets, tokens, authenticated sessions, and CI/CD execution context. When testing uses HAR captures, custom commands, or pipeline-intercepted traffic, the boundary between application security and identity governance becomes visible. That makes the article relevant to teams managing secrets, service accounts, and privileged automation around AppSec tooling.

Key questions

Q: How should security teams combine spidering, HAR files, and custom discovery in DAST?

A: Use spidering for baseline crawl coverage, HAR files for authenticated browser-driven paths, seed paths for routes you already know exist, and custom discovery when you have trustworthy test automation that reaches complex flows. The goal is not to pick one method, but to match the discovery method to how the application actually exposes routes and sessions.

Q: When does crawl-based discovery fail to find the attack surface?

A: It fails when routes are unlinked, hidden behind workflow state, or only reachable after authentication and client-side execution. Crawl-only approaches also miss paths discovered through API specifications or application tests. If the application depends on browser interaction or privileged navigation, teams need discovery methods beyond simple link following.

Q: What breaks when security testing commands are allowed to run inside pipelines?

A: Pipeline-based discovery can blur the boundary between testing and execution. If commands are not tightly controlled, the scan job may inherit excess permissions, expose secrets, or interact with systems outside the intended test scope. Teams should treat any command that drives scanning as privileged automation and review its credentials and runtime context.

Q: What is the difference between HAR-based discovery and seed paths?

A: HAR-based discovery captures the routes a real browser actually used, including authenticated navigation and session-specific requests. Seed paths are explicit routes that you already know should be tested, even if the crawler cannot find them. HAR files are better for realism, while seed paths are better for forcing coverage of known hidden or sensitive endpoints.

Technical breakdown

How spidering discovers reachable application paths

Spidering starts from a known application host and follows links and relative paths breadth-first to build a site tree for active testing. That works well when pages are connected and discoverable through normal navigation, but it will miss routes that are unlinked, hidden behind application logic, or only reached after authentication. HawkScan also performs passive checks during discovery, which lets it inspect responses before active attack routines run. The technical limitation is coverage, not speed: a crawler can only find what the application exposes through linkable structure or explicit seeds.

Practical implication: treat spidering as baseline coverage, not complete discovery, and add explicit routes for authenticated or hidden flows.

Why HAR files improve authenticated scan discovery

A HAR file records browser network activity, including URLs, headers, cookies, timings, and request content. For security testing, that matters because it captures the actual requests a browser makes after authentication and during dynamic navigation. Compared with pure crawling, HAR-based discovery preserves the session context needed to reach password-protected or single-page application routes. The value is not just precision but fidelity: the scan sees the application as a browser does, including paths that only appear after JavaScript execution or interaction.

Practical implication: use HAR capture when the routes you need to test depend on real user sessions, dynamic navigation, or browser state.

How custom scan discovery extends DAST into developer workflows

Custom scan discovery runs a command in an intercepted environment so HawkScan can observe the traffic produced by external tools such as Postman or Cypress. Architecturally, this moves discovery from passive crawling to workflow replay, which is useful when teams already have reliable test suites that exercise privileged or obscure routes. The same flexibility also raises governance issues because the scanner is now executing developer-controlled commands and handling runtime configuration, including secrets interpolation. That makes the discovery mechanism powerful, but also dependent on careful pipeline scoping and execution controls.

Practical implication: restrict custom discovery commands to approved test runners and apply the same controls you would to any privileged CI/CD job.

NHI Mgmt Group analysis

Custom scan discovery is a pipeline governance problem, not just a testing feature. Once scanners can execute developer-written commands or consume browser-captured sessions, the security boundary shifts into the CI/CD and secrets-management layer. That means discovery quality depends on identity and access controls around the automation itself, not only on the DAST engine. Practitioners should treat scan discovery as privileged workload execution, not generic build tooling.

Hidden-path testing exposes the limits of crawl-only application security. Web applications increasingly rely on dynamic routes, browser state, and authenticated workflows that a standard spider will miss. The result is a discovery gap, where teams believe coverage exists because a scan ran, but the scanner never saw the real attack surface. The practical conclusion is that application security programmes need multiple discovery modes, each matched to how the application is actually used.

Secrets handling becomes more visible when testing is orchestration-heavy. The article’s custom command examples show why discovery tooling often intersects with credential exposure, runtime configuration, and pipeline permissions. That is where NHI governance becomes relevant, because tokens, API keys, and session material are frequently present in the same automation stack that drives security testing. Teams should review discovery pipelines as part of broader secrets and service-account governance.

Workflow replay is now part of attack-surface management. If your test harness can replay Postman collections or Cypress flows, it can also become a controlled mechanism for validating the routes that matter most to business logic and authenticated access. That is useful, but it also means teams need governance for which workflows are allowed to drive scans and how their outputs are handled. The right model is controlled reuse, not unrestricted execution.

What this signals

Application security teams should expect discovery tooling to be judged less by scan volume and more by route fidelity. In practice, that means the strongest programmes will pair crawl-based coverage with authenticated recordings and workflow replay, then validate the resulting route set against application inventory and business-critical flows.

Discovery fidelity gap: this is the difference between a scan that ran and a scan that actually saw the routes attackers could reach. Teams that do not track this gap will continue to overestimate coverage, especially in single-page apps and authenticated portals. A useful external reference point is the NIST Cybersecurity Framework 2.0, which frames detect and protect outcomes around real asset awareness.

For identity and secrets owners, the main signal is that AppSec tooling is now another consumer of privileged automation. If discovery jobs can execute commands, ingest browser sessions, or reuse pipeline variables, those jobs need the same governance scrutiny as any other non-human workload. That includes credential scope, secret handling, and approval boundaries.

For practitioners

• Map discovery mode to application shape Use spidering for linked public content, HAR capture for authenticated or SPA routes, seed paths for known hidden endpoints, and custom commands only where existing test workflows reliably exercise the right traffic.
• Treat scan runners as privileged automation Limit who can modify custom discovery commands, isolate the runtime environment, and review the service accounts, tokens, and injected variables that the scan uses before it can interact with production-like systems.
• Audit secrets exposure in discovery workflows Check whether browser recordings, test fixtures, or pipeline variables carry long-lived credentials into scan jobs, then remove reusable secrets from the workflow and replace them with short-lived access where possible.
• Validate hidden-route coverage deliberately Compare the scanner’s discovered routes with application inventory, OpenAPI definitions, GraphQL introspection results, and known admin or internal paths to find gaps that crawl-based discovery cannot reach.

Key takeaways

• Scan discovery is only as good as the paths it can actually observe, which makes hidden and authenticated routes the central coverage risk.
• Browser captures, seed paths, and workflow replay extend DAST coverage, but they also move the control problem into secrets and pipeline governance.
• Teams should treat discovery runners as privileged automation and align route coverage with real application behaviour, not crawler assumptions.

Key terms

• Scan Discovery: Scan discovery is the step where a security tool identifies which application routes, endpoints, or paths it should test. It determines coverage before active testing begins and is often the difference between finding real exposure and testing only a narrow slice of the application.
• HAR File: A HAR file is a browser-generated record of network activity that captures requests, responses, headers, cookies, and timings. Security teams use it to replay authenticated navigation or dynamic application flows so scans can reach paths that crawlers may miss.
• Seed Path: A seed path is an explicitly provided application route that a scanner should visit even if it cannot discover it automatically. It is a practical way to force coverage of hidden, internal, or unlinked endpoints that matter for testing and governance.
• Custom Scan Discovery: Custom scan discovery lets a security tool run a specified command and observe the traffic it generates. This is useful for reusing existing tests, but it also turns discovery into privileged automation that must be governed like any other pipeline workload.

What's in the full article

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

• The exact HawkScan configuration snippets for spidering, HAR capture, seed paths, and custom discovery.
• Step-by-step examples for intercepting Postman and Cypress traffic during scan discovery.
• Runtime handling details for secrets interpolation and environment variables in custom scan jobs.
• The vendor's own documentation pointers for using scan discovery across OpenAPI, GraphQL, and Soap inputs.

👉 StackHawk's full post covers spidering, HAR files, seed paths, and custom command examples.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It is designed for practitioners who need to connect identity controls to operational security programmes across the enterprise.