ASM Scope Management¶

Overview¶

Attack Surface Management (ASM) scope controls determine which discovered Assets are actively monitored and scanned for vulnerabilities. Effective scope management balances comprehensive coverage against operational efficiency, ensuring that security resources are focused on relevant Assets while maintaining visibility into the broader attack surface.

The recommended approach to ASM scope management is progressive refinement: initial discovery is executed broadly across the full attack surface, followed by selective Asset monitoring through status management. This methodology ensures comprehensive visibility while allowing precise control over which Assets receive active security assessment.

Scope Determination¶

Asset inclusion in the active monitoring scope is controlled through the Asset Status field. The preferred way to manage ASM scope is by setting Asset status directly: either manually through the platform/API, or through bulk edits. For organizations managing large attack surfaces, declarative allowlist/blocklist rules in the Global Configuration provide an additional layer of control.

Precedence¶

When an Asset is discovered or updated, its status is resolved using the following priority chain:

Manually set status: Explicit status changes through the UI, API, or bulk edit are preserved. See Asset Management.
Integration and AI Pentesting defaults: Assets pulled by AWS, AWS Account, Akamai, Azure, Cloudflare, GCP, and Kubernetes integrations are MONITORED. REST, GraphQL, and WebApp assets discovered by AI Pentesting are also MONITORED.
Third-party detection: Assets identified as third-party are THIRD PARTY.
Private Location discovery: Assets identified as private are MONITORED.
Global Configuration scope rules: Domain or IP allowlist/blocklist rules determine status for the corresponding target type. Valid Top Level Domains integrations add implicit domain allowlist rules. See Global Configuration Scope Rules.
Monitored Hosts and IPv4 Ranges: When no rules exist for the target type, a domain or subdomain of a MONITORED Host, or an IPv4 address inside a MONITORED IPv4 Range, becomes MONITORED.
Default: OUT OF SCOPE.

Manually set statuses and MONITORED statuses assigned by integration defaults, AI Pentesting, or Private Location discovery take precedence over scope blocklists. To exclude these Assets, set their status explicitly to OUT OF SCOPE.

Default Behavior¶

Discovered Assets are OUT OF SCOPE unless one of the rules above assigns another status.

Status-Based Scope Rules¶

The conditions below are evaluated in precedence order:

Condition	Resulting Status	Scanned
Manually created Asset	`MONITORED`	Yes
Integration or AI Pentesting default applies	`MONITORED`	Yes
Detected as third-party, without an earlier default	`THIRD PARTY`	No
Private Asset, without an earlier status	`MONITORED`	Yes
Allowed by applicable Global Configuration scope rules	`MONITORED`	Yes
Blocked by applicable Global Configuration scope rules	`OUT OF SCOPE`	No
No domain rules: Domain or subdomain of a `MONITORED` Host	`MONITORED`	Yes
No IP rules: IPv4 address inside a `MONITORED` IPv4 Range	`MONITORED`	Yes
No earlier condition applies	`OUT OF SCOPE`	No

Scope Management Operations¶

Maintaining Out-of-Scope Assets:

Set an Asset's status explicitly to OUT OF SCOPE if automatic promotion must be prevented.

Including Assets in Scope:

Asset status can be changed to MONITORED to include the Asset in the scanning scope. This can be performed through:

The platform interface or Public API (individual or bulk edits)
Declarative Global Configuration scope rules for rule-based inclusion

Selective Exclusion:

When a parent domain is monitored but specific child domains must be excluded, those child domains should be manually set to OUT OF SCOPE, FALSE POSITIVE, or DEPRECATED status to override the hierarchical inheritance. Alternatively, blocklist rules in the Global Configuration scope can exclude matching domains or IP ranges when no higher-priority status applies.

Out-of-Scope Asset Handling¶

Assets discovered outside the defined monitoring scope are preserved with OUT OF SCOPE status. These Assets remain visible in the ASM interface for review but are excluded from active security scanning.

Review Workflow¶

Out-of-scope Assets can be reviewed and managed through the following process:

The ASM interface is filtered by OUT OF SCOPE status to display all discovered but unmonitored Assets
Assets identified as relevant to the attack surface are transitioned to MONITORED status, triggering scanning for the Asset and its subdomains
Assets determined to be irrelevant or erroneous are marked as FALSE POSITIVE or DEPRECATED to reduce inventory clutter

This workflow ensures that discovery breadth is maintained while scope precision is refined through iterative review.

Monitored Asset Visibility¶

The complete inventory of actively monitored Assets is accessed by navigating to the ASM Assets page and applying the MONITORED status filter. This view displays all Assets currently included in the scanning scope, providing a comprehensive overview of the Organization's defined and actively assessed attack surface.

Domain Hierarchy and Scope Boundaries¶

Domain hierarchy applies when no domain scope rules or higher-priority defaults apply. In this case, Assets on the same domain or a subdomain of a MONITORED Host are monitored. IPv4 addresses use monitored IPv4 Ranges when no IP scope rules apply.

Parent Domain Exclusion Scenario¶

When domain hierarchy determines scope, monitoring a child domain keeps its broader parent domain OUT OF SCOPE. You control scope expansion by monitoring the parent explicitly.

Example Configuration:

An Organization has no domain scope rules or Top Level Domains integrations and has manually created the following monitored Hosts:

api.example.com (MONITORED)
staging.example.com (MONITORED)

When a public WebApp Asset https://example.com/ is discovered without an integration or AI Pentesting default, the extracted Host example.com is assigned OUT OF SCOPE status because:

example.com isn't a subdomain of api.example.com or staging.example.com
example.com represents the parent domain, which is broader than the explicitly defined scope
The monitoring scope includes only api.example.com, staging.example.com, and their respective subdomains

Scope Boundary Examples¶

The following table illustrates scope determination for various domain relationships:

Host	Status	Reason
`api.example.com`	`MONITORED`	Manually created Host
`staging.example.com`	`MONITORED`	Manually created Host
`v2.api.example.com`	`MONITORED`	Subdomain of MONITORED Host
`test.staging.example.com`	`MONITORED`	Subdomain of MONITORED Host
`example.com`	`OUT OF SCOPE`	Parent domain, broader than defined scope
`portal.example.com`	`OUT OF SCOPE`	Different subdomain, not under MONITORED Hosts

Scope Expansion:

To include parent domains or additional subdomains in the monitoring scope, either transition the Host (for example, example.com or portal.example.com) to MONITORED status manually, or add a matching allowlist rule in the Global Configuration scope. Hierarchy promotion applies only when no domain scope rules exist. With domain rules, add allowlist entries for the domains you want to monitor.

Global Configuration Scope Rules¶

The Global Configuration scope key supports allowlist and blocklist rules that directly control ASM Asset status. For Assets without a higher-priority status, rules determine MONITORED or OUT OF SCOPE with priority over domain hierarchy and monitored IPv4 Ranges.

This mechanism supports domain rules and IP rules, enabling declarative scope control for both hostname-based and IP-based Assets.

Global Configuration Only

Only the Global Configuration scope is used for ASM Asset status determination. Profile-level or scan-level scope settings don't affect ASM Asset status: this prevents localized scan configurations from altering the organization-wide ASM view.

Configuration Example¶

scope:
  allowlist:
    - type: domain
      operation: ends_with
      value: example.com
    - type: ip
      value: 10.0.0.0/8
  blocklist:
    - type: domain
      operation: equals
      value: legacy.example.com
    - type: ip
      value: 10.0.99.0/24

For Assets without a higher-priority status, this configuration produces:

All Assets under example.com and its subdomains are MONITORED
Assets in the 10.0.0.0/8 IP range are MONITORED
legacy.example.com is explicitly excluded (OUT OF SCOPE), overriding the allowlist
Assets in the 10.0.99.0/24 range are excluded, overriding the broader allowlist
Other domains and IP addresses are OUT OF SCOPE, unless an implicit Top Level Domains allowlist rule allows the domain

Rule Evaluation¶

Scope rules follow the same evaluation logic as DAST scope rules:

Blocklist takes precedence over allowlist: if a target matches any blocklist rule, it's OUT OF SCOPE
If allowlist rules exist, targets are MONITORED only when they satisfy allowlist matching logic

If rules exist for a target type, their result is final: an unmatched allowlist target is OUT OF SCOPE. Domain hierarchy applies only when no domain rules exist. Monitored IPv4 Ranges apply only when no IP rules exist.

Valid Top Level Domains integrations allow their domains and subdomains alongside your configured allowlist. This applies even when those domains aren't listed in your saved YAML.

Blocklist-Only Scope

Without explicit or implicit domain allowlist rules, a domain blocklist marks every non-blocked domain MONITORED. Add an allowlist to exclude unmatched domains. The same behavior applies to IP blocklists without IP allowlists.

Supported Rule Types¶

Rule Type	`type` value	Matches
Domain	`domain`	Hostnames and subdomain patterns
IP	`ip`	IP addresses and CIDR ranges

Domain rules support the operation field for flexible matching (equals, ends_with, starts_with, contains, regex, wildcard). See ScopeMatchOperation in the configuration reference.

Relationship with Other Scope Mechanisms¶

Global Configuration scope rules complement existing scope mechanisms:

Asset status (manual or bulk edits) remains the preferred way to manage individual Assets. Manually set statuses are never overwritten by scope rules.
Domain hierarchy and monitored IPv4 Ranges apply only when no scope rules exist for the corresponding target type.
Discovery-level blocklists (service_discovery.blocklist, subdomain_enumeration.blocklist) prevent Asset creation entirely, while scope rules determine the status of Assets that are already discovered. Global scope blocklist rules are also automatically propagated to these discovery-level blocklists.

Discovery-Level Scope Control¶

Configuration parameters enable scope control at the discovery level, preventing specific domains from being discovered. This approach is recommended when predictable domain patterns should never be scanned (for example, tenant subdomains in multi-tenant environments) or when discovery overhead must be reduced at scale.

Discovery-Level Exclusion Use Cases¶

Discovery-level domain exclusion is appropriate when:

Domain patterns are predictable and should be systematically excluded from discovery
Inventory clutter must be prevented at scale across large attack surfaces
Domain exclusion must occur before Asset creation to reduce processing overhead

Domain and Subdomain Exclusion¶

Domain exclusion at the discovery source is achieved through discovery-level blocklist parameters in the Global Configuration. These parameters prevent Asset creation for matching domains.

Multi-Tenant Subdomain Exclusion¶

Multi-tenant environments frequently generate numerous tenant-specific subdomains that should be excluded while preserving administrative and infrastructure domains. Regex domain rules in the service_discovery.blocklist parameter filter domains during the discovery phase:

service_discovery:
  blocklist:
    - type: domain
      operation: regex
      value: "^env[0-9]+\\.example\\.com$"      # Exclude numbered tenant environments (env1, env2)
    - type: domain
      operation: regex
      value: "^tenant-.*\\.example\\.com$"      # Exclude subdomains prefixed with "tenant-"
    - type: domain
      operation: regex
      value: "^[a-f0-9]{32}\\.example\\.com$"   # Exclude hash-based tenant identifiers

This configuration excludes tenant subdomains matching the specified patterns while allowing administrative domains such as admin.example.com, api.example.com, or console.example.com to be discovered.

Blocklist Impact on Existing Assets¶

Retroactive Behavior:

Existing Assets are retained in inventory regardless of blocklist configuration
Blocklist rules apply only to future discovery operations
Existing tenant Assets must be manually deleted through the platform interface or Public API if removal is required

Subdomain Enumeration Filtering:

For granular control during subdomain enumeration, the subdomain_enumeration.blocklist parameter is configured:

subdomain_enumeration:
  blocklist:
    - type: domain
      operation: regex
      value: "^env[0-9]+\\.example\\.com$"
    - type: domain
      operation: regex
      value: "^tenant-.*\\.example\\.com$"

This configuration prevents subdomain enumeration for domains matching the specified patterns during discovery operations.

Complete blocklist parameter documentation and regex syntax are detailed in the Configuration Reference.

Summary¶

Set Asset status manually to control individual Assets. Integration defaults, third-party detection, and Private Location discovery take priority over Global Configuration scope rules. When no rules exist for the target type, monitored Hosts and IPv4 Ranges provide fallback scope. Discovery-level blocklists act separately, preventing Asset creation for excluded patterns.