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. This mechanism provides explicit control over which discovered Assets are subjected to security scanning.

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 only when an Asset belongs to the domain hierarchy of an existing MONITORED Host. This conservative default prevents unintended scanning while maintaining comprehensive discovery visibility.

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 must be explicitly changed to MONITORED to include the Asset in the scanning scope. This change can be performed through the platform interface or Public API.

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.

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, the example.com Host or the specific subdomain (e.g., portal.example.com) must be manually transitioned to MONITORED status. This transition triggers ASM scanning for the domain and its subdomain hierarchy.

Advanced Configuration-Based Scope Control¶

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

Configuration-Based Exclusion Use Cases¶

Configuration-based 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. Status-based scope management through the platform interface offers post-discovery refinement, while configuration-based exclusions enable proactive filtering at the discovery level. Effective scope management combines both approaches: broad initial discovery for comprehensive visibility, followed by selective monitoring based on organizational security priorities and risk assessment.

Related Documentation¶

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