ASM — Frequently Asked Questions¶

Scope Management¶

The recommended approach to scope management in ASM is to scan wide, then refine. Run discovery across your full attack surface, then manage which Assets are monitored through the platform or API.

If you know exactly which Assets should be scanned upfront, you can manually add them through the platform or use advanced configuration to control discovery at the source (see Advanced Configuration-Based Scope Control).

How does the ASM determine which discovered Assets should be monitored?¶

Asset scope is controlled through the Asset Status field. By default, all discovered Assets are marked OUT OF SCOPE and will not be scanned. Assets are automatically promoted to MONITORED only if they belong to the domain hierarchy of an existing MONITORED Host.

Scope determination rules:

Managing scope:

• No action required to keep Assets OUT OF SCOPE — this is the default state
• Set Assets to MONITORED to include them in your scanning scope
• To scan a parent domain while excluding specific children, manually set those children to OUT OF SCOPE, FALSE POSITIVE, or DEPRECATED

What happens to Assets discovered outside the defined scope?¶

Assets discovered outside the defined scope persist with OUT OF SCOPE status. They remain visible in the ASM interface (by filtering on status) but are not scanned.

Review and management:

1. Filter the ASM Page by OUT OF SCOPE status to review discovered Assets
2. Change Assets to MONITORED to trigger scanning for that Asset and its subdomains
3. Set irrelevant Assets to FALSE POSITIVE or DEPRECATED to reduce clutter

How can the full scope of monitored Assets be viewed?¶

The complete scope of an Organization's monitored Assets can be viewed by navigating to the Hosts Page and filtering by MONITORED status (this is the default filter). This view displays all Assets that are currently being scanned and monitored by the ASM, providing a comprehensive overview of the Organization's defined attack surface.

Why would an Asset on the same parent domain as monitored services be marked as OUT OF SCOPE?¶

Scope determination in ASM is based on domain hierarchy relationships, not simple domain matching. An Asset is only considered in scope if it is on the same domain or a subdomain of an explicitly monitored Host.

Example scenario:

Consider an Organization with the following manually created Hosts:

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

When a WebApp Asset https://example.com/ is created or discovered, the ASM extracts the Host example.com. However, this Host is marked as OUT OF SCOPE because:

• example.com is not a subdomain of api.example.com or staging.example.com
• example.com is actually the parent domain, which is broader than the defined scope
• The scope only includes api.example.com, staging.example.com, and their subdomains (e.g., test.api.example.com, v2.staging.example.com)

Scope boundaries:

To include the parent domain or additional subdomains in the scope, the example.com Host or the specific subdomain (e.g., portal.example.com) must be manually set to MONITORED status, which will trigger ASM scanning for that domain and its subdomains.

Advanced Configuration-Based Scope Control¶

Advanced configuration options allow control at the discovery level, preventing specific domains from being discovered. Use this when you have predictable domain patterns that should never be scanned (e.g., tenant subdomains in multi-tenant environments) or need to reduce discovery overhead at scale.

When to use configuration-based exclusion¶

Use the Global Configuration blocklist when:

• Domains follow predictable patterns that should never be discovered
• You need to prevent discovery at scale to reduce inventory clutter
• You want to exclude domains before Assets are created

How can domains or subdomains be excluded from discovery?¶

Use the blocklisted_domains parameter in the Global Configuration to exclude domains at the source, before Assets are created.

How can tenant-specific subdomains be excluded in multi-tenant environments?¶

Multi-tenant environments often generate numerous tenant subdomains that should be excluded while preserving administrative and infrastructure domains. Use regex patterns in the service_discovery.blocklisted_domains parameter to filter domains during discovery:

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 matching tenant subdomains while allowing administrative domains like admin.example.com, api.example.com, or console.example.com to be discovered.

Impact on existing Assets:

• Existing Assets remain in inventory—blocklists do not retroactively remove Assets
• Future scans exclude domains matching the specified patterns
• Manually delete existing tenant Assets through the platform or API if needed

Additional subdomain filtering:

For finer control during subdomain enumeration, configure subdomain_enumeration.blocklist:

subdomain_enumeration:
  blocklist:
    - "^env[0-9]+\.example\.com$"
    - "^tenant-.*\.example\.com$"

This prevents subdomain enumeration for matching patterns during discovery.

Refer to the Configuration Reference for complete blocklist parameter documentation and regex syntax.

Scan Management¶

How can I view ASM scans for a single Asset?¶

ASM scans for an individual Asset can be viewed via the Asset side panel:

1. Navigate to Escape ASM All Assets
2. Locate the desired Asset in the table
3. Click on the Asset to open the side panel
4. Navigate to the Profile tab
5. Click on ASM Profile to access the profile view
6. Open the History tab to see the full scan history for this Asset

This view provides detailed scan history and results specific to the selected Asset.

How can I restart an ASM scan for a specific Asset?¶

Individual ASM scans can be manually restarted when needed, such as after significant environmental changes or if an error occurs during scanning:

1. Navigate to the Asset via Escape ASM All Assets
2. Click on the Asset to open the side panel
3. Navigate to the Profile tab
4. Click the New Scan button

This triggers an immediate revalidation and discovery process for the Asset.

How can I view all ASM scans across my Organization?¶

To view all ASM scans for an Organization:

1. Navigate to https://app.escape.tech/profiles/scans/
2. Uncheck DAST Scans
3. Check ASM Scans

This provides a comprehensive view of all ASM scanning activity across all Assets in the Organization.

Port Scanning¶

Which ports are scanned by default?¶

By default, ASM scans the most common ports when performing port scanning during Asset discovery. These typically include standard web ports and frequently used service ports to efficiently identify running services on discovered hosts.

How can I scan additional or specific ports?¶

You can customize which ports are scanned by using the port_scanning.ports configuration parameter in your Global Configuration. This allows you to specify an exact list of ports to scan based on your infrastructure needs.

Example configuration:

port_scanning:
  ports:
    - 80      # HTTP
    - 443     # HTTPS
    - 22      # SSH
    - 8080    # Alternative HTTP
    - 8443    # Alternative HTTPS
    - 3000    # Common development port
    - 5000    # Common API port

Configuration behavior:

• If the ports list is specified, only the listed ports will be scanned
• If the ports list is empty or not specified, the default set of most common ports will be scanned
• Port scanning helps identify web services and APIs running on non-standard ports

Use cases:

• Scanning additional custom application ports specific to your infrastructure
• Limiting scans to specific ports to reduce scan time and network overhead
• Including non-standard ports where internal APIs or services are hosted

Refer to the Configuration Reference for complete port scanning configuration documentation.

Rate Limiting¶

How can I control the rate of requests during ASM scans?¶

ASM scans can be configured to control the rate and volume of requests sent to your Assets using the network configuration parameters in your Global Configuration. This helps prevent overwhelming your infrastructure and allows you to comply with rate limits imposed by your systems.

Key rate limiting parameters:

• requests_per_second: Controls the maximum number of requests sent per second
• parallel_requests: Controls the maximum number of concurrent parallel requests
• request_timeout_s: Sets the maximum timeout duration for each request (in seconds)

Example configuration:

network:
  requests_per_second: 100        # Limit to 100 requests per second
  parallel_requests: 5             # Allow up to 5 concurrent requests
  request_timeout_s: 10            # Timeout individual requests after 10 seconds

Configuration behavior:

• requests_per_second sets a hard limit on the request rate, spreading requests over time to avoid bursts
• parallel_requests limits concurrency to prevent connection exhaustion on the target or scanner
• Lower values reduce load on your infrastructure but increase total scan time
• Higher values speed up scans but may trigger rate limiting or overwhelm services

Use cases:

• Reducing scan aggressiveness for production environments to minimize performance impact
• Complying with API rate limits or WAF thresholds
• Preventing scan traffic from being blocked by rate-limiting security controls
• Balancing scan speed against infrastructure capacity

Additional network configuration:

You can also configure custom headers to identify scan traffic:

network:
  requests_per_second: 100
  parallel_requests: 5
  custom_headers:
    x-scan-identifier:
      - "asm-security-scan"

Refer to the Configuration Reference for complete network configuration documentation.

Scan Location Configuration¶

Can ASM scans be configured to use different Public Locations than DAST scans?¶

No, Public Locations cannot be configured separately for ASM and DAST scans. All enabled Public Locations are used globally across the Organization and are available for both DAST and ASM scans simultaneously.

Current behavior:

• Public Locations are Organization-level resources that apply to all scan types
• Enabling or disabling Public Locations affects both DAST and ASM scans
• There is no mechanism to restrict specific Public Locations to individual ASM scan types or specific Assets

Common scenario:

Organizations may need ASM scans restricted to specific regions (e.g., US-only due to firewall allowlists) while DAST scans require different regions (e.g., Europe).

Solution:

To achieve this configuration, the following approach must be taken:

1. The Public Locations should be configured to include only the desired regions (e.g., US Public Locations only)
2. All DAST scans must be migrated to use the same Public Locations that are required for ASM scans
3. If DAST scans require Public Locations in different regions, Private Locations should be deployed in those regions as an alternative

This limitation ensures consistent network behavior across all security assessments but may require infrastructure adjustments when geographic restrictions apply to specific Assets.

For organizations with complex geographic requirements, Private Locations provide greater flexibility by allowing region-specific deployment while maintaining separation from Public Location configurations.