Release Notes¶

#154 · Updated Escape Copilot — Smarter, Faster, More Actionable

Escape Copilot just got a significant upgrade. It now understands your current context, pulls from Escape's documentation, and guides you directly to the right place in the platform.

What's new

• Page-aware context. Copilot reads your current page. Ask about a vulnerability, a scan, or how to remediate a specific issue you’re reviewing— it already knows which one you mean:

Grounded in Escape's documentation. Ask anything about the platform and Copilot pulls the answer directly from the official docs. You’ll be always working from accurate, up-to-date guidance:

• Direct links inside the platform. Copilot points you to the exact setting, result, or configuration you need:

**- Always up to date. **Copilot automatically picks up new Public API features as they ship.

How to use it:

Open Copilot from any page. Just press Cmd + Shift + E (or Ctrl + Shift + E on Windows) to activate Copilot in-app.

Ask in plain language — "what are my most vulnerable profiles?", "how do I remediate this issue?", "how do I configure my firewall?" — and get answers tied to where you are right now.

We’ve implemented a new thinking model that can perform more complex actions to ensure utmost accuracy. You might experience slower reasoning times but better output.

Try it our now!

#153 · Deeper Attack Surface Detection

Knowing your attack surface starts with finding everything that's exposed. Subdomains are often one of the entry points for attackers.

We've integrated new provider sources and a caching mechanism into our detection engine to address exactly that.

Early results confirm we are now surfacing significantly more subdomains that were previously invisible, with detection increases ranging from 3% to over 229% depending on the end-user environment.

If you're on the ASM product, the new detection logic has already been automatically applied. Nothing to configure!

#152 · New Integrations page with built-in testing, logs, and project-level organization

The Integrations page in Escape has been redesigned to make integrations easier to manage and troubleshoot. You can now configure, test, and monitor integrations from one place, with clear insight into associated assets, execution history, and usage across workflows.

By separating integrations from asset scope and adding built-in testing and logs, it’s simpler to validate changes, debug issues, and keep integrations organized by project as you scale.

What’s new

Standalone integrations

Integrations and asset scope are now managed separately. Domains and IP ranges are handled under ASM Scope Management, while integrations focus only on connectivity and execution.

Configure and manage assets in ASM via Scope Management:

Manage integrations independently at a dedicated Integrations page:

• Keep scope and connectivity as separate concerns

This makes it easier to reason about what connects vs. what’s being scanned.

Project-level organization

You can now organize integrations based on how your team actually works.

• Link each integration to a specific project (for example, Brand A)

• Create multiple integrations for different environments (staging, prod etc.)
• Manage integrations independently across teams or setups

Makes it simpler to scale without everything living in one shared config.

Built-in testing

Validate integrations before using them in workflows in a single click on “Test configuration”

• Run tests directly from the UI during your initial set up or if you’re making changes.
• Inspect requests and responses
• Catch misconfigurations early

Fewer broken workflows and less trial-and-error.

Usage logs

Understand how integrations behave in practice.

• Click on History on a specific integration’s page and see exact when an integration ran

• Identify which workflow triggered it
• Review in-depth execution history by clicking on a specific pull for debugging

Your troubleshooting faster and more predictable.

Asset scope insight & export: Helpful for governance and reporting

For Attack Surface Management users: you can now exactly see which assets are associated with each integration.

And also export associated assets as CSV for audits or reviews:

Workflow-native messaging integrations

Create Slack, Discord, and other messaging integrations directly inside workflows, where they’re used.

Result: less setup friction and cleaner configuration.

Custom Integrations (on request)

Need something tailored?

Collaborate with the Escape team to design a custom integration built specifically for your use case.

Why this matters

Previously, integrations were harder to reason about:

• Limited visibility into dependent assets and workflows
• Manual debugging when failures occurred
• Little insight into usage or performance
• Confusion between asset scope and connectivity

Now, you get:

• Clear separation between asset scope and integrations
• Built-in testing to validate configurations
• Usage logs for debugging and traceability
• Project-level organization across environments

This makes integrations easier to manage, troubleshoot, and scale as your setup grows.

Learn more in the docs

• ASM integrations
• Jira integration
• CI/CD integrations
• Workflows (messaging & ticketing)
• Tooling

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

#150 · New: Attack Path Validation & Observable API Coverage in Escape

As with web applications, we reworked how Escape represents dynamic security testing coverage across APIs to give you full transparency into the scanner input, so you can confidently verify results and avoid blind spots.

What’s New For APIs (At a Glance)

• New Coverage page showing all API endpoints actually visited during a scan
• Advanced filtering by endpoint, severity, method / mutation type, and coverage status
• HTTP status code visualization to quickly spot error-heavy or unreachable routes
• Attack Path Validation graph that gives you visibility into Escape’s API exploration engine and helps you ensure that everything found by Escape is interpreted in the correct way and that all the input is valid.
• Pentesting Summary (Beta) explaining endpoint's purpose and what vulnerabilities found on that endpoint
• New Logs page with a full, filterable execution trace of the scan

Yes, you can now get full visibility into everything executed during a scan and truly check whether Escape is testing your APIs appropriately. You can find more details on each point below.

Why this matters

After every security scan, you might be left wondering: "Did it actually test our admin endpoints? How did it reach that nested API call? Why didn't it find the vulnerability our pentester discovered?" When auditors, developers, or leadership ask for proof of thorough testing, you're stuck with a vulnerability report and a shrug.

Now, we help your team to answer the following questions:

• What endpoints were actually tested?
• How were inputs discovered? Were they discovered well? How were they chained?
• Did authentication succeed, and where did it fail?
• Which attack paths succeeded, failed, or were blocked?

This update makes Escape’s exploration and testing fully transparent, end-to-end. You can prove what was tested, troubleshoot gaps instantly, and stop defending your security tooling.

What's New In Details - For API Testing

Coverage Page: Proving What Was Actually Tested

The Coverage page shows every API endpoint visited by the crawler, allowing you to quickly confirm that sensitive routes were actually exercised.

You can:

• Search for a specific endpoint or resolver
• Confirm whether it was tested
• Immediately see if testing succeeded, partially failed, or was blocked

This lets you answer, with certainty:

Was this endpoint actually exercised during the scan?

You can narrow the list of endpoints by:

• Associated vulnerability severity

  → focus on endpoints involved in high-impact findings

• Associated HTTP method (REST) or mutation type (GraphQL)

  → understand how an endpoint was interacted with

• Coverage status

  → OK, server error, timeout, unreachable, etc.

This is especially useful to:

• Identify endpoints that consistently error out
• Spot routes that were reachable but never returned valid responses
• Understand where configuration issues prevented deeper testing

At the top of the page, Escape visualizes HTTP status codes (200 / 400 / 500 …) in a stacked bar chart. This gives you a fast signal for question like “Are a large number of endpoints returning 400 or 500?”

Attack Path Validation Graphs: Verify that interpreted in the correct way

Coverage page tells you what was reached. Attack Path Validation Graphs show how it was reached, including the initial input. For each endpoint, you can open an Attack Path Validation Graph that exposes the exact execution chain used by Escape to get there.

These graphs help you to understand complete request sequence generated by Escape’s Business Logic Security Testing (BLST) algorithm, an intelligent engine built by the our research team that understands dependencies, extracts dynamic values, and chains requests like an experienced pentester.

What the Graph Shows (Precisely)

Each graph represents:

• The sequence of requests and responses
• Dependencies between endpoints
• Data extraction and reinjection logic used to build valid requests

Extractions and reinjections between different requests are described using jq syntax.

Example (REST API): Chaining Endpoints the Way an Attacker Would

Imagine an API exposing:

• GET /books/v1

  → returns a list of books and associated user_id

• GET /users/v1/{user_id}

  → returns user details

During exploration:

1. Escape calls GET /books/v1
2. Extracts user_id values from the response
3. Reinserts those IDs into GET /users/v1/{user_id}

In the Attack Path Validation Graph, you can see:

• Where the ID came from
• How it was validated
• Which follow-up requests succeeded or failed

Pentesting Summary (Beta)

To complement raw execution data, Escape adds AI-generated summaries per endpoint.

Exploration Summary (Beta)

This explains endpoint's purpose, business logic, how it was discovered, and which execution path led to it

Useful for:

• Reviews
• Knowledge transfer
• Audits

Pentesting Summary (Beta)

This section focuses on security impact and provides explanations:

• What vulnerabilities were found
• Which payloads triggered them
• Why the behavior is exploitable
• What an attacker could realistically do

It connects findings directly to execution evidence.

To get access to the AI pentesting summary feature, reach out to your dedicated Escape contact.

As with Web Apps, whether you’re validating a critical admin endpoint, debugging a failed scan, preparing for an audit, or reviewing a production incident, Escape gives you the right evidence.

#149 · Redesigned Web Application Coverage with Screenshots and Pentesting Summaries (Beta)

We reworked how Escape represents dynamic security testing coverage across web applications, with one goal:

Make every executed action observable, verifiable, and explainable. We strongly believe every app is different, and just showing visited URLs is not enough.

What’s New for Web Applications (At Glance)

• Web Application Coverage showing all tested pages and states
• Screenshots captured during exploration, including dynamic SPA states
• Search and filtering to validate that specific routes were tested
• Dedicated Crawling view listing all discovered pages in a folder-based structure
• API Coverage for web-triggered API calls, with the same attack path exploration graphs and visibility as API-first scans
• Unified Logs page shared across web and API testing for full end-to-end traceability

Now, we help your team to answer the following questions:

• Is the scanner getting good broad coverage?
• Did authentication succeed, and where did it fail?
• Which attack paths succeeded or weren’t tested?

This update makes Escape’s exploration and testing fully transparent, end-to-end. You can prove what was tested, troubleshoot gaps instantly, and stop defending your security tooling.

Web Application Coverage Page

Escape now shows:

1. Coverage with Screenshots

Every unique application state reached during the crawl is:

• Captured as a screenshot

• Associated with a logical route
• Searchable and filterable by severity

2. Pentesting summary (Beta)

Beyond screenshot validation, Escape delivers AI-generated summaries that break down how vulnerabilities associated with a specific page were uncovered and precisely which attack attempts led to its discovery:

3. Associated Issues

In a dedicated tab, you can view all issues linked to this specific web page, giving you immediate visibility into what was found and where.

No more guessing whether a given page was touched during scanning.

Behind the scenes: Escape’s RL-driven web crawler identifies similar page states and avoids redundant visits — now you can see exactly which unique states were tested and why.

Crawling View

A structured list of all discovered pages organized by folder and hierarchy. This makes it easy to:

• Validate that important areas of the site were exercised
• Cross-reference against your sitemap
• Spot blind spots in discovery

API Coverage Within Web Testing

When web crawling triggers API calls (XHR/Fetch), those same coverage and attack path visualisation capabilities apply — giving you:

• Unified API visibility
• Integration into Attack Path Validation graphs
• Proven evidence of how frontend and backend interactions were exercised

This gives you end-to-end visibility, from UI action → API call → vulnerability.

With this release, Escape shifts dynamic testing from a black box to a glass box.

You don’t just see results of the scan, you see:

• How coverage was achieved
• Why authentication might have failed
• And where your real attack surface lies

Whether you’re validating that a critical part of a web app was tested, debugging a failed scan, preparing for an audit, or reviewing a production incident, Escape gives you the right evidence.

#148 · New: Network Monitoring via IPv4 Ranges in Escape Attack Surface Management

Escape ASM now supports Network Monitoring through IPv4 (CIDR) ranges. This allows you to continuously scan an entire network range and automatically detect exposed assets based on their corresponding IP ranges - something that wasn’t possible before.

Modern infrastructure doesn’t always expose services via domains. Developers may deploy services directly over IPs—intentionally or accidentally—creating blind spots in asset discovery and security monitoring. With this capability, if a developer deploys a service directly over an IP address, Escape ASM will now detect it and alert you, even if it’s not tied to a known domain or hostname.

This feature will be in general availability for current ASM users and is included in your current ASM pricing plan. If you wish to learn more, feel free to reach out to your dedicated Escape contact.

How it works

1. Go to ASM → Scope Management → Configure scope

1. Select IPv4 Range to set IPV4 range up
2. Create a Network asset: Add an IPv4 CIDR range (e.g., 192.168.1.0/24) as a new asset in Escape ASM.

1. Private network support (optional)

   • If the IPV4 belongs to a private network, enable the Private Network option.
   • Select a Private Location so the scan is executed from within your infrastructure.

2. Click on Validate to view whether the corresponding asset can be found

1. Network scanning & asset discovery
   • Escape scans all IPs in the range.
   • For each IP with at least one open port (based on your configuration), a new asset is automatically created.
2. Full ASM coverage
   • Discovered IP assets are added to your ASM inventory.
   • They are scanned like any other asset, allowing ASM to:
     • Discover web applications, APIs, and services
     • Perform vulnerability scanning
     • Run security and exposure checks and set up alerting workflows based on a specific asset, a tag or a project they’re associated with

Important notes & limitations

• ⚠️ CIDR size limit
  • Currently, Escape ASM supports network ranges up to /24 (256 IPs).
  • Larger networks can be scanned by splitting them into multiple /24 ranges.
• If scanning larger ranges becomes a recurring need, reach out, this is something we can discuss.
• Looking ahead: Scanning entire Autonomous Systems (AS) will be supported easily in the future.

Why this matters

With Network Monitoring, Escape ASM now covers one of the most common blind spots in asset discovery: IP-based deployments. This ensures that anything exposed on your network—whether intentional or accidental—is detected, inventoried, and continuously secured.

#147 · Improved Scan Logs Page: Stop Debugging Scans Blind and Improve Your Scan Performance

Escape’s improved Logs page gives you a complete, chronological view of everything that happens during a scan — and, crucially, why it happens.

By making every scanner decision, skip, and failure fully visible, Logs help you quickly diagnose issues, fine-tune configurations, and continuously improve scan coverage and reliability.

The result: less guesswork, faster debugging, and better scans over time.

What you’ll see in the Logs page

The Logs page shows every event associated with a scan, including:

• Configuration steps (schema download, auth detection, proxy usage)
• Execution steps (requests, responses, mutations)
• Issues found
• Agentic LLM reasoning and decisions (when enabled)

It helps to answer the following questions like

• "Why didn't the scanner find anything?" → It was blocked by your WAF, but you didn't know
• "Why is coverage so low?" → Authentication failed during the scan

You can search and filter logs by:

• Log level (debug, info, warning, error)
• Scan stage (configuration, execution, agent actions)
• Risk type (unauth access, sensitive data, external exposure…)
• Escape severity
• Scan problem codes (auth failure, WAF block, unreachable asset, timeout…)

to help you troubleshoot scan problems instantly:

• Filter by "Scan Problems" → see "Authentication Failure" logged at 8:04:26 AM → fix auth config → rescan
• Filter by "Blocked by WAF" → see exactly which requests triggered blocking → whitelist scanner IP
• Filter by "Rate Limit Exceeded" → adjust scan before next run

Each log entry is evidence-backed:

• Full request and response
• Attachments (exchange, snippet, attack validation path graph - to highlight when the execution path from the Escape business logic security testing engine was generated:

or screenshots captured via Agentic crawling:

• Clear explanation of why an issue was raised

You can even save filtered views to reuse during reviews or audits.

Feel free to explore!

Want to improve your current coverage? Check out our documentation.

#146 · New Visualizations in Escape Attack Surface Management

We’ve introduced new visualizations in Escape Attack Surface Management that provide structured visibility into discovered assets and identified issues.

The new visualizations include:

• Issues by Severity – A breakdown of identified issues across all discovered assets by severity level (High, Medium, Low, Informational).
• Assets by Class Over Time – A time-based view showing changes in asset inventory over time, grouped by asset class (Host, API Service, Web Application).
• Assets by Source – A breakdown of asset volumes by discovery source, such as domains, Kubernetes clusters, and other integrated sources.

These visualizations help teams quickly assess risk distribution, track how the attack surface evolves over time, and understand where assets are being discovered from, supporting more accurate risk prioritization.

#145 · Escape Projects Now Generally Available

Escape Projects, our feature for organizing assets and assigning clear ownership so teams can act on the findings that matter to them, is now generally available for all customers.

Projects let you map assets to logical ownership boundaries, scope access to the right users, reduce noise by filtering out unrelated findings, and accelerate remediation loops by giving teams the context they need to fix issues efficiently.

You can learn more about the feature in our documentation and how to use it efficiently in this article.

Want to set it up?

Go to Organization Settings → Projects: This is where you create, edit, and manage Escape Projects.

Happy organizing!