Skip to content

#151 · Scope Configuration Update – Action Required

We’ve simplified and unified scope configuration across all scanners (ASM + DAST) to make allowlists and blocklists easier to manage.

All scanners now use a single, consistent scope model to define:

  • What should be tested or crawled
  • What should be explicitly allowed or excluded

This brings more consistency, safer defaults, and clearer behavior across frontend, REST, and GraphQL scans.

Each scanner supports:

  • A global scope (shared across scanners)
  • Scanner-specific scope extensions
  • Unified allowlist and blocklist rules (domains, URLs, API paths, GraphQL operations, page elements, etc.)

Below is an example of what changed:

BEFORE
frontend_dast:
  scope:
    api:
      blocklist:
          - ^(?!.*\/api\/v2\/on-call).*

AFTER (AUTO-MIGRATION)
 rest_api_dast:
  scope:
    allowlist: []
    blocklist:
      - type: rest_api_path
        value: ^(?!.*\/api\/v2\/on-call).*
        operation: regex

AFTER (MANUAL MIGRATION WITH WILDCARDS)
rest_api_dast:
  scope:
    allowlist: 
      - type: rest_api_path
        value: "*/api/v2/on-call*"
        operation: wildcard

Action required for customers using scope configuration in CI/CD: you need to upgrade your configuration to the new unified scope format.

Existing configurations were migrated automatically where possible, but CI/CD setups relying on scope definitions must be updated to ensure scans keep working as expected.

For more information on scope configuration, new naming and structure, please refer to our documentation.