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:

1. Manually set status — If a user has explicitly set the Asset status (via UI, API, or bulk edit), that status is preserved and never overwritten automatically. See Asset Management.
2. Global Configuration scope rules — If scope allowlist/blocklist rules are defined in the Global Configuration and match the Asset, the matching result determines the status immediately. See Global Configuration Scope Rules.
3. Domain hierarchy — If the Asset is a subdomain of a MONITORED Host, it is promoted to MONITORED.
4. Default — OUT OF SCOPE.

Default Behavior¶

All discovered Assets are assigned an initial status of OUT OF SCOPE and are excluded from active scanning. Automatic promotion to MONITORED status occurs when an Asset belongs to the domain hierarchy of an existing MONITORED Host, or when it matches an allowlist rule in the Global Configuration scope.

Status-Based Scope Rules¶

The following table defines scope determination logic based on Asset type and conditions:

Scope Management Operations¶

Maintaining Out-of-Scope Assets:

No action is required to keep Assets in OUT OF SCOPE status, as this is the default state for all discovered Assets.

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 declaratively.

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:

1. The ASM interface is filtered by OUT OF SCOPE status to display all discovered but unmonitored Assets
2. Assets identified as relevant to the attack surface are transitioned to MONITORED status, triggering scanning for the Asset and its subdomains
3. 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 Hosts Page and applying the MONITORED status filter (this filter is applied by default). 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¶

Scope determination is based on domain hierarchy relationships rather than simple domain string matching. An Asset is included in the monitoring scope only when it exists on the same domain or a subdomain of an explicitly monitored Host.

Parent Domain Exclusion Scenario¶

Assets on parent domains of monitored services may be marked as OUT OF SCOPE due to hierarchical scope boundaries. This behavior is intentional and reflects precise scope control.

Example Configuration:

An Organization has manually created the following monitored Hosts:

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

When a WebApp Asset https://example.com/ is discovered, the extracted Host example.com is assigned OUT OF SCOPE status because:

• example.com is not 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:

Scope Expansion:

To include parent domains or additional subdomains in the monitoring scope, either transition the Host (e.g., example.com or portal.example.com) to MONITORED status manually, or add a matching allowlist rule in the Global Configuration scope. Both approaches trigger ASM scanning for the domain and its subdomain hierarchy.

Global Configuration Scope Rules¶

The Global Configuration scope key supports allowlist and blocklist rules that directly control ASM Asset status. When a discovered Asset matches a scope rule, the rule determines the Asset status (MONITORED or OUT OF SCOPE) with priority over domain hierarchy.

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

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

With this configuration:

• 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

Rule Evaluation¶

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

1. Blocklist takes precedence over allowlist — if a target matches any blocklist rule, it is OUT OF SCOPE
2. If allowlist rules exist, targets are MONITORED only when they satisfy allowlist matching logic

If no scope rules match (or no scope is configured), the system falls back to domain hierarchy and then to the default OUT OF SCOPE status.

Supported Rule Types¶

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 continues to apply when no scope rule matches — subdomains of MONITORED Hosts are still promoted automatically.
• 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 (e.g., 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 the blocklisted_domains parameter in the Global Configuration. This parameter prevents 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 patterns in the service_discovery.blocklisted_domains parameter filter domains during the discovery phase:

service_discovery:
  blocklisted_domains:
    - "^env[0-9]+\.example\.com$"      # Exclude numbered tenant environments (env1, env2, etc.)
    - "^tenant-.*\.example\.com$"      # Exclude subdomains prefixed with "tenant-"
    - "^[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:
    - "^env[0-9]+\.example\.com$"
    - "^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¶

ASM scope management provides flexible control over which Assets are actively monitored and scanned. Three mechanisms work together, in order of precedence:

1. Asset status (manual or bulk edits) — the preferred way to manage scope for individual Assets
2. Global Configuration scope rules (allowlist/blocklist) — declarative rules for managing scope at scale across domains and IP ranges
3. Discovery-level blocklists — prevent Asset creation entirely for known irrelevant patterns

Effective scope management combines these approaches: broad initial discovery for comprehensive visibility, followed by selective monitoring through status management and declarative rules based on organizational security priorities.

Related Documentation¶

• Asset Management
• ASM Configuration Reference
• DAST Scope Configuration
• Network Configuration
• Private Locations