# 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](<#global-configuration-scope-rules>) 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**: Explicit status changes through the UI, API, or bulk edit are preserved. See [Asset Management](). 2. **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`. 3. **Third-party detection**: Assets identified as third-party are `THIRD PARTY`. 4. **Private Location discovery**: Assets identified as private are `MONITORED`. 5. **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](<#global-configuration-scope-rules>). 6. **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`. 7. **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](<#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: 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 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](<#global-configuration-scope-rules>). 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. > [!WARNING] > > **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 ```yaml 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](): 1. **Blocklist takes precedence** over allowlist: if a target matches any blocklist rule, it's `OUT OF SCOPE` 2. 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. > [!WARNING] > > **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`) 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 this discovery-level blocklist. ## 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: ```yaml 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:** Subdomain enumeration applies the domain rules from the global scope blocklist. For example, adding the following rules to the scope configuration prevents subdomain enumeration for domains matching these patterns during discovery operations: ```yaml scope: blocklist: - type: domain operation: regex value: "^env[0-9]+\\.example\\.com$" - type: domain operation: regex value: "^tenant-.*\\.example\\.com$" ``` Domains matching these patterns are excluded from subdomain enumeration while the rest of the scan continues. 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. ## Related Documentation - [Asset Management]() - [ASM Configuration Reference]() - [DAST Scope Configuration]() - [Network Configuration]() - [Private Locations]()