Notifications
Clear all
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.
NHIMG editorial — based on content published by StackHawk: Customized and Configurable Scan Discovery
By the numbers:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
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.
👉 Read StackHawk's guide to customized and configurable scan discovery →
Customized scan discovery in DAST: can your controls find hidden paths?
Explore further
02/08/2026 12:36 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Customized scan discovery changes how DAST reaches hidden paths
