Seed Path

What a seed path does in a scanner workflow

A seed path is not a discovery result, it is a deliberate starting point. It tells a scanner to visit a route that may be hidden from crawling, blocked by navigation limits, or simply absent from the public link graph, so coverage can include endpoints that matter for assurance even when automated discovery would miss them.

This matters because many important application paths are only reachable through internal navigation, direct routing, or out-of-band knowledge. Seed paths let testing teams anchor coverage to those routes instead of assuming that crawler visibility equals application completeness.

Why seed paths exist in coverage planning

Seed paths are used when the real assessment goal is not just to map what is linked, but to inspect what is actually deployed. They are especially useful when teams already know about admin screens, feature flags, legacy routes, environment-specific paths, or business-critical endpoints that should be included in a scan even if no page links to them.

In practice, a seed path can make a scan more representative of the application’s real attack surface. It narrows the gap between what the scanner can infer automatically and what the organisation already knows should be tested.

How seed paths relate to scanner completeness

Discovery-based crawling is efficient, but it is bounded by what the scanner can reach from its starting point. A seed path supplements that process with explicit coverage targets, which helps prevent blind spots caused by weak navigation, JavaScript-heavy interfaces, disconnected backend routes, or deliberately unlinked administrative functions.

The trade-off is that a seed path improves coverage only for routes you already know to include. It does not validate whether the broader application inventory is complete, and it can create false confidence if teams rely on it instead of maintaining a current view of all deployed routes.

Where seed paths fit in governance and testing practice

Seed paths are most valuable when they are treated as part of test scope governance, not as an ad hoc convenience. A well-managed list helps teams document why a route is included, who owns it, and when it should be added or removed as the application changes.

They are also a reminder that security testing should combine automatic discovery with human knowledge. If a route only exists in someone’s memory, a release note, or a deployment ticket, encoding it as a seed path is one way to keep assessment coverage aligned with operational reality.

Risk and Threat Considerations

Hidden or unlinked endpoints often carry higher risk than their visibility suggests, because they may be less reviewed, less monitored, or older than the rest of the application. A seed path is useful precisely because those routes can be important to security testing even when ordinary discovery would not find them.

Failure mechanism: If teams do not seed scanners with known routes, the assessment may miss internal-only functions, alternate entry points, or legacy endpoints that still accept requests and expose sensitive actions or data.

Impact: Missed coverage can leave exploitable functionality untested, delay remediation, and create a false sense of security about the application’s true attack surface.

Practitioner Guidance

Why practitioners should care: Seed paths are a control over scan scope, so they should be maintained with the same discipline as other testing inputs. The list should reflect routes that are intentionally in scope and still operational, rather than becoming a stale collection of old URLs.

What to watch for: Pay particular attention to routes that exist outside normal navigation, especially administrative, internal, or feature-specific paths. Those are the places where scanners most often need help to achieve useful coverage.

Related resources from NHI Mgmt Group

• Why do leaked secrets need a different reporting path than ordinary software bugs?
• How should security teams prevent hardcoded secrets from becoming a breach path?
• What breaks when organisations do not map the access path of AI and SaaS integrations?
• How should organisations respond when a privileged SSH certificate path is flawed?