Topic starter
02/08/2026 9:43 am
TL;DR: Multiple scan discovery methods for HawkScan, including spidering, HAR files, seed paths, and custom commands, help teams uncover routes that web crawlers miss or cannot reach, according to StackHawk. The governance issue is not just discovery breadth but whether testing workflows can safely map authenticated and hidden application paths without creating new operational risk.
Editorial analysis by NHI Mgmt Group, based on content published by StackHawk: “Customized and Configurable Scan Discovery”.
Key questions
Q: How should security teams test hidden application paths that crawlers miss?
A: Use multiple discovery sources.
Q: Why do authenticated routes often escape standard DAST coverage?
A: Authenticated routes usually depend on cookies, headers, or scripted actions that a basic crawler cannot infer from public pages.
Q: What can go wrong when custom scan discovery is too permissive?
A: The scanner can become a privileged execution path rather than a bounded test step.
Practitioner guidance
- Define discovery sources by route type Map which routes should come from crawling, HAR capture, seed paths, or custom commands, and assign each source to the application pattern it best represents.
- Control HAR files as sensitive test artefacts Store HAR captures with the same care as other test inputs because they can include cookies, headers, and authenticated request details.
- Restrict custom discovery commands Allow only approved commands and environments for custom scan discovery so pipeline execution cannot drift into arbitrary shell access or uncontrolled network calls.
Bottom line: Standard crawling still misses hidden and authenticated paths in modern applications, so DAST coverage depends on more than link following.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 12:36 pm
Discovery breadth is now a governance problem, not just a scanner setting. When DAST relies only on link crawling, it inherits the false assumption that exposed application routes are easy to enumerate from a homepage. Hidden endpoints, authenticated workflows, and scripted flows invalidate that assumption. For practitioners, the key question is whether discovery reflects the real attack surface or just the easiest part of it.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: Should teams combine crawling, HAR files, and seed paths in DAST?
A: Yes, when they represent different parts of the application surface. Crawling covers discoverable links, HAR files capture real session behaviour, and seed paths ensure known hidden routes are tested. Combining them reduces blind spots, but only if teams own the inputs, update them as the app changes, and keep discovery logic under change control.
👉 Read our full editorial: Customized scan discovery changes how DAST reaches hidden paths