Scan Settings

How to configure per-tenant scan settings in Guard, including the scan-status gate and custom HTTP headers for outgoing scan requests.

Scan-Status Gate

Guard enforces a per-asset scan-status gate that prevents assets in certain lifecycle states from entering the scan queue. This gate applies consistently across every path through which scan jobs can be enqueued — including scheduled scans, startup job fan-outs, and webhook-triggered enqueues.

Affected Lifecycle States

Assets in any of the following states are excluded from scanning:

State	Description
Frozen	Asset has been manually paused from scanning.
Pending	Asset is awaiting approval before scanning begins.
Deactivated	Asset has been removed from active monitoring.

Assets in these states will not receive scans regardless of how a scan job is initiated.

Enqueue Paths

The gate is applied at every point where scan jobs can enter the queue:

Cron-Scheduled Scans

When the background scheduler runs at its configured intervals, assets in Frozen, Pending, or Deactivated states are excluded before any jobs are enqueued. The scheduler evaluates each asset's lifecycle state as part of the selection criteria.

StartJobs Fan-Out

When Guard fans out jobs at startup, the same lifecycle predicates are applied. Assets that are stale, unapproved, or otherwise in a non-scannable state are filtered out before entering the queue.

Account Webhook Triggers

Webhook-initiated enqueues evaluate the scan-status gate on a per-asset basis. An asset in a Frozen, Pending, or Deactivated state will be skipped even if the triggering webhook would otherwise cause it to be scanned.

Managing Asset Scan Status

You can view and change an asset's scan status from its detail page in the Guard platform. The available status transitions depend on your role and the asset's current state. For details on asset lifecycle management, see the Asset Management article in the documentation.

Custom HTTP Headers

Guard supports attaching custom HTTP headers to all outgoing scan requests on a per-tenant basis. This allows scan traffic to carry authentication tokens, bypass markers, or routing values needed in environments protected by WAFs or other header-gated controls.

Custom headers are merged with Guard's base headers and applied uniformly across all scan capabilities, including:

Web crawling
Nuclei
DAST
Screenshot capture
Burp sync

Configuring Custom Headers

Open Scan Settings from the Guard platform navigation.
Locate the Custom HTTP Headers section.
Use the key-value editor to add, edit, or remove header entries.
Save your changes. The updated headers will be applied to subsequent scan requests.

Header Validation

Guard validates header names against RFC 7230 and header values against RFC 9110. A denied-name list prevents custom headers from overriding reserved internal headers used by Guard.

If a header name or value fails validation, an error will be displayed in the settings UI and the configuration will not be saved until the issue is resolved.

Common Use Cases

Use Case	Example Header
Exempt scan traffic from WAF rules	A header recognized by your WAF as a bypass marker
Authenticate to a staging environment	An `Authorization` or API key header
Route requests through a specific upstream	A `X-Forwarded-Host` or routing header required by your infrastructure

Considerations

Custom headers are scoped to the tenant and apply to all scan targets. Header values that are environment- or target-specific should be managed carefully to avoid unintended side effects.
Reserved Guard headers cannot be overridden. Attempts to use a reserved name will be rejected during validation.
Changes take effect on the next scan run; in-progress scans are not affected.

Support

If you observe unexpected scan behavior related to asset lifecycle states or custom header configuration, contact support@praetorian.com.