From 69e7350fea50dbc08ce6b10e06e96e58c41a25c0 Mon Sep 17 00:00:00 2001
From: permissiondenied1337
<282577724+permissiondenied1337@users.noreply.github.com>
Date: Fri, 8 May 2026 15:55:42 +0200
Subject: [PATCH 1/2] Updated Schema-Based Testing documentation
---
.../schema-based-testing/explore.md | 128 +++--
.../schema-based-testing/overview.md | 135 +++--
.../schema-based-testing/setup.md | 536 ++++++------------
.../sbt-docker-container-output.png | Bin 0 -> 220175 bytes
.../sbt-hypothesis-detail.png | Bin 0 -> 160663 bytes
.../sbt-policies-list.png | Bin 0 -> 140672 bytes
.../sbt-policy-create-postman-new.png | Bin 0 -> 50424 bytes
.../sbt-policy-docker-command-new.png | Bin 0 -> 59099 bytes
.../sbt-security-issues-by-run.png | Bin 0 -> 131110 bytes
.../sbt-test-run-details.png | Bin 0 -> 124894 bytes
.../sbt-test-runs-row.png | Bin 0 -> 45451 bytes
11 files changed, 350 insertions(+), 449 deletions(-)
create mode 100644 images/vulnerability-detection/sbt-docker-container-output.png
create mode 100644 images/vulnerability-detection/sbt-hypothesis-detail.png
create mode 100644 images/vulnerability-detection/sbt-policies-list.png
create mode 100644 images/vulnerability-detection/sbt-policy-create-postman-new.png
create mode 100644 images/vulnerability-detection/sbt-policy-docker-command-new.png
create mode 100644 images/vulnerability-detection/sbt-security-issues-by-run.png
create mode 100644 images/vulnerability-detection/sbt-test-run-details.png
create mode 100644 images/vulnerability-detection/sbt-test-runs-row.png
diff --git a/docs/latest/vulnerability-detection/schema-based-testing/explore.md b/docs/latest/vulnerability-detection/schema-based-testing/explore.md
index 8facd64b08..9c50a05e31 100644
--- a/docs/latest/vulnerability-detection/schema-based-testing/explore.md
+++ b/docs/latest/vulnerability-detection/schema-based-testing/explore.md
@@ -1,12 +1,26 @@
# Exploring Test Run Results
-Once [Schema-Based Testing](overview.md) is enabled and tests [are run](setup.md#docker-run), you can explore the test run results as described in this article.
+Once [Schema-Based Testing](overview.md) is enabled and tests [are run](setup.md#docker-run), you can explore the results in Wallarm Console as described in this article.
## Test runs and results
In Wallarm Console, go to **Security Testing** → **Schema-Based** → **Test runs** to view all test runs and their results.
-Here you can review security issues detected during the run, health checks, and the Docker output for the run:
+The **Test runs** tab lists every run started against any of your test policies. Each row shows:
+
+* Started / finished date and run duration.
+* Run title and policy used.
+* Target URL (taken from the Postman collection or environment).
+* Number of replayed requests.
+* **Credits** consumed by the run.
+* Number of detected security issues grouped by risk level.
+* Run status.
+
+Filter by policy, status, or test run title to narrow the list.
+
+
+
+For each completed run you can review the security issues detected, the health checks performed at the start of the run, and the Docker output captured during execution:
@@ -15,61 +29,101 @@ Here you can review security issues detected during the run, health checks, and
+Detected vulnerabilities are also published to the Wallarm Console's [**Security Issues**](../../api-attack-surface/security-issues.md) section with `Discovered by = Schema-Based Testing` and a link back to the originating test run, so they can be tracked, triaged, and resolved alongside vulnerabilities found by other Wallarm components.
+
## Test run details
-You can obtain test run details from Wallarm Cloud and from you Docker container output.
+Click a test run to open its details page. From here you can also:
+
+* Click **Download Results** to export the run report.
+* Click **Copy link** to share a direct link to this run with colleagues.
+
+The details page is organized into the following sections.
+
+
+
+### Health Checks
+
+Confirms that the inputs were valid and the run executed end-to-end:
+
+* **Postman collection validation** — the supplied collection was parsed successfully.
+* **Execution success check** — the run completed without unrecoverable errors.
+
+### Errors & Warnings
-### In Wallarm UI
+Lists any non-fatal problems encountered during the run (for example, individual requests that failed to replay). An empty section means the run completed cleanly.
-Click test run to expand and see its detailed technical information:
+### Tests
-
+Shows the engine's progress through the run as a sequence of stages:
-You can check:
+| Stage | What happens |
+|---|---|
+| **Generating** | The engine analyzes the collection and generates vulnerability hypotheses. |
+| **Ready** | Hypotheses are prepared; test cases are about to be executed. |
+| **Executing** | Generated tests are sent against the target application. |
+| **Improving** | The engine retries inconclusive tests with refined inputs. |
+| **Compiling** | Findings are compiled and mapped to security issues. |
+| **Completed** | The run is finished. |
-* Test run health: is specification/Postman collection valid and was the run successful.
-* Errors and warnings (if any) occurred while running.
-* Docker container output (with the **Copy to clipboard** capability).
+When a run is in progress, the current stage is highlighted; previous stages are marked complete.
-Also you can:
+### Strategies
-* Download JSON report for your test run.
-* Copy link to the test run details to share with colleagues.
+Below **Tests**, the run's results are grouped by [strategy](overview.md#strategies). Each strategy block expands into the list of **hypotheses** the engine produced for that strategy and the verdict for each one:
+
+| Verdict | Meaning |
+|---|---|
+| **Vulnerable** | The validation step confirmed the hypothesis — a real, reproducible issue was found. A linked security issue is created in **Security Issues**. |
+| **Not Vulnerable** | The validation step rejected the hypothesis. The application behaves as expected for this attack scenario. |
+
+Click any hypothesis to open its detail panel. The panel exposes four tabs:
+
+* **Hypothesis** — a description of what was tested: the targeted endpoint, the vulnerability under investigation, severity, and a step-by-step exploitation chain.
+* **Source Code** — the test script the engine generated and executed for this hypothesis. Downloadable for offline reproduction.
+* **Output** — the captured execution log of the test (requests, responses, intermediate decisions).
+* **Finding** — for confirmed issues, the structured finding that was promoted to **Security Issues** (vulnerability type, evidence, request/response excerpts).
+
+
### Docker container output
-You can find test run results in your Docker container output directly, for example:
+You can find test run progress and results in your Docker container output directly:
+
+
+
+A typical run ends with a summary similar to:
```
-Sep 2 18:26:40.222 INF STARTING with arguments test_profile_id=60 client_id=5 wallarm_api_host=https://us1.api.wallarm.com wallarm_api_token=*****FWmup send_logs=true fail_severity=high
-Sep 2 18:26:40.228 INF Running pre-flight checks
-Sep 2 18:26:40.698 INF Successfully authenticated with Wallarm API
-Sep 2 18:26:40.698 INF All pre-flight checks passed
-Sep 2 18:26:40.698 INF Requesting test policy test_profile_id=60
-Sep 2 18:26:41.926 INF Test policy received
-Sep 2 18:26:42.383 INF Running Postman workflow
-Sep 2 18:26:42.383 INF Getting postman configuration files test_profile_id=60
-Sep 2 18:26:43.168 INF Running target URL connectivity check with Newman
-Sep 2 18:27:40.723 INF Target URL connectivity check with Newman passed total_requests=47 failed_requests=9 failure_ratio=0.19148936170212766 threshold=0.75
-Sep 2 18:27:40.727 INF Starting Postman security testing workflow
-Sep 2 18:33:51.069 INF Postman security testing completed successfully
-Sep 2 18:33:51.069 INF Workflow completed successfully
-Sep 2 18:33:57.283 INF Security issues summary total_issues=17 severity_counts.high=16 severity_counts.medium=1
-Sep 2 18:33:57.410 INF Container logs exportedto the cloud
-Sep 2 18:33:57.411 ERR Exiting with code 1 due to security issues meeting fail-severity threshold fail_severity=high count=16
+INF Postman security testing completed successfully
+INF Workflow completed successfully
+INF Security issues summary total_issues=26 severity_counts.high=26
+ERR Exiting with code 1 due to security issues meeting fail-severity threshold fail_severity=high count=26
```
-In the example, pay your attention to exit with code 1 (failed tests) due to set [test run success criteria](setup.md#test-run-success-criteria).
+Note the exit with code `1` (failed tests) due to the configured [test run success criteria](setup.md#test-run-success-criteria).
+
+## Reviewing detected security issues
+
+When the run is finished, the **Security issues** column on the **Test runs** tab shows the number of confirmed findings and their distribution by risk level. Click that number to open the [**Security Issues**](../../api-attack-surface/security-issues.md) page filtered to this run.
+
+On the filtered Security Issues page you can:
+
+* Use the top widgets to see **Top vulnerable hosts**, **Security issues by types** (BFLA, BOLA, Authentication bypass, Information exposure, SQLi, Denial of Service, etc.), and **Statistics** by severity.
+* Refine by **Type**, **Risk**, **OWASP**, **Status**, **Incident**, or **Discovered by** filters. Schema-Based Testing findings carry `Discovered by = Schema-Based Testing` and the originating test run ID.
+* Open any issue to inspect its full details — request/response evidence, the generated description, OWASP mapping, and the linked test case from the originating test run.
+
+
## Downloading initial files
-From the **Schema-Based Testing** page, you can download files that you used for creating OAS or Postman-based test policies:
+From the **Schema-Based Testing** page, you can download the files used to create a test policy:
-* OAS: its specification.
-* Postman: Postman collection file, Postman environment file(s) if were used
+* The Postman collection file.
+* The Postman environment file(s), if attached.
To download files:
-1. In Wallarm Console, go to **API Security Testing** → **Schema-Based** → **Test policies** tab.
-1. Hover your policy, and click the edit icon. Policy edit dialog is displayed.
-1. In corresponding file field, click the download icon.
+1. In Wallarm Console, go to **Security Testing** → **Schema-Based** → **Test policies**.
+1. Hover over your policy and click the edit icon. The policy edit dialog opens.
+1. In the corresponding file field, click the download icon.
diff --git a/docs/latest/vulnerability-detection/schema-based-testing/overview.md b/docs/latest/vulnerability-detection/schema-based-testing/overview.md
index 0a3201b164..51630292c6 100644
--- a/docs/latest/vulnerability-detection/schema-based-testing/overview.md
+++ b/docs/latest/vulnerability-detection/schema-based-testing/overview.md
@@ -1,96 +1,115 @@
# Schema-Based Testing
-Wallarm's Schema-Based Testing is a dynamic application security testing (DAST) solution that enables "shift-left" security. It uses an API's schema (such as an OpenAPI specification or a Postman collection) as a blueprint to automatically generate and execute targeted security tests. By integrating into CI/CD pipelines, Schema-Based Testing allows development teams to proactively identify a wide range of vulnerabilities—including OWASP API Top 10 risks, business logic flaws, and input validation issues—early in the development process, making them easier and cheaper to fix.
+Wallarm's Schema-Based Testing is a dynamic application security testing (DAST) solution that enables "shift-left" security. It uses a [Postman collection](https://www.postman.com/product/collections/) — your existing functional tests — as a blueprint for security tests, and runs them as a Docker container that fits into CI/CD pipelines next to functional tests, smoke tests, and other security testing.
+
+Schema-Based Testing is built on an AI-driven scanning engine that goes beyond signature-based scanners:
+
+* It analyzes the application context, generates vulnerability hypotheses, builds attack chains, and validates each finding with an executable proof-of-exploit test before reporting it.
+* This approach detects multi-step issues such as broken object level authorization (BOLA), broken function level authorization (BFLA), business logic abuse, and mass assignment — vulnerabilities that traditional payload-based DAST tools struggle to catch.
+* Confirmed findings include a generated description, the test that reproduces the issue, and the exploitation log captured during the run, so each result is reproducible by the development team.
Schema-Based Testing capabilities:
-* Deep, dynamic analysis of API endpoints.
-* Detection of vulnerabilities in the application or API itself, as well as security misconfigurations in the underlying infrastructure or environment.
-* Visualization of found issues in the Wallarm Console's [**Security Issues**](../../api-attack-surface/security-issues.md) section.
-* Lightweight execution via Docker container, enabling embedding into your CI/CD pipeline alongside functional tests, smoke test, and other security testing.
+* Deep, dynamic analysis of API endpoints based on the supplied collection.
+* Detection of vulnerabilities listed in the [OWASP API Security Top 10](https://owasp.org/API-Security/editions/2023/en/0x11-t10/) and the OWASP Top 10, plus security misconfigurations exposed through the application's HTTP traffic.
+* Visualization of found issues in the Wallarm Console's [**Security Issues**](../../api-attack-surface/security-issues.md) section, with the originating test run as the source.
+* Lightweight execution via a Docker container, with run progress and aggregated results streamed back to Wallarm Cloud.
-
+
## How it works
Use Schema-Based Testing by fulfilling the following steps:
-1. **Create test policy**: specify the target application, provide its OpenAPI specification or Postman collection, base URL, and select the tests to run.
-1. **Copy Docker command**: find your test policy on the **Test policies** tab, click it, and copy the provided Docker command.
-1. **Run and monitor**: start the agent with the command. Track progress and view results on the **Test runs** tab.
+1. **Create test policy**: provide the Postman collection (and, if needed, environment file) that describes how to call the target API, then choose the [scan modes and strategies](#test-approaches) to run.
+1. **Copy Docker command**: open your test policy on the **Test policies** tab and copy the Docker command it provides. The command embeds the policy ID and the API token used to upload run results to Wallarm Cloud.
+1. **Run and monitor**: start the agent with the command. Track progress and view results on the **Test runs** tab; confirmed vulnerabilities also appear in **Security Issues**.

## Test basis
-Schema-Based Testing can base its tests on:
+Schema-Based Testing uses a **Postman collection** as the test basis. The functional tests inside the collection drive security testing: the engine replays the collection to learn the application, then generates and executes targeted security tests on top of it. Because Postman collections capture realistic, multi-request flows with authenticated users, this option works well for detecting business logic and access control vulnerabilities. See [details](setup.md#postman-collection-based-test-policies).
-* **OpenAPI specification (OAS)** - precise and machine-readable blueprint of your API allows to build efficient and reliable test suite for your application. You can use an OAS [exported from API Discovery](../../api-discovery/exploring.md#openapi-oas-export) or from any other source. OAS-based testing is focused on input validation, injection, and misconfiguration detection.
-* **RAML specification** - if your API is documented using [RAML (RESTful API Modeling Language)](https://raml.org/), you can upload it directly. RAML files are automatically converted to OpenAPI specifications, enabling the same comprehensive security testing. See [details](setup.md#raml-based-test-policies).
-* **Postman collection** - if you use the [**Postman**](https://www.postman.com/) API design platform, the **functional tests** from its [*collections*](https://www.postman.com/product/collections/) may be used to build security tests alongside. See [details](setup.md#postman-collection-based-test-policies). Postman collection-based testing is focused on complex business logic and access control vulnerabilities.
+The richer your collection (more endpoints, multiple authenticated users, complete environment variables), the broader the security coverage Schema-Based Testing can provide.
- !!! warning "Temporary limitation"
- Creating new policies based on Postman collections is temporarily not available. Existing policies that were previously created using Postman collections continue to work as expected.
+## Test approaches
-## Schema-Based Testing (Postman) vs API Security Testing via Postman
+A Postman-based test policy organizes scanning into two modes that you enable independently:
-Wallarm also offers [API Security Testing via Postman](../api-security-testing-via-postman/overview.md)—a lighter option that runs inside Postman Agent Mode with no Docker or CI/CD. Both options can use your Postman collections; choose based on how you work and how deep you need to go:
+| Scan mode | Purpose |
+|---|---|
+| **Passive Scan** | Inspects the HTTP traffic captured by replaying the Postman collection, without sending additional payloads. Detects exposure of sensitive data, missing security headers, insecure cookies, debug output, and similar issues observable in normal responses. |
+| **Active Scan** | Generates and sends targeted attack requests built from collection context, then validates each finding with an exploit test. Detects business logic, access control, injection, and other multi-step vulnerabilities. |
-| | **Schema-Based Testing** (Postman collection) | **API Security Testing via Postman** |
-|---|---|---|
-| **Use when** | You want automated, comprehensive DAST in CI/CD; you already have functional tests in Postman and want them to drive security tests. | You want a quick, conversational check inside Postman—ask in natural language and get results in the Agent chat in a few minutes. |
-| **How it runs** | Dynamic testing: sends real requests, uses your collection's functional tests as a blueprint to generate and run security tests. | Passive, design-level analysis; no attack payloads, no traffic replay. |
-| **Depth** | OWASP API Top 10, business logic, access control, input validation (injections, RCE, etc.), environment misconfigurations. | Auth gaps, data leaks, over-permissive endpoints, schema issues, basic BOLA/BOPLA—summarized for developers. |
-| **Where** | Docker-based; runs in your pipeline or locally; results in Wallarm Console (Test runs, Security Issues). | Inside Postman (Agent Mode); results in chat and in Wallarm Cloud. |
+Each scan mode uses one or more [strategies](#strategies). The set of enabled strategies determines which vulnerability classes are checked.
+
+## Strategies
+
+A **strategy** is a reusable scanning recipe used by Active Scan or Passive Scan. Each strategy targets one vulnerability class and contains the detection logic the engine applies during the run.
-In short: use **Schema-Based Testing** with a Postman collection when you need full DAST and pipeline integration; use API Security Testing via Postman for fast, in-Postman checks with minimal setup.
+Strategies fall into two categories:
-## Test types
+* **Default strategies** — provided by Wallarm, kept up to date with new attack patterns, and available to all accounts that have Schema-Based Testing enabled. They cannot be edited, only viewed and toggled per policy.
+* **Custom strategies** — created by you to extend the engine with checks specific to your application or threat model. A custom strategy is bound to your account and can be enabled in any of your test policies.
-For OpenAPI specification-based tests, Schema-Based Testing uses several types of tests to detect security issues:
+Each strategy is either of type **Active** (sends attack requests during a run) or **Passive** (analyzes captured traffic only).
-* **Authentication bypass** checks for risks of [bypassing](../../attacks-vulns-list.md#authentication-bypass) the authentication mechanisms or exploiting their weaknesses.
-* **Environment misconfiguration tests** check for vulnerabilities and misconfigurations in the environment or infrastructure the application and APIs run on (not the API logic). Examples:
+### Default strategies
- * Exposed source code, backups, configuration files.
- * Accessible `.git`, `.env`, or system files.
- * Insecure web server settings (e.g., directory listing, weak TLS).
+Default passive strategies:
-* **GraphQL vulnerability detection** checks for 10 GraphQL most popular misconfigurations (API2, API4).
+| Strategy | Purpose |
+|---|---|
+| **Data Exposure** | Detects unauthorized exposure of sensitive user data, authentication secrets, and third-party credentials in API responses. |
+| **Security Headers Misconfiguration** | Flags missing browser security headers on rendered content and improper cache-control directives on responses carrying sensitive data. |
+| **Secrets Management** | Detects credential-grade secrets transmitted over insecure channels and session cookies set without proper security attributes. |
+| **Service Internals** | Detects exposure of internal server details through debug output, stack traces, version fingerprinting, and unintended static file serving. |
+| **Web Vulnerabilities** | Identifies common web application vulnerabilities through pattern analysis, including open redirects, SSRF, injection syntax, and cross-site scripting markup in request inputs. |
-* **Input parameter tests** check each input point (parameters, headers, etc.) defined in the OpenAPI specification for application-level vulnerabilities. Covered vulnerabilities:
+Default active strategies:
- * Command injection
- * CRLF injection
- * LFI / RFI
- * NoSQL injection
- * Open redirect
- * Path traversal
- * Remote code execution (RCE)
- * SQL injection
- * SSRF
- * SSTI
- * XSS
- * XXE
- * Infoleak
+| Strategy | Purpose |
+|---|---|
+| **BOLA (Broken Object Level Authorization)** | Checks whether one user can access or modify another user's resources by reusing object identifiers with their own credentials. |
+| **BFLA (Broken Function Level Authorization)** | Verifies whether principals can invoke functions, workflow steps, or management actions reserved for higher-privilege roles or outside their tenant. |
+| **Business Logic Abuse** | Detects flaws that allow attackers to gain unauthorized value, bypass workflow constraints, or manipulate quantities, states, and application-specific invariants. |
+| **Excessive Data Exposure** | Identifies API responses that return sensitive, internal, or unnecessary fields beyond what the client needs. |
+| **JWT Authentication Flaws** | Tests JSON Web Token implementations for algorithm manipulation, signature bypass, claim tampering, weak secret brute-force, missing expiration or audience/issuer validation, and replay of non-revocable tokens. |
+| **Mass Assignment** | Detects APIs that bind all client-supplied fields directly to internal models, allowing unauthorized modification of restricted attributes (for example, roles, status, pricing). |
+| **NoSQL Injection** | Sends operator-based payloads into query-driving fields to bypass authentication, expand result sets, or perform unauthorized data modifications. |
+| **Resource Exhaustion** | Detects missing rate limits, brute-force exposure, and client-controlled amplification that lets attackers degrade availability or scale server-side work via unbounded inputs. |
+| **SQL Injection** | Targets query-driving parameters with SQL syntax payloads to detect authentication bypass, unauthorized data access, data modification, and schema disclosure. |
+| **SSRF (Server-Side Request Forgery)** | Identifies endpoints where user-controlled input can influence backend outbound network requests to attacker-controlled or internal destinations. |
+| **Unauthenticated Access** | Detects endpoints that allow reading, modifying, or deleting business resources without requiring authentication, including cases where predictable selectors make objects directly addressable. |
+
+For instructions on enabling, customizing, and creating strategies, see [Managing strategies](setup.md#managing-strategies).
+
+## Schema-Based Testing vs API Security Testing via Postman
+
+Wallarm also offers [API Security Testing via Postman](../api-security-testing-via-postman/overview.md) — a lighter solution that runs inside Postman Agent Mode with no Docker or CI/CD. Both products take a Postman collection as input; choose based on how you work and how deep you need to go:
+
+| | **Schema-Based Testing** | **API Security Testing via Postman** |
+|---|---|---|
+| **Use when** | You want automated, comprehensive DAST embedded in CI/CD; you already have functional tests in Postman and want them to drive security tests. | You want a quick, conversational check inside Postman — ask in natural language and get results in the Agent chat in a few minutes. |
+| **How it runs** | Dynamic testing as a Docker container: replays the collection, then generates and validates targeted security tests against the application. | Passive, design-level analysis; no attack payloads, no traffic replay. |
+| **Depth** | OWASP API Top 10, business logic, access control, input validation (injections, RCE, etc.), and traffic-observable misconfigurations. | Auth gaps, data leaks, over-permissive endpoints, schema issues, basic BOLA/BOPLA — summarized for developers. |
+| **Where** | Docker container runs in your pipeline or locally; results in Wallarm Console (Test runs, Security Issues). | Inside Postman (Agent Mode); results in chat and in Wallarm Cloud. |
-## Run types
+In short: use **Schema-Based Testing** when you need full DAST and pipeline integration; use API Security Testing via Postman for fast, in-Postman checks with minimal setup.
-Any test run via Schema-Based Testing:
+## How runs are configured
-* Is actually a Docker run
-* Is based on some [schema](#test-basis) (OAS or Postman)
-* Requires [token](setup.md#token) from Wallarm
-* Is displayed in **Test runs**, results are displayed in **Security Issues** (see [details](explore.md#test-runs-and-results))
+Schema-Based Testing always runs the same way — as a Docker container on your side that uses a Postman collection as the test basis, authenticates to Wallarm Cloud with a [token](setup.md#token), and reports results to **Test runs** and **Security Issues** (see [details](explore.md#test-runs-and-results)).
-In the same time, you are free to choose whether to use Wallarm's UI:
+What differs is how you provide the run parameters to the container:
-* **With UI**: you create test policy in Wallarm, it contains token, your schema and all testing parameters and provides you a Docker run command **linked** to it.
-* **Without UI**: having token, you form Docker run command yourself defining all parameters locally. Note that you can still use Wallarm's [wizard](setup.md#running-without-test-policy) to help you with that.
-* **Combination**: you create test policy in Wallarm, it contains token, your schema and all testing parameters and provides you a Docker run command linked to it, but **in this linked** command you **override** any parameters, like use local file instead of the one attached to the policy. What is not overridden, is taken from the policy.
+* **From a test policy**: you create a test policy in Wallarm Console; it stores the collection, environment file(s), and selected scan modes and strategies, and produces a Docker command linked to the policy.
+* **Locally**: you build the Docker command yourself, passing the collection and other parameters as flags. The Wallarm Console [wizard](setup.md#running-without-test-policy) can compose this command for you.
+* **Mixed**: you start from a policy's Docker command, but **override** individual parameters at run time (for example, point to a local collection file instead of the one stored in the policy). Anything not overridden is taken from the policy.
-See details on each variant [here](setup.md#docker-run).
+See [Docker run](setup.md#docker-run) for details.
## Enabling and setup
-To start using Schema-Based Testing, enable and configure it as described in [Schema-Based Testing Setup](setup.md).
\ No newline at end of file
+To start using Schema-Based Testing, enable and configure it as described in [Schema-Based Testing Setup](setup.md).
diff --git a/docs/latest/vulnerability-detection/schema-based-testing/setup.md b/docs/latest/vulnerability-detection/schema-based-testing/setup.md
index 0deeff0e57..68091cb89f 100644
--- a/docs/latest/vulnerability-detection/schema-based-testing/setup.md
+++ b/docs/latest/vulnerability-detection/schema-based-testing/setup.md
@@ -7,449 +7,276 @@ This article describes how to enable and configure Wallarm's [Schema-Based Testi
Schema-Based Testing is disabled by default. To enable:
1. Contact sales@wallarm.com to activate the [**Security Testing** subscription plan](../../about-wallarm/subscription-plans.md#core-subscription-plans) for your account.
-1. Go to the **Security Testing** → **Schema-Based** → **Test policies** tab and create [at least one policy](#test-policy-types).
+1. Go to **Security Testing** → **Schema-Based** → **Test policies** and create [at least one policy](#test-policy-types).
+
+After both steps are completed, the **Schema-Based** entry appears in the left menu under **Security Testing**.
## Prerequisites
### Token
-Schema-Based Testing requires a [token](../../user-guides/settings/api-tokens.md) for authorizing data exchange between running Docker container and Wallarm Cloud. The token can be created in two ways:
+Schema-Based Testing requires a [token](../../user-guides/settings/api-tokens.md) for authorizing data exchange between the running Docker container and Wallarm Cloud. The token can be created in two ways:
-* **Automatically** - Schema-Based Testing will create it automatically and include into the `docker run` command on first attempt to copy Docker command from any policy. Other policies will re-use already existing token.
-* **Manually** - in Wallarm Console, go to **Settings** → **API Tokens**, click **New token**; on creation, set **Token usage** to `Schema-Based Testing agent`. All policies will use this token.
+* **Automatically** — Schema-Based Testing creates the token automatically and embeds it into the `docker run` command on the first attempt to copy a Docker command from any policy. Other policies reuse the same token.
+* **Manually** — in Wallarm Console, go to **Settings** → **API Tokens**, click **New token**; on creation, set **Token usage** to `Schema-Based Testing agent`. All policies will use this token.
-### Whitelist
+### Allowlist
-When you are planning to run Wallarm's Schema-Based Testing against domains protected by some security tools, it is recommended to add the client IP (IP from where the Docker command is being run) to the allowlist, otherwise majority of requests will be blocked and the vulnerabilities will not be found.
+When you plan to run Schema-Based Testing against domains protected by some security tools, add the client IP (the IP from which the Docker command is run) to the allowlist. Otherwise the majority of requests will be blocked and vulnerabilities will not be found.
-This includes the case when Wallarm itself is used as the protection tool for these domains - see details on Wallarm's allowlist [here](../../user-guides/ip-lists/overview.md).
+This applies when Wallarm itself protects the target domain — see details on Wallarm's allowlist [here](../../user-guides/ip-lists/overview.md).
## Test policy types
-You can configure test policy [based](overview.md#test-basis) on OpenAPI specification (OAS), RAML specification, or Postman collection. Note that one test policy is aimed at only one type of testing.
-
-* OAS and RAML are more focused on input validation, injection, misconfiguration detection
-* Postman - on complex business logic and access control vulnerabilities
-
-## OAS-based test policies
-
-OpenAPI specification (OAS)-based test policy defines persistently:
-
-* Application's **OpenAPI specification**
-* Tests to run
-
-Besides persistent parameters that are the same for any test run, each test policy may optionally include parameters that can be overridden during each next test run (**Runtime parameters**). Re-defining the runtime parameters can be useful for embedding of Docker into the CI/CD pipelines:
-
-* Application's **Target URL**
-
- (although can be redefined during each run, some initial value is required)
-
-* Authentication parameters
-
-To configure test policy:
-
-1. Go to Wallarm Console → **Security Testing** → **Schema-Based** → **Test policies**.
-1. Click **Add policy**, attach OpenAPI specification file.
-
- !!! info "Using OAS from API Discovery"
- You can use an OpenAPI specification exported from [API Discovery](../../api-discovery/exploring.md#openapi-oas-export). In **API Discovery**, select a host, click **Download report** → **OpenAPI (OAS 3.1, JSON)** → **Generate OAS**, then attach the downloaded file when creating the test policy.
-1. Select [test types](overview.md#test-types) to run.
-1. Set **Target URL** (can be overridden dynamically during each test run).
-1. Optionally, add authentication **Runtime parameters**.
-
- 
-
-## RAML-based test policies
-
-If your API is documented using RAML (RESTful API Modeling Language), you can create test policies directly from RAML specifications. Wallarm automatically converts RAML files to OpenAPI specifications internally, enabling the same comprehensive security testing available for OAS-based policies.
-
-RAML-based test policy defines persistently:
-
-* Application's **RAML specification**
-* Tests to run
-
-Besides persistent parameters, each test policy may include **Runtime parameters** that can be overridden during each test run:
-
-* Application's **Target URL** (although can be redefined during each run, some initial value is required)
-* Authentication parameters
-
-To configure test policy:
-
-1. Go to Wallarm Console → **Security Testing** → **Schema-Based** → **Test policies**.
-1. Click **Add policy**, select **RAML spec** as the source, and upload your RAML specification file.
-1. Select [test types](overview.md#test-types) to run.
-1. Set **Target URL** (can be overridden dynamically during each test run).
-1. Optionally, add authentication **Runtime parameters**.
-
- 
+A test policy in Schema-Based Testing is currently configured on top of a **Postman collection** — see [test basis](overview.md#test-basis). One test policy targets one application and one set of [scan modes and strategies](overview.md#test-approaches).
## Postman collection-based test policies
-!!! warning "Temporary limitation"
- Creating new policies based on Postman collections is temporarily not available. Existing policies that were previously created using Postman collections continue to work as expected - only the creation of new Postman-based policies is currently disabled.
-
-With Postman-based security testing you can automate security scans alongside your regular API tests, ensuring that each API run is thoroughly tested for vulnerabilities.
-
-!!! info "API functional tests as basis"
- Wallarm's schema-based testing leverages your functional tests to generate security tests. The more complete your functional tests are, the broader the security coverage Wallarm can provide. More APIs, users, and requests mean richer and more effective security testing.
+Postman-based testing automates security scans alongside your regular API tests, ensuring that each API run is thoroughly tested for vulnerabilities. The richer your collection (more endpoints, multiple authenticated users, complete environment variables), the broader the security coverage Schema-Based Testing can provide.
### Pre-check of Postman collection
-Before using Postman data for schema-based security testing:
+Before using Postman data for security testing:
-1. Ensure that you collection and environment files contain:
+1. Ensure that your collection and environment files contain:
* Functional tests for API endpoints
* Location of the target application
* All environment variables set
* Necessary credentials to authenticate in the target application
-1. (Recommended) Check whether the Postman collection is working. For example, this can be done by running the command:
+1. (Recommended) Verify that the Postman collection works. For example:
```
newman run my_collection.json -e my_environment.json
```
- This can tell you in advance whether there are any problems, for example, related to the quality of the Postman collection, the availability of the target URL, or that all the necessary variables are specified.
+ This surfaces problems related to collection quality, target URL availability, or missing variables in advance.
!!! warning "Valid Postman collection"
- If the Postman collection itself cannot work, then the schema-based security testing will not work either.
+ If the Postman collection itself cannot run, security testing based on it cannot run either.
-### Configuring test policy in Wallarm
+### Configuring the test policy
-In Wallarm, Postman collection-based test policy defines:
+A Postman-based test policy defines:
+* **Policy name**.
* Application's **Postman collection**.
* **Postman environment file(s)** (optional if all configuration is stored in the main collection file).
+* **Working Modes** — which scan modes ([Active Scan](overview.md#test-approaches), [Passive Scan](overview.md#test-approaches)) are enabled and which [strategies](overview.md#strategies) participate in each.
- !!! info "Target URL and authentication"
- Application's **Target URL** and authentication parameters are defined in the Postman collection or environment files.
+!!! info "Target URL and authentication"
+ For Postman-based policies, the application's **Target URL** and authentication parameters are taken from the Postman collection or environment files. These cannot be redefined per Docker run.
-* Test case selection is not currently supported for security testing based on Postman collections.
+To configure a test policy:
-To configure test policy:
+1. Go to Wallarm Console → **Security Testing** → **Schema-Based** → **Test policies** and click **Create test policy**.
-1. Go to Wallarm Console → **Security Testing** → **Schema-Based** → **Test policies**.
-1. Click **Add policy**, set **Source** to **Postman collection**.
-1. Attach Postman collection file.
-1. Optionally, attach Postman environment file(s). Attaching 2 files allows running testing twice with different variable values (for example, different credentials) and then comparing results.
-
- 
+ 
-### Business logic security testing
+1. Provide a **Policy name**.
+1. Set **Source** to **Postman collection** and attach the Postman collection file.
+1. Optionally, attach Postman environment file(s). Attaching two files runs testing twice with different variable values (for example, different credentials) and then compares results.
+1. Under **Working Modes**, enable **Active Scan**, **Passive Scan**, or both. For each enabled mode, click **Advanced settings** to choose which [strategies](#managing-strategies) participate. By default, all strategies of the corresponding type are enabled — you can leave the defaults or narrow the selection.
+1. Save the policy.
-For business logic testing ([OWASP API1:2023 Broken Object Level Authorization (BOLA)](https://github.com/OWASP/API-Security/blob/master/editions/2023/en/0xa1-broken-object-level-authorization.md) and [OWASP API5:2023 Broken Function Level Authorization (BFLA)](https://github.com/OWASP/API-Security/blob/master/editions/2023/en/0xa5-broken-function-level-authorization.md)) Wallarm's Schema-Based Security Testing requires API traffic from at least two different authenticated users, preferably with varying privileges (e.g., admin and regular users). This diversity enables more effective business logic security tests and provides a more thorough assessment.
+ 
-| Business logic vulnerability | Input requirements |
-| ---- | ---- |
-| [OWASP API1:2023 Broken Object Level Authorization (BOLA)](https://github.com/OWASP/API-Security/blob/master/editions/2023/en/0xa1-broken-object-level-authorization.md) | Testing for this vulnerability requires multiple authenticated users to demonstrate whether proper object-level authorization checks are in place. |
-| [OWASP API5:2023 Broken Function Level Authorization (BFLA)](https://github.com/OWASP/API-Security/blob/master/editions/2023/en/0xa5-broken-function-level-authorization.md) | Testing for this vulnerability requires requests from users with different privilege levels to evaluate whether function-level authorization is enforced consistently. |
+## Managing strategies
-#### Example 1: Using Postman collections with requests from two users
+A [strategy](overview.md#strategies) is a reusable scanning recipe used by Active Scan or Passive Scan. Wallarm ships with a set of [default strategies](overview.md#default-strategies); you can also create your own.
-Do the following:
+Strategies are managed on the **Security Testing** → **Schema-Based** → **Strategies** tab. Use the **All / Active / Passive** filter to narrow the list. Default strategies are read-only — open them to inspect the description and the vulnerability classes they cover. Custom strategies can be edited and deleted.
-1. Create a Postman collection containing requests from two authenticated users. For example, in the target application, include login and activity requests from `User A` and `User B` in the same collection.
+
- 
+### Creating a custom strategy
-1. Verify that all requests are executed correctly.
-1. Create a test policy with the created Postman collection.
+To extend the engine with checks specific to your application or threat model:
-#### Example 2: Using Postman environments for multiple users
+1. Go to **Security Testing** → **Schema-Based** → **Strategies** and click **Create strategy**.
+1. Provide a **Name**. The slug is generated automatically; it must be lowercase, may contain digits and underscores, and must not collide with a reserved or already-existing slug.
+1. Choose the strategy type:
-Do the following:
+ * **Passive** — analyzes captured traffic without sending additional requests. Provide the detection logic in the **Content** field.
+ * **Active** — sends targeted requests during the run. Provide the search prompt in the **Search content** field; the engine uses it to derive hypotheses to test against the application.
-1. Create two Postman environment files, each holding the credentials for a different authenticated user, e.g.:
+1. Save the strategy. It becomes available immediately on the Strategies tab and can be enabled in any new or existing test policy.
- * `env1.json` for `User A`
- * `env2.json` for `User B`
+### Enabling strategies in a policy
-1. Create a test policy that uses your Postman collection and both environment files.
-
- In this setup, the collection is executed twice - once with `env1.json` (`User A`) and once with `env2.json` (`User B`) - so each request runs under both user contexts.
+Open a test policy → **Working Modes** section. For each mode (Active Scan, Passive Scan), toggle the mode on, click **Advanced settings**, and select which strategies participate. Disabling a mode disables all of its strategies for that policy.
## Editing existing policy
-You can edit previously created policies: while clicking policy itself opens its Docker command info, you can click the edit button to access the edit dialog:
-
-
+You can edit previously created policies. Click a policy to open its Docker command details, or use the edit button to access the edit dialog.
## Docker run
### Requirements
-The Docker container should have network connectivity:
+The Docker container needs network connectivity:
* To the API being tested
-* To the Wallarm Cloud (US or EU):
+* To the Wallarm Cloud (US, EU, or ME):
--8<-- "../include/cloud-ip-by-request.md"
### Running with test policy
-As test policy is [created](#test-policy-types), it provides you with the Docker run command which allows you start tests for your application:
+Once a test policy is [created](#test-policy-types), it provides a Docker run command that starts security testing for your application:
1. Go to Wallarm Console → **Security Testing** → **Schema-Based** → **Test policies**.
-1. Click you policy. The policy's Docker command will be displayed.
-1. If necessary, redefine Docker log level and format, and [test run success criteria](#test-run-success-criteria). This adds extra [variables](#environment-variables) to the command.
-
- 
-
-1. Copy command and run it or embed into your CI/CD pipeline. This will run security tests selected in the policy for your application.
-
- Remember that, for OAS-based run, you can override the policy's **Runtime parameters** on each run by adding the corresponding `-e` parameters to the Docker `run` command, for example:
-
- ```
- -e TARGET_URL="http://dvapi.st.wallarm.tools"
- -e AUTH_HEADER="Authorization: Bearer "
- ```
+1. Click your policy. The policy's Docker command is displayed.
+1. If necessary, redefine the Docker log level and format, and the [test run success criteria](#test-run-success-criteria). These additions add extra [variables](#environment-variables) to the command.
- You can simplify re-defining these parameters by selecting the **Rewrite authentication data** and/or **Rewrite target URL** checkboxes that add to the command:
+ 
- ```
- -e AUTH_HEADER="${AUTH_HEADER}" -e TARGET_URL="${TARGET_URL}"
- ```
-
+1. Copy the command and run it, locally or from a CI/CD pipeline, on a machine that can reach the target application. This runs the security tests selected in the policy.
1. View run statistics and [test run results](explore.md) on the **Test runs** tab.
### Running without test policy
-Having token, you can form Docker run command yourself defining all parameters locally. Note that you can still use Wallarm's wizard to help you with that.
+With a token, you can build the Docker run command yourself, defining all parameters locally. You can still use the Wallarm Console wizard to compose the command.
-To use wizard:
+To use the wizard:
-1. Go to **Schema-Based Testing** section.
-1. Click the **Generate test run command** button.
-1. Select appropriate parameters, the wizard will compose the Docker run command correspondingly.
+1. Go to **Security Testing** → **Schema-Based** and click **Generate test run command**.
+1. Select the parameters; the wizard composes the Docker run command accordingly:
- 
+ * **Log level** — `Info` (default), `Debug`, `Warn`, `Error`.
+ * **Log format** — `Colored` (default), `JSON`, `Text`.
+ * **Fail on risk level** — `High` (default), `Critical`, `Medium`, `Low`, `Info`. See [Test run success criteria](#test-run-success-criteria).
1. Copy the command.
1. Replace the placeholders with actual values.
-1. You have the command.
-
-Note that:
+1. Run the command on a machine that can reach the target application.
-* If wizard is left with default values, it does not add anything additional to Docker command.
-* **Export input data to the Cloud** if you use this, OAS or Postman collection file that you use locally to run tests, will be uploaded to **Test runs** for improved debugging if needed later.
+If the wizard is left at default values, it does not add anything beyond the required environment variables to the Docker command.
### Running combination
-You create test policy in Wallarm that will contains token, your schema and all testing parameters and provide you a Docker run command linked to it, but **in this linked** command you **override** any parameters, like use local file instead of the one attached to the policy. What is not overridden, is taken from the policy.
+You can create a test policy in Wallarm that contains the token, collection, and all test parameters and provides a Docker run command linked to it, but **in this linked** command **override** any parameters at run time (for example, use a local collection file instead of the one attached to the policy). Anything not overridden is taken from the policy.
-See details on how to use the policy with local override in the Docker [`--help`](#available-flags).
+For details on overriding parameters from the linked policy, see the Docker [`--help`](#available-flags) output.
### Environment variables
-When you create and save a test policy in Wallarm, it automatically creates a Docker run command, adds all required `-e` variables and sets values for them. Generally, variables aim to tell Docker container to which account in Wallarm Cloud to connect and which test policy to take as the basis for testing of your application:
+When you create and save a test policy in Wallarm, the resulting Docker run command includes all required `-e` variables and their values. The variables tell the Docker container which Wallarm Cloud account to connect to and which test policy to use as the basis for testing:
Environment variable | Description| Required
--- | ---- | ----
`WALLARM_API_HOST` | Wallarm API server:- `us1.api.wallarm.com` for the US Cloud
- `api.wallarm.com` for the EU Cloud
- `me1.api.wallarm.com` for the ME Cloud
| Yes
-`WALLARM_API_TOKEN` | Wallarm's `Schema-Based Testing agent` API token. See details [here](#token). | Yes
-`WALLARM_TESTING_POLICY_ID` | ID of [test policy](#test-policy-types) containing all testing configuration. | Yes
-`FAIL_SEVERITY` | Defines [test run success criteria](#test-run-success-criteria) used when running tests as a part of a specific CI/CD pipeline. | No
-`TARGET_URL` | For OAS-based run only. If set, overrides the target URL specified in test policy itself. | No
-`AUTH_HEADER` | For OAS-based run only. If set, overrides the authentication data specified in test policy itself. | No
+`WALLARM_API_TOKEN` | Wallarm `Schema-Based Testing agent` API token. See details [here](#token). | Yes
+`WALLARM_CLIENT_ID` | Numeric identifier of your Wallarm client account. The Console embeds it automatically when copying the command. | Yes
+`WALLARM_TESTING_POLICY_ID` | ID of the [test policy](#test-policy-types) containing the test configuration. Required for runs linked to a policy. | Conditional
+`FAIL_SEVERITY` | Defines [test run success criteria](#test-run-success-criteria) for runs that are part of a CI/CD pipeline. | No
### Available flags
-You can use flags to modify behavior of Wallarm's Schema-Based Testing running as Docker container. To see the full list of available flags, use:
+You can use flags to modify the behavior of Schema-Based Testing running as a Docker container. To see the full list of available flags, use:
```
--help
```
-The outup will be something like:
+The output looks like this:
-=== "OpenAPI specification (OAS)-based"
- ```
- Run OpenAPI security testing workflow.
-
- This command performs automated API security testing using OpenAPI specifications,
- executing comprehensive security tests against the target API and reporting vulnerabilities.
-
- OPERATING MODES:
-
- Standalone Mode:
- Use local OpenAPI specification file without Wallarm platform integration.
- Requires: --openapi-file and --target-url flags
-
- Example:
- docker run -v "$(pwd)/api-spec.yaml:/app/api-spec.yaml" \
- -e WALLARM_API_HOST="https://api.wallarm.com" \
- -e WALLARM_API_TOKEN="..." \
- wallarm/security-testing:v0.11.0 openapi \
- --openapi-file /app/api-spec.yaml \
- --target-url https://api.example.com
-
- Cloud Mode:
- Integrate with Wallarm platform using Test Policy.
- Requires: WALLARM_TESTING_POLICY_ID environment variable or --testing-policy-id flag
-
- Example (with local file override):
- docker run -v "$(pwd)/api-spec.yaml:/app/api-spec.yaml" \
- -e WALLARM_API_HOST="..." \
- -e WALLARM_API_TOKEN="..." \
- -e WALLARM_TESTING_POLICY_ID="..." \
- wallarm/security-testing:v0.11.0 openapi \
- --openapi-file /app/api-spec.yaml
-
- Example (uses specification from Test Policy):
- docker run \
- -e WALLARM_API_HOST="..." \
- -e WALLARM_API_TOKEN="..." \
- -e WALLARM_TESTING_POLICY_ID="..." \
- wallarm/security-testing:v0.11.0 openapi
-
- Configuration priority: CLI flags > Environment variables > Test Policy > Defaults
-
- Usage:
- security-testing openapi [flags]
-
- Flags:
- --auth-header string Authentication header in 'Name: Value' format (can be provided by Test Policy)
- -h, --help help for openapi
- --openapi-file string Path to local OpenAPI specification file (JSON or YAML)
- --target-url string Target application URL (can be provided by Test Policy)
- --test-types stringSlice Comma-separated list of test types to run (environment_misconfiguration, sql_injection, command_injection, ssrf, xxe, open_redirect, xss, path_traversal, ssti, lfi_rfi, crlf_injection, infoleak, nosql_injection, rce, graphql_vulnerability_detection, auth_bypass, input_validation)
-
- Global Flags:
- API:
- --send-logs Send logs to Wallarm API (default true)
- --testing-policy-id string Wallarm testing policy ID (optional, enables Test Policy integration)
- --wallarm-api-host string Wallarm API host URL (required)
- --wallarm-api-token string Wallarm API authentication token (required)
-
- GENERAL:
- --export-files Upload local files (--openapi-file, --postman-collection-file, --postman-environment-files) to Wallarm cloud
- --fail-severity string Set fail severity level (critical, high, medium, low, info) (default "high")
- --insecure Turn off SSL verification checks, and allow self-signed SSL certificates
- --test-run-title string Custom title for the test run
-
- PREFLIGHT-CHECKS:
- --preflight-check-timeout int Timeout in seconds for target URL connectivity checks (minimum: 10) (default "75")
- --skip-target-url-connectivity-check
- Skip checking target URL connectivity
-
- REPORTS:
- --no-summary Disable summary output to stdout
- -r, --report Enable report generation
- --report-format string Report format (json, csv, junit) (default "json")
- --report-output string Report output file path (default extension matches format: .json for JSON, .csv for CSV) (default "report/results.json")
- --report-pretty Pretty-print JSON output (default true)
-
- REQUEST-LOG:
- --request-log-output string Output file path for HAR request log (default "./results/request_log.har")
- --send-request-logs Send request logs to Wallarm API (default true)
-
- LOGGING:
- -f, --log-format string Set log format (json, colored, text) (default "colored")
- -l, --log-level string Set log level (debug, info, warn, error) (default "info")
-
- MTLS:
- --mtls-ca-cert string Path to CA certificate for server validation (PEM format)
- --mtls-client-cert string Path to client certificate file (PEM format)
- --mtls-client-key string Path to client private key file (PEM format, unencrypted)
- ```
-=== "Postman collection-based"
- ```
- Run Postman security testing workflow.
-
- This command performs automated API security testing using Postman collections,
- executing comprehensive security tests against the target API and reporting vulnerabilities.
-
- OPERATING MODES:
-
- Standalone Mode:
- Use local Postman collection without Wallarm platform integration.
- Requires: --postman-collection-file flag
-
- Example:
- docker run -v "$(pwd)/collection.json:/app/collection.json" \
- -e WALLARM_API_HOST="https://api.wallarm.com" \
- -e WALLARM_API_TOKEN="..." \
- wallarm/security-testing:v0.11.0 postman \
- --postman-collection-file /app/collection.json
-
- Cloud Mode:
- Integrate with Wallarm platform using Test Policy.
- Requires: WALLARM_TESTING_POLICY_ID environment variable or --testing-policy-id flag
-
- Example (with local files override):
- docker run -v "$(pwd)/collection.json:/app/collection.json" \
- -v "$(pwd)/env.json:/app/env.json" \
- -e WALLARM_API_HOST="..." \
- -e WALLARM_API_TOKEN="..." \
- -e WALLARM_TESTING_POLICY_ID="..." \
- wallarm/security-testing:v0.11.0 postman \
- --postman-collection-file /app/collection.json \
- --postman-environment-files /app/env.json
-
- Example (uses collection from Test Policy):
- docker run \
- -e WALLARM_API_HOST="..." \
- -e WALLARM_API_TOKEN="..." \
- -e WALLARM_TESTING_POLICY_ID="..." \
- wallarm/security-testing:v0.11.0 postman
-
- Configuration priority: CLI flags > Environment variables > Test Policy > Defaults
-
- Usage:
- security-testing postman [flags]
-
- Flags:
- -h, --help help for postman
- --postman-collection-file string Path to local Postman collection file (JSON)
- --postman-environment-files stringSlice
- Path(s) to Postman environment file(s) (JSON, supports multiple files)
-
- Global Flags:
- API:
- --send-logs Send logs to Wallarm API (default true)
- --testing-policy-id string Wallarm testing policy ID (optional, enables Test Policy integration)
- --wallarm-api-host string Wallarm API host URL (required)
- --wallarm-api-token string Wallarm API authentication token (required)
-
- GENERAL:
- --export-files Upload local files (--openapi-file, --postman-collection-file, --postman-environment-files) to Wallarm cloud
- --fail-severity string Set fail severity level (critical, high, medium, low, info) (default "high")
- --insecure Turn off SSL verification checks, and allow self-signed SSL certificates
- --test-run-title string Custom title for the test run
-
- PREFLIGHT-CHECKS:
- --preflight-check-timeout int Timeout in seconds for target URL connectivity checks (minimum: 10) (default "75")
- --skip-target-url-connectivity-check
- Skip checking target URL connectivity
-
- REPORTS:
- --no-summary Disable summary output to stdout
- -r, --report Enable report generation
- --report-format string Report format (json, csv, junit) (default "json")
- --report-output string Report output file path (default extension matches format: .json for JSON, .csv for CSV) (default "report/results.json")
- --report-pretty Pretty-print JSON output (default true)
-
- REQUEST-LOG:
- --request-log-output string Output file path for HAR request log (default "./results/request_log.har")
- --send-request-logs Send request logs to Wallarm API (default true)
-
- LOGGING:
- -f, --log-format string Set log format (json, colored, text) (default "colored")
- -l, --log-level string Set log level (debug, info, warn, error) (default "info")
-
- MTLS:
- --mtls-ca-cert string Path to CA certificate for server validation (PEM format)
- --mtls-client-cert string Path to client certificate file (PEM format)
- --mtls-client-key string Path to client private key file (PEM format, unencrypted)
- ```
+```
+Run Postman security testing workflow.
+
+This command performs automated API security testing using Postman collections,
+executing comprehensive security tests against the target API and reporting vulnerabilities.
+
+OPERATING MODES:
+
+Standalone Mode:
+ Use local Postman collection without Wallarm platform integration.
+ Requires: --postman-collection-file flag
+
+ Example:
+ docker run -v "$(pwd)/collection.json:/app/collection.json" \
+ -e WALLARM_API_HOST="https://api.wallarm.com" \
+ -e WALLARM_API_TOKEN="..." \
+ wallarm/security-testing:v0.14.1 postman \
+ --postman-collection-file /app/collection.json
+
+Cloud Mode:
+ Integrate with Wallarm platform using Test Policy.
+ Requires: WALLARM_TESTING_POLICY_ID environment variable or --testing-policy-id flag
+
+ Example (with local files override):
+ docker run -v "$(pwd)/collection.json:/app/collection.json" \
+ -v "$(pwd)/env.json:/app/env.json" \
+ -e WALLARM_API_HOST="..." \
+ -e WALLARM_API_TOKEN="..." \
+ -e WALLARM_TESTING_POLICY_ID="..." \
+ wallarm/security-testing:v0.14.1 postman \
+ --postman-collection-file /app/collection.json \
+ --postman-environment-files /app/env.json
+
+ Example (uses collection from Test Policy):
+ docker run \
+ -e WALLARM_API_HOST="..." \
+ -e WALLARM_API_TOKEN="..." \
+ -e WALLARM_TESTING_POLICY_ID="..." \
+ wallarm/security-testing:v0.14.1 postman
+
+Configuration priority: CLI flags > Environment variables > Test Policy > Defaults
+
+Usage:
+security-testing postman [flags]
+
+Flags:
+-h, --help help for postman
+--postman-collection-file string Path to local Postman collection file (JSON)
+--postman-environment-files stringSlice
+ Path(s) to Postman environment file(s) (JSON, supports multiple files)
+
+Global Flags:
+API:
+--send-logs Send logs to Wallarm API (default true)
+--testing-policy-id string Wallarm testing policy ID (optional, enables Test Policy integration)
+--wallarm-api-host string Wallarm API host URL (required)
+--wallarm-api-token string Wallarm API authentication token (required)
+
+GENERAL:
+--export-files Upload local files (--postman-collection-file, --postman-environment-files) to Wallarm cloud
+--fail-severity string Set fail severity level (critical, high, medium, low, info) (default "high")
+--insecure Turn off SSL verification checks, and allow self-signed SSL certificates
+--test-run-title string Custom title for the test run
+
+PREFLIGHT-CHECKS:
+--preflight-check-timeout int Timeout in seconds for target URL connectivity checks (minimum: 10) (default "75")
+--skip-target-url-connectivity-check
+ Skip checking target URL connectivity
+
+REPORTS:
+--no-summary Disable summary output to stdout
+-r, --report Enable report generation
+--report-format string Report format (json, csv, junit) (default "json")
+--report-output string Report output file path (default extension matches format: .json for JSON, .csv for CSV) (default "report/results.json")
+--report-pretty Pretty-print JSON output (default true)
+
+REQUEST-LOG:
+--request-log-output string Output file path for HAR request log (default "./results/request_log.har")
+--send-request-logs Send request logs to Wallarm API (default true)
+
+LOGGING:
+-f, --log-format string Set log format (json, colored, text) (default "colored")
+-l, --log-level string Set log level (debug, info, warn, error) (default "info")
+
+MTLS:
+--mtls-ca-cert string Path to CA certificate for server validation (PEM format)
+--mtls-client-cert string Path to client certificate file (PEM format)
+--mtls-client-key string Path to client private key file (PEM format, unencrypted)
+```
-See the explanation for the `-fail-severity` flag in the next section.
+See the explanation for the `--fail-severity` flag in the next section.
### Test run success criteria
-If your include Wallarm's Schema-Based test runs into your CI/CD pipeline, it is important to define the criteria of test run success. You can do that in the test policy details by setting
-the **Fail on a risk level** to one of the values:
+When you include Schema-Based Testing in your CI/CD pipeline, define when a test run should be considered failed. Set **Fail on a risk level** in the test policy details to one of:
* critical
* high (default)
@@ -457,24 +284,21 @@ the **Fail on a risk level** to one of the values:
* low
* info
-Selecting any value different from default adds the `FAIL_SEVERITY` environment variable to the Docker run command.
-
-
+Selecting any value other than the default adds the `FAIL_SEVERITY` environment variable to the Docker run command. The selected value is also reflected in the policy's [Docker command panel](#running-with-test-policy) under **Fail on a risk level**.
Example:
```
-docker run -e WALLARM_API_HOST="us1.api.wallarm.com" -e WALLARM_API_TOKEN="" -e WALLARM_TESTING_POLICY_ID="" -e FAIL_SEVERITY="medium" --network="host" wallarm/security-testing:0.11.0
+docker run -e WALLARM_API_HOST="us1.api.wallarm.com" -e WALLARM_API_TOKEN="" -e WALLARM_CLIENT_ID="" -e WALLARM_TESTING_POLICY_ID="" -e FAIL_SEVERITY="medium" --network="host" wallarm/security-testing:0.14.1 postman
```
-
-You can also set test run success criteria with the `-fail-severity` flag, for example:
+You can also set the test run success criteria with the `--fail-severity` flag, for example:
```
-docker run -e WALLARM_API_HOST="us1.api.wallarm.com" -e WALLARM_API_TOKEN="" -e WALLARM_TESTING_POLICY_ID="" --network="host" wallarm/security-testing:0.11.0 --fail-severity medium
+docker run -e WALLARM_API_HOST="us1.api.wallarm.com" -e WALLARM_API_TOKEN="" -e WALLARM_CLIENT_ID="" -e WALLARM_TESTING_POLICY_ID="" --network="host" wallarm/security-testing:0.14.1 postman --fail-severity medium
```
-...will lead to the following: if testing finds at least 1 medium (or high or critical) security issue, the test run will exit with code 1 ("test failed").
+If testing finds at least one medium (or high or critical) security issue, the test run exits with code `1` ("test failed").
### Report generation
@@ -486,8 +310,9 @@ To enable report generation, use the `--report` flag along with `--report-format
docker run -v "$(pwd)/reports:/app/report" \
-e WALLARM_API_HOST="us1.api.wallarm.com" \
-e WALLARM_API_TOKEN="" \
+ -e WALLARM_CLIENT_ID="" \
-e WALLARM_TESTING_POLICY_ID="" \
- --network="host" wallarm/security-testing:0.11.0 openapi \
+ --network="host" wallarm/security-testing:0.14.1 postman \
--report --report-format json --report-output /app/report/results.json
```
@@ -501,21 +326,22 @@ Available report formats:
#### JUnit reports for CI/CD
-JUnit format is particularly useful for CI/CD integration as most CI/CD platforms natively support JUnit test reports for visualizing test results.
+JUnit format is particularly useful for CI/CD integration, since most CI/CD platforms natively support JUnit test reports for visualizing test results.
-Example for CI/CD pipeline:
+Example for a CI/CD pipeline:
```
docker run -v "$(pwd)/reports:/app/report" \
-e WALLARM_API_HOST="us1.api.wallarm.com" \
-e WALLARM_API_TOKEN="" \
+ -e WALLARM_CLIENT_ID="" \
-e WALLARM_TESTING_POLICY_ID="" \
- --network="host" wallarm/security-testing:0.11.0 openapi \
+ --network="host" wallarm/security-testing:0.14.1 postman \
--report --report-format junit --report-output /app/report/security-tests.xml \
--fail-severity high
```
-This generates a JUnit XML report that can be consumed by CI/CD tools to display test results and track security issues over time.
+This generates a JUnit XML report that CI/CD tools consume to display test results and track security issues over time.
### Request/response log export
@@ -527,8 +353,9 @@ By default, request logs are sent to the Wallarm API. You can also export them l
docker run -v "$(pwd)/logs:/app/results" \
-e WALLARM_API_HOST="us1.api.wallarm.com" \
-e WALLARM_API_TOKEN="" \
+ -e WALLARM_CLIENT_ID="" \
-e WALLARM_TESTING_POLICY_ID="" \
- --network="host" wallarm/security-testing:0.11.0 openapi \
+ --network="host" wallarm/security-testing:0.14.1 postman \
--request-log-output /app/results/request_log.har
```
@@ -551,8 +378,9 @@ To use mTLS, provide the client certificate, private key, and optionally the CA
docker run -v "$(pwd)/certs:/app/certs" \
-e WALLARM_API_HOST="us1.api.wallarm.com" \
-e WALLARM_API_TOKEN="" \
+ -e WALLARM_CLIENT_ID="" \
-e WALLARM_TESTING_POLICY_ID="" \
- --network="host" wallarm/security-testing:0.11.0 openapi \
+ --network="host" wallarm/security-testing:0.14.1 postman \
--mtls-client-cert /app/certs/client.crt \
--mtls-client-key /app/certs/client.key \
--mtls-ca-cert /app/certs/ca.crt
@@ -573,7 +401,7 @@ mTLS flags:
You can delete a test policy. If you do so:
-* Information on previous test runs will remain untouched
-* You will not be able to run Docker's command based on the deleted policy
-* If policy's Docker containers are running, they will continue to do so and the testing will continue
-* When policy's Docker containers stop, you will not be able to re-run them
\ No newline at end of file
+* Information on previous test runs remains untouched.
+* You will not be able to start a Docker run based on the deleted policy.
+* If the policy's Docker containers are running, they continue to run and the testing continues.
+* When the policy's Docker containers stop, you cannot re-run them.
diff --git a/images/vulnerability-detection/sbt-docker-container-output.png b/images/vulnerability-detection/sbt-docker-container-output.png
new file mode 100644
index 0000000000000000000000000000000000000000..1632d7ad662c4a9ef1a2150bacee597324d21999
GIT binary patch
literal 220175
zcmZ5{Wl$VZ)9ylWNYLQ!?!i5{v$(svJ4Y6
zJvB8oJyoY>YWke>^wUqrs;kPqMDs|j;D(q!8jowTS?U1ewZg83AeF|u=Vz`rjr%VOn1|4
zxV_>EKCKWBO9g&Q{{QSE8WA-2QC{JH+r8R%txQ;i#l>B~jB`18KnS_rOL(SqPRx;PmV+SPtFi-Lgu
zf3-NQaX9ST6zx^OH#0#l)#B%FF1O%_O^JDxq(DH?bP)V%O(+B{C|Oq^lrE&;_A|hA
zux1+`${aJrfU_Ym!&E4>=3Qv3}|6dLjVb
z{(3c`0pR>bV3&Zyf=74<{3Gxb66kGVrRX^4XxD4I5>58XriFKCraPPNkrr2$J5@M<
zbKhaVb;^`+fI!O#?L}8f^c=!jK{M7%0Dy!YK`
ze?PgISF)ZH{8_ED-nBdmi~vC}3;W3Ezrg__!JqYpsMJ#+&3#ICt#*@Sd$7;weL#|E(_uX5fI^ii-C%yY{<4r0
zIOscNwkC>#EyV>-7b%6%;R1Q6c8Fo3D=10c?E3_7F2xD`lj+y$LVaOHXCpOKQ`L*`
z1t=BN^K34K+Fu|*aM6@asEi7|3K9)I8QM)FO90@>GnHWFa4>%bn5z^MGJT^K1XWW;
z#Fkp}y0uQUyUIo2=tykIyvwZ2XMktngmq
zv-=-7fL(w2Y*ymW?Oco~*edPTE`cSbY;~PhW9lHi97D?4A-$@+@6e1Cbnw!>j6eHf
zZMnv#P_Ke*roQO*H-8r9GlLI`R+*2vy>*qz&_`ATMOtW(7`azcl5Amu05qU<+Q2bA
zwrV-N0~VVuor5FV73AGvg_d!P=_Bk(&+Zp0YXfDP;b0RqKXscwyzOD2F#Ac6Rb^AG
z!M25w0LBqf?Dp^SoF!2mh}W#q_^VBvKD(s~77ZD&`=F_?I^I+tC|MM7Y8d}Wvx*?^CD#gJ`4Ec7AvL&*s0hhBzKtz*M
z@#>FXKO-w;u#%`;em?KkFtcgQYfl6xv-PT^FaaS)!&A4
z5rjU@_M_iBgU0(
zC&{b*t`5+^;mB)2lSG7rYN4JzFSE>&o5A5n*Iiijp!>L`8Ut;UM+>lHlG)IpdhzeS
zlH0o)3gki1&ms)!f~6)Mmd}tJOwoqC$qZ;IgDvb^xp*8h#w0JxlGCg`H#)=f$&(@FZ+
z9<>;RZY&J`NqlzI`Dx#*Q3Fnk<6K_aAD6lv{1^LvfSIkTiDkReUPC<@`Et^4;xOmN
z2#GXvn!UP`1AHy-_l%qrNTpk_pwrphtk2VO=q)tRVNW~Vw`E_l>k#Q+$(Ej=sumbt
z{#eq3HIv(a1MHY)%n<4;piSy96B7~M|6uzi9|cgLTD)jyV$6o4uJ{FBy8HsUtYaz#
z)=8q|_dL>PL#1il(xfp)h{wbf`7IP%Ho^?!{O;(tr=J&}EosaNUVP#VB!JJBGG;|#
z_pVZ$tfdY>8BndxG($r4YUdlYn!u}TT7`F1Pkcn4RQg5Qrn5l21xl$y;MWwzG&*YlRz|vnF37t!
zvJExe4{lJRz1Hr8F#TuNf*$f;%0SOGuh+iD@u{h&aBCzQJFYK1Yn4?!U_PfE3GN?c
zpQE~q0oATO$%rrHq*!inAxXB}QhE*be0*TlRaIkbS!sT@rL;WN3D466;0u#PMn((7
z(QvFchgPmfUSz3&=sG?7s`yHox65Sc*9*QRKm5)or!SVTo(RNe4_JS-`;laTZg|
zXiRQnBly%0%UCb9ZuoecgyLn(M$qpp{&D>Vb4;5^nzy*U)7|>eVaa@zRGVZ(mMG~-{K{UoUVxCCB6feP(Qe_rXL%_}l!B=qTe1DG1`4|3%2NL7OkG3k
zr6LKehmN%SQ}GN7nmMC3tts4)p|QC1L!FHGALx7Rse6}*ieBYoRF5zI%{Dptard44
z@yxI6jj_8Q`Zo(v0-sG4(+Uw-=kz~3j5<;{Z+CD!tDTUks)k>N&>=M+9L`m56}@Bx
z;)?q(7$9MD4kccX9;fkrE!7z5(ocm(f-7{ZT|3v3qx~N4RR_p&YjUTVtqA-XKWO-QVM{Y9ds}9{$_8NiSY27pkga@dGsJ
zvGEIR)D07holhr^;;d@7;smDs)xy|n0W*KAR$E)O7ymZA{3Sr+v^Q&Sj_D%FqztS4T=VH@*!_5lTL4YSMzBf}7}F`pMiuozQM
z>=d~uozis;9ZC4vIfOGTC4l8%h^+tZEbsI+mnfdx!r@C<~nvZCHoL<(dkCtrwAfS%l$
zhe}F}B2E(-!?`MJ{`lZB!{gxc!evEpeqk9_-*n@LyDq(z84roein6xlPLsqw%dl~J
zACWp9q>NQ6&CipWU_TLQAG{SPNf>?9^8Q^>ly!ERb+!;x5w(AF!nY$v0S-`mHug=8
zA0o}uaLy!i%T|fKP5tZ@Hjf`m!m+^kL~$1YeS(v$`r=0L38o*h)&7ar3Td+
zH6)0asma)UY@Y|RP
zR4!j|&{h#Y$x$vt9pzKp9=g$C%Tq3Lo0s(I{AaS@P)T$@*%4Uw8Khe8bNTOPXU73b
zHe{ZLb6lk2uvKwAGn}qFrw8re7OKL?)JabI^!|3tqMq07?LU(mZKohnqt+Ek<}(x^~3
zH5eSlo#Eju)o~8qzG%Ya0PonAP5G0CYPhhn8BP~kh~)SL=Vjb0UmjFtr!xznJg(#o
ze4GhYX!65l$&7iv_kxeL-mM5I)?o1){B!y>nmmn%0|l3gW2-2Z>r*}0Mw^pvAiB|{
z+K*7p3j+lZiZ$wm#uxVv|KY{r!6C{6AOVEX%J1&k6voxT&Oha*
zTx=JQL!+9!9m^eTc{tkmDZ|QLY@LQVy%MoX5aNqC&z?DV6ydt3YcCK7CcKJL&Ay-V
zl$fs!Wk^Su5X!np)$`G1A<6T^tfRt!R5ZoqF*08c5tV}~2I9bjdO~yvCF|~6Eg`+h
zm)ba*J@wp~3FVrVcxuTLx7`A&5eN}i%KiVG!cj^b|A5!AHCwGM`mDCb@rNn9B}Sae
zb-1XxmhwLy$_#LfJ_`A_)r-R`k0w|emO?a35R$?<&sM&5_z%&9H7a*5Ru9yP{Tj?{
zbkZCMdkiVsMSBbTfMCC*JwgCysEz|0o2!ef)0RxoZKZgK7qRrNO1XKlx}gbsU?`?{
zTvuri6@o#vo+En=@uH}wYiO5b24(2c!@=SrWcYBq_k@2us-a`j$=z)r%2``ycJYHp
zV4&?(Ca=egjemK&N#QClN`L^D(&)`lKT;Z9-Q(~$1FBm6_Q4RCB|YsrR{m=}eLq2V
z8;X4k(9`pWKA{DCiLsL-}l2SvN}Pm
zlaR<6y4bE_$(}R#8Tc<7kuuRJ@P3F7pZGGM;e*|RQA=HG3%n^Y+2<)cNK>$-=UYzS
z^DM_jfKywZx!~Xk$;)+UfEJ%?<;HWfdKAZ?N_+LN>nu7RR?u6gz+eq^1hl{@^kW-g
z_CTI@RHxJp@3F1$;vkAWC||v@s`!S}(zCIS**Y|p{!4G%tKO}~aHD+wgq#6|1)pWB
zm)8D6qIvf|v_bQ38+C-86bCx;DXqDB`M1A6lic)^m00#Tn@Uoiv4k>%sbSa4*yy!R
zofGqk&+W--$laaaZssF0oT#aBSA9#9zjamGWXV}nPs$31ctCzq+Zdf76
zuz!6DdZ-w0n^<*mW}A!dYU`L1CzJ&g>}ES2vSh!n2t4I~T;Z%I&KAF)+Ptfi<(>K6
zXwu~DwgR18QFA@@v7vc&?kkiCZ47!Gy4hBm<0tVqmVORT>3GZ!YU00`&kpKJO&!S{
z?Z)BQBYMBhobJlTKXUQ3QPX85go3fUtgkXBNP()t~!Jw8ErCb~qB;{4w<{
zi#Ek&l|ZEuP%=Tmy~M$zT>Bx!rx0bklBVf?(U%;;2Rh)aNyU(RUR{0Jr2u*CDL4jS
z&IWG3?l26quhBAy%DBgviyTAVGx_gA#<53P&SBG4Uzbwd>H#M#P_FV7#et6yS*n`VG
zmPzk=aP-3P>(qDP9UTXAC^Ma2cZ*-)KcGkdo&Oe6Sw~Y-lgSun$nB-6sGlDif}M+tE7_5MS@kYnd`0@)h57B+aT4gI?+XXs3{#&Ly(AVF`HS-)+)J6M5sg>)3RZx`|rSvc`*(e3Rnbw(#6X
z(;GwpVWh0{;Yt!(G3>d6!*>iGPJ*?pwbkcqbbZU#v;)R~-Imx*Xi-`41Hl5Yu}*
zQ1-YX3F2j$&eHvHcf&wcI#$Fct|z>evB>FExU?U6A3U9VGUPv9+u
zcR0ba1{RXknwgqBqg0I$0C$O%uesWI$-w#3u&QiI20O
zYFfd|O1HcL6E;=0(>84la$L9}2Q@c%J}Ha`yaK5V%TXH|osg$YK$|Si*A8rggybSm
zTQ}jIHS>K5>Q_OI_MVSBO;tLR+!~}`$H_tWgU`<|3$#{%(9s}E&*#NalEbDjs^0dw
zl@8Cx$w`H^_aA4N)7f29YglcKJG7H6H&ieOikdsqu*1*JhV$3NNLv%alfwe@cIi6f
z+Bv<9QGO73!nyLKA(j4RZmwzfw08`y0ME4u3x(9ap1m+&KEi=C1*KvHuAXXR=(xyg
zhjqp0ofe^2!)oLRNN{l7-l9YdfP!~g*`J2{H})l$89!b0!Ql6=^Aya&c>4PsixT9i
z1Z?%%Wj$o@_lA#&KmA!*Lyu3i>74d8ySaj^LQpD|Tgesfy4zlnEcrOM+U9dOG%nUY
z*$D#eA(KI+=kp)DS(RA49T~PdQ`pkt|KZ|}bBUfHm~AU2{;Y%b
z*SgJUDAH~;f`sljcR{`bmdSW&irJ^Hx}atQ2VNb;Xxj$bt0
ztDDLBOH;JoOBJ?{UsqE0YlH~R%O)1vs|j%1`Byt`F}s2U-kAXzOK2)OnwvUxdY~&^
z_cOa?a+a~V4>$QQ6-ftGO6fMYJ`bKH5$mi9gzqGkRJ|XIDNL9~PrNCD?kfU~lbFmi
z0659_cUv2NyS}d*4JSN@Y)lba^Am6x{JARVKh3rr6M^>J6kjD##{_H%_-=rTb+i{E
zu6cf_w<2pzdZF#E=XT2fvk}m21=0-3!{ri9FS;G0^%4eA2!tn6Cs6d9a48EI$&*te
zjqq8sGxWkZ51tak(aFwg+%rK^kWUdIpHY1p#i#VdM+$}J(sJ<8=)
z&o@&mOqdxi0^n^!iq&OCZRagt@+5?0ZUvlgIGsMt5|V>x-MwLw@F`-@+tcgHS_r
zZZ2*hBy)Vs^O$YOZ5Wfvb*;}|^W67r^C?EHcqy)KPl7jY(`%NUW@VOGm}EiW#Yag%m=SC0?^;YG#-x-AzH
zQhmvN*y)EHC$SS0z3dMX#i#z$z@i5-BLE8gHr4ve+$F3~)7`46b6uB`Q2?4@-($K5
zCr#4dH76*SKCh}FyhPN?weiFzI{Dkf7KN3L)>VIj+C6>3syrIr{
z393JkP~f^Nl1%rxN!}Bh#$2s9G9Af!}
z1PQ;W^XjtW>(q3*s$VY@pCr_|2`zVc`s(D>RI|CRw%ZU+?f>Q%_d5fhwUu=U+6F*6
zn~WzHO4i60mab>IlihBkK5H><5i5~g=lODH%elsg$Nf<8s5pJuTdC4vXXx*NWl()%
zjX{)`2*nE3>3G^`ItH__tsIN3?&2BxT=%Q3{Sq5LJqqzYN>OfFG|@LKY-=OaaI%h1
z%;z1uF-8g~ZEk956i+C=k5F2V<sg&qdFj`?mk_V*=O|4f2Z6`x
zTcdRxI>>rLAFD$9y_eV}jTQ}_CPo3?x|)wL>=qoi2#qYxlr@&{c#;FwxNwNEwM#
z6a(XBaPo&YfbL`ZPgdW1TdUI-A*BC`H%`J~le8Grk<)&zr%nx8CQQ1A&3R@BKxRnl
ziPju*)2vN=KIw^g=j(4+2iCv61)l9~`EfvK42H2Qb9*^wT$7^xY;FrmDm(;GBCTWY
z?Ctq{(F7(%xfnr_k98x(@DaPeXykw2l1hEEtLdP@p$soZ0_^@h%t1~s@ZXB!cG9;u
z9;KM}h%A)t3!Y@}H>?R2JCxtz5yj_yctjG?;{r2@Gcz_T3d?f0J|D`+tH8SGhjZAa
z@y7ULsf(lA;6$DNwP3HHdEsmtpppM>I1AW1$T4W5iziOKznay!vw3EsY;b*V^7(T*
zO(Yi*-+Mo5IDDH%#V=BCn8)%B?KQ8|Z=R&DG=#X~vlJ{mEM6R3=onLo1^5Mt93gAf
zRIaqP7#Jt(A_eyR&Am&Rw8z5`ZvUND^UJkzwyo=a)a=v>wC)Lo=ZIOWrO^Z|Q{?6O
z@ql(5vnf6?_az)1FRv_|B3p87x$n^hX#c8AfDvjLmcUD);HvOfD);m8N^w$4^W;d;
z@!Xb~gI*`UM_0{)6Nl6Jb@+)Ha$Q_GgEd9-_{6#i#q*OTe_oP)_}hq(nEQbe|H*mb>5ZdvtSUyg`_UK`1U5^zFlYBIdJi$o0hpHT7N%C<)>x8sB~3E15z
zmUnz`qSMq<(fW1jK0+CR!!FBn_Ia=of~(azx$7)
zps_mMpHg$DWTcqsiB67}i`vr^Nu`%91W1E@#dcVuwN4D#pYr*e|HM2DjugaCb>b!8
z!y1ASaY+Nk1P?|KKG+t9%IIJ#d$GXmN?ko>Z{
zk7ZL_1I>`-Sc05<)l@T$zeQNJ_`S-^5-96S4|($VBR226@xo4JadsOLXEq@qo&&-5k=gO)%-FgL66-@21A*%~P5uEr`_AkOGahY015#L9eYARj%
zW_3B(#Qiug!|n}HEog|6mK9EWKPC)_Y#P8WgdM9aJe@mU?##%gVe{EJN3z9m#i}Pm
znCUE$c0nSmOAGnZ?(0$Cwgsn#gafAEt6`2$8(5EedHFWq5*n}Y9S2pVeroGPcJ)J6
z8#M~Kp1lcZ3Zs`Z6`3b_pu+k?S(ZoO8S7OEPH*O@YUEv7x_8($!va>d)5eMG8S87-
zftJNlK242el#-8QVuos68#NczjZ@qtDDrjba0u)89;syjc9Pl#!ldWpZ3eL!EbvEZ
zLe6^x-zpyI$uQQhi?xK%zQv)L!)&_K$-AwyjaAMf$juB1$?)N?YSJrXJ`dZPhO%T}
z9jz*k3)a-o>`$3tFJ(=kYbkm+FSLkg^U4f>gW&>XyPdu7Zp+QJfG_PL^B<7ramMfF
zMvJI&N!2@e=6iSne^Aihi@6XxtN7!e_X05`5ezUg8fBE37**vZ?)N{b`Q!XX02&ez
zj}0w3GWW9{{&?BbV{a7Uh@98}p|Ns0RmS{`4~-J+Y|m_$F`gSN)%=fnKZPnj548}5
zEzJUApO!Lit%60Z&>b=C*&vNzSBGL5!5L6dcz`w27_`8J@U_gAj3YsUNnIrGCfWrE
zY%v-v4UPg}ne~)cInRIW$T440Q~j!{Ci`L`&${WOU^NeU1C*nf=k;2E0$R15+;Hgh
zEf#=YUiy1Bh7io7{2NDFMfl%9mwm|$hd1K5ULR|mZ8i=@*s|zPEinid-}7$AlAB_L
zG9bg@r=Z49F?PMxwwRdKY&-djFc|%UC<3C-gh>EB5EeI2#5)vOxZfzGxXB0^e!+Qo
zmHVpYohD6!6yh&WDQXld&~(@)M%rpi^B^4~M!`o%rR(J5Ub%eGbzkw+0%L#ZSB>)P
z7oY9L#Ot-AM_jgi`$oR3C=lrMW%n28*6)HA${_TMW)2|nMJtq%OR0h%RKF5x(0-}g
zb>{@a8xce*nbXzD(jGudy2bqPA+UP*(-8w0vaJlMubX^0@&l1ZaH&~<#PV8P)+?M&
z&!6RPDRSO-$|$S%N##d=SAXb@4;x9vOmYET6lDLv0s!Ffz(Bbzkq
zX+EcyuxB~UaS^(fvX2VQPtZUX@P+y6QPSodz0r3dk|gWJ@`yGXk4mIFKx}Tb-DRnD
zte9~#hedJJsZM|FU|MvaTwEkd3F2Kb`(yWbz=e8#i7Q05)qKXFiuL37xnpnNwlZ<%
zxy!`usNleFZguj0Kd}mAC#9xeE7qe+4xJn})t2v5m&1{Je={~c4
zZ{R2cs%tSB)e;k0R?Pg|xe_=a!yG{7YgU(^IRiq=WZ0Z2N#efivNyLT?*~uLK%D0$WSZZY8Qp6
z@3X5AxzG4mm<;tz4aG-JDL;4amozyR#BX;~AvntPtw<=GesIw#_i`*c&A@tdad-e2
zVX!gK!^_RfXO@T#5PZA`oV9=12VZxuxPx#aS+Df>#_RO$l*8xm`D`rWJa_yhJqMTr&LZCtXBIFU*5)j;?#hVL<^y-|z
zLDX;JQ7b(47UmLRZVoL+237h@R^E;n%r5IH~iX~t!pzTmyhyMHc0>eY<~i6i?=Iyo&TP9DEKi!z6^Mp-6=7jhRZ
zAnkQdnOUk_K;^po^}i%x@DMx^;;wJ&cNUaVUOn~7aahoTRG>)0CT#*DAVU>mJo{L_fk^V^z#J^5E8&%fr;yU;IL+I`dRYp$cC!Dg!`IiJ!;&r}|!
zQUyY;!H-;3BmWeqbjqgo?Opwb+KyI?3Y&oZaXXOf%9bXDd$Oi
z$3V|=<*(zvwRSNbiw;Xu*itjx()eZ#MoGyjK16R!_pF;qyNl#S!2YfoRWx=3yLry-
zK{iAfdx)QiI62ukn&O+6DaemY<@~S>Fe(8>AQRZw_|A
ziNx1q%L=|H3~NBowm*b=dikQdAZ2;_V)IzNqi8pi0w7jYg2LCP1eq9hG!3gQ62o5}
zX~`B33pF3cWIb;e^mGA~F`6ch)karfdQLT2yZH{q*Lm<8(gaY
z3xN|(lNjF>ARxfGeSq+3d8qsT(L949pREQ`e!hD`|2_8ww*E<6f^(8>00BE9kKeEz
zpe+{P|BUU3iWmyO7=B9;&YccgsTBYcVR7^+3#=o1Gs&OJ-?dun<6k1@@n3iE8Uyn<
zl+mnG4Ucb!x3B4@9}n(US5o|s&;gWyua=9E4iy@X&$|n3;ufTwW}>D;RIg5cvM7`n
zPh(=J$tUN3;%&N4C6Sm0R}{F(uMmR*K{Ou&JjX9L8Tv6dMHsnT_c~McRK2hJ$6xMe
zvh=y?q)R{+N`sCEz&qfke0lY_48dVOQpX=uza=+Q8Tc(dQlXHU`;rZ~|%TCn6rNzuls^XS^u;E{&GW0^_jm^C*Rc#K+dN>1+TqpJ`QHfs;;?h@X$_)eB{%;1&NEyc^mT-(aNvbGaKC}+f!9WiO&Toy~6m~eLP(b%3%8s%l!3@4ev
zik)uL2tsLW-XtnDab2TMMW%Q{zuLvbVc#`4@#eMV{Bta4KhAGokJFou=(iMOOW1cv
z((NQfk#}@xH+Oy@IhxCn;}_;5)GkeA;T;u#vYUkB=zX+sm%o4xAq@hs_Fn&&IBYi?
zG2u(JQ!PkfvD(ICn5Bsb>)}YB60$C$uui8TTT4J@JJYa{Kg9K4fcM(A{zy9n2vw(K
z0j)#X+7S
z2nz#=-tI;^{{XMYiXW2Y_eHr<0uW3qQpxyImPm@8jZNH@W0=66Ml
zxpeAW(iZ&X~eosWpSV5V=uHJO1A8
zH0&?u`ez#sgNMMrE(taogxArNhb-}M))g#EZ?O?~Q}hVr&U>$Ry1J4daiIb&$)|8s
zQ#po%^Xr1z9~NJRC?IwO^f5NIW_=vWQ^>ZU6qo~R&~
zVXqk(GfOvHaNU%N!5B>)os8PN%d5FSt0Z}J$$Kq|4H_JV7fU24!J6YXEK0-auFHB&
zdYoiAQC!F!g#1Gb+l)u`x2)x4m`aSKiNK1eRFMLvwAhqaMKd!M
zZHRAzGkDb9oI2g01T1<4mNyNx=ZqRt9}YW!N_nq4TV9bVLcKtOneI0hFf4+B%6nBd
z5H1wY{YVYTR?f^kJ5=irGAx!r>8&J(8}}V}9<(fa;w@VoVTM5XH8nwNT9mZa73T^9
zWR0c%%9>mk_mjsX`kmE!Q|+zfI2>&l7Q#8w=cmrHy`FZxj7uFiPlq
zhfBlkJ?1#gg?K=suZu=H2EAqywb=gXa?JG+X<+U0J?i_yn9
z10re4yz8itN&)|WuiZ)Q`+KbR%~(;teU~o{E1H8R$tQUhHVO30RYC_Ji8(5UC
z9b~i28&X9N6FVZ|>GZM22FeCHq*2oDz6%Qp3LIgSiama2{Gf=29i_bU@srcLGin4b
zDYLAss2JsLy^B5s^OvnV6A%*lXjL=c(#pLTIVmgrFdKcmVz)jhp#5=O@-(QFg>I8`
z11Ed$iJ6Y-d`xv<$H5%3P<@xC60BZ;_pcJ@Z*A>au^$=`0>PQ2B_<0xFA!FS-ItcU
z+0$w2X(nU%CpWa(l`ss%@n|3-QZ%P3r9o81Cp!#4erNx*5fhVMvb=PRONNltcX;Vo
zn?)pgQhawkLYNe_gGE?T@YLfi
z6vAOOH@khw+AFPf!SiZg`;FBU&6I21#7M6xf?m!EqI>@AqQG?%rY0+L-i#E!CE!42
zrn^4w$Ii{_aZLLQ{iqX$oLvVxEyLbGjZp6uZk3)1fT-((=gIU-RU&d;DlYO=gIpK+
zF>Vlf+uNeK&{7y?CW87*nSgn+`uJ3lglUm5vq>8EZSzP(ZTt}Z8?`(FKCLdR0MyR)
zBu=&2!=Emn2O{>Kh8(y6A%PDKy##Lxb3X6S
z8KagT6qw(o5c)K4ozAkm9`838GZ0Z>HGD}L<99m#CS%62cuD$u{?!CZ5<@^qLQi|f
zh}2NG&1i0>#TkRyyixfP+Sx`Yv6RX8y+-^oMCmBzQr}YJkXI+x$jFm|`qo<9ub+<}
zI^=R+_TY;Wz!lADd~@lhC|64Eev4CK;km{By=$C}+dQ&fj!9Zp@Q|&(u---Z=&gz)MhaEvX6ez!serJPm*lNsDcVikBI!$7p{
ztMXfZ-%Q6hL@1(Mu#{vj?v2Xz_(DUSKawbYkdoi;T@Uc~ru%hB-$8Imz%B$c5(t9o
zZ9ZM@1|AMlxR+|NYRBv2_sg!98#?0Ps@P9kWF7#A#ZYBpzQF@dukOynO+g`~bK-Z<
zDhII5P~?a`-h;)tAqr(|&*0$62JvLV{rb9BwKk%W7Cns*`&
z9j8*F1$69+p%Vcit}S=*p`LU3CIO(c7n=F$zHDoP
z5p$r^Vs(hp_d>gl3QtGq8*O_FdYoa(+p5NYy>IHj;LK2IyL5R9+Oi@aC_F`eiRTkT
z5&s014E>&wm#2c(Ja15asH&Qe1VF>$s=rrs-2Ml-i2oAOGIx1(4(r&sd*2!HU!=vf
zrrT*-q}=}ng6|~AnfWIZa}Is|o--br1VB-T-|`-J8p}NWT81&_0T}}J9OcSjq~{Dh
z$o8-&>|@YMtgDtu0{XQjCa5<;)HNt4{u0U0LA|nBZhp?-n`LE$Z3lkohD9
z#Y#?js|+kFWmo|K8GnKnvq?cugA8TAy{?~0PEB9d<@l-H2ZE=4&BaK+cJu>FoB#bJ
zPuQ6hiJ>df>F0~-HX7R=mWp`jK*R?4S&&{fnaT_78riFsZ|d11p-CO#u^h`n^qNFs;;}MD>&+1S*Qf!!!y^8*VdSTmY25TkAn+WyONwB1LSoLFQ46b)BHWg^EN8O
z*5BuGdG2UR$8ln7!DoHN94F)nmH<&*fY-I;=I{J*pJE`ouoB$
zC#5%HRN+_dnfR7Wkd2FB<@zRUIN$nO*tORYVbz`d*E55-L#6?vuBQ~~q^1jOllB&u~vW44t*dH&J229zHZxvKlU
zy8-2sKXk~5eS|M*{k2gTQEM9Wi;?PBj&0JUr|t{HMUr$`0r2860^GTZD@4b=u#{C+
z&99)wG)(6ZKCv8+4_PjY^xH3Xe4e(Q2%MMKqc#m4snIl77QdJfrPzCI)z{n(2;fr@
zAQEEYitl?kopFmye1$G|P~ozwcxMd~4Mxu~O~kq?K+8C2fcX(!^cLm5nAWoA%v;`(
zk7}D{6J$_G0HmW{UqCoRrf?c%=6$z*GAB9ets^6j&aDW0xo_r#YkqsODr
z(MyXTU(c4{q!O_O<`ovKT70-rl*22RDKq-TEV^E0!FW3_&-NJf_SabKF67
zn@auqcoF8kCIp&tYzeIsOCNZ8Qmle_FZe2s`)3Rt?d^-V`|(kYN^W8nfb6{cqBx
zKt=a7X$_pjffS;SXFpia!N1v$uXk2%2l2M(=-p@2l$dNKH8rAtzQf!pG7JsnSS;H)`24@jP@PlQ;_TkZiwviH?*y_7XbC_bR0dgf%As>K#~)6(L47e9by6N><^H
zlllGE8eKeu2>~hUQrr~RZMHDG%OQv_k5BM{M~-1N9xJnDEWxQfwv<-!)qM~din%fq
z-JPMq3}|XtbUzT55}3a{R=IQWCcesS5=koQB}OWYE=&3#To!zTbczEhQI1f@iE)-B
zy|`z@=)=&A`$Ua^8+xQz46M{*8@qgI8EkB_gBEl~!
zI=SFB0)UIdRIN1HjuvnK_k+~Czky1`Sq$PQA~G-9SXB&mB+*s1^nS9Ycx!tF#(q4z
z|AEU`B3;B9`PR<5$>ZYwKeSTTRY>f?6oo&x2%2VjG$&ISsa1QZA!
z)g971LYm#JVU{X~ko|w)L|F)P_4E2W*xNqGdyw}YzIv6^gP2PBlN3t-UU}h1sTg%d
zeBYw>F{lZ2*1(XzI!N8#Ne(-sPnL(Je+9PEk$2kn*6IdMtf&wyp&4w^k{{<^0#_c1
zukK^mG!QI@VRfeh70;A59Q3wEEnW|cwZ8x_65}XB@yziORKG^uTLfOOh(Fq@iX-tX
zRobE!UBv1m&K?aZwrLo$NMxW$diWHksq`1`du_2-=3vc`37a}M4=XL{&grBPH~R<{
zw0epVdEbofxLoxD6~?y>3{RgIkiA~#kdw$&@?yA?88+I*Gv_?FZ?-93Sb5C9*B=2t
z74KiQBnSbi3$L7$(K)DMicX*t>31K3V>5c-^OWmRp?R
z8?DhY^QDo@TqFsZBraI`Jl|5?ESql!l
zRoj_yn?Fs8f{o4ps!-bYXwmsgB71nSGXykFa(SMv8ByvOELl5M%@8NSL^_eZ|92y7
zU3M%NhL=`hEhk6)M~{kgM7g?imVNhP*iiRZ_I;H9a~$vIL#KboUUDZvb?Tbb1m#|w
z&D2H7_}ySSg7uOSJWKWP=nKl#6I*gisd>vfyI-tC=vVWGffh-9wBw>#m{AfV7F
zGd(w>ACugdf-~-mH};{rz9bblLyJ|F3mLNTScUSv9_@jzb~qgxsTx=eq~<025q%nX
z+`i<6s|l;j8j^a1N^GV-wJHSJPL6YOz14(hl4v46`TL~}>be-UYH@foKQG8rMbtxf
zbhe{go4L_x8R;bZi(zjQYTfArAhgz*z+j2uMb9wP6s<)HAd+*P)MndZIa{f7Y0a~L
zN}iMJ)ApG|gK!+DqBWTVZ&iQchggpCt{!#0UMzT1ggB3k)XF*de(}-p|B&|9L2Z6t
z)Ni1;hCnGE+>5(IkwS4O?ykk%-QC>^lv1p?7xz$#ySuvvZocpDow;-WzRxhsFmoo8
zkUS@6@3q!v>(*z6m!q%^1hS{cwstE15>uhA4`e76yU58fQMLJCJIn3k@9XXD>p2Gw
zS7iWYwdIMnccs;+AD6z?5u3`7n25i?ZoK3Qe8$^GjVeELzj|}-y2rB!p#ax^gjn9D
z1%B-pnkcw(DE|JAOj#)1E)5=uQyMi6uMd8vErbAqR%!I8&BZgwB_IB%7y<52YXpi!
zCp?V1uD0n1E8Ett+Y%3-?uVljW&j}c#;&ebzs@=_XE>}rd1q?lvS;zf2j+hZIPjt5
z076Bi?GWf?-0XYY<+gZs)##z50_x2d+gTCA%Jn0m{}BuxskVG*MwQvP*Z_)&s$pg-d;&rXV`^H9zdmx`u*p)=Lf1CMx8euM-UWIt2@7(#
zPA`1hyKeL~2&N<&k5@`?KPOX!qKG|hKHN;LJ};G)?&=iPW#dS|PI_hU&IxbdWv$WpQWy&G8Nd#$=mXn
z=9b5*R0rU5AKqm#&1UCvDtJR*g}m!o(UHsq26Q@C^?s&v_!6Ph#2p|0nAx@9_nbzPR*y@228B~gZZqc{7xLL7ys!)^)s{8v&N#-TT|^Cw==J@{
ziHD`@@gJ)N-ByDS)pN$MboGEl?3X@f)a>}ox%p?OZbN56BCG?X?%pzCP$pYF3S1YQ
z)|AaZj{2hbaz8zN=lE+K&a3qQ*$dhxe>+f;#ueB$pni`YA_)M@S)a7wmL#l*4fApd
z%mN(`Zy^wY&dqVd0}qaya#+G*wL08H)}Ff8QGhf?#L1M!uyc{7Ea~Iy^4M&&HHApt
zh+I{(4AHg#PX1ADIT$cQcs(~zmkxNvi`wg#OJIu>rs(UiO5%f^=Jlidhs
zeWZe#HeYkZcWiD#kq5>m(p3HIC(ugBrC%=|Hc+HZc|mA+fGK7s&7V!2a*Sel#uxEq
zq+mCtf}Oabem0I$9iLX6+K;K8dd*jj(wucOC$1aqN^#a~+TZ2oT@~miA^yojn>RZ<
zEjCkws`gd8lEy$b{&O(cC*+WNLy2Wu7C4xk`6$QfuvAth)A>4bmbW^^ykle*2de@N
zsx7W}iz^005I8KXtuguQMbItI9-`>$KO=n8NjE+s^6DX`&z-dBTdS=ZDDUfW-9!9Y
zA0Sjnov$R&M{X>XiRB&fEE5)IQnsS!j%G}9$(HMiEo{F<%dVMeCEcWF&qGw2Y|2la
zOP9O#?}+1$E3Nj=X}tL4PE6yRYKa}8HgSD_3P-nUP!<5b$CV3vzps9JsC3%at^KcF
zT`xVFDSHm)i7}
z?RbjFg~~iPAQo--J}Q*?!|N!RjWDu3p3vIvz*zA`*V+RW?_iYUF<@)nY3M
zE!U40cN(zFTYbj2BO<;v>0_o0PW;zd(%0EJ6an?>y|of4xDwx@4VLLTRx~1rU{ClI
zAaaJ;$rd#L-V$Oo^;mk#TJG1xUzk^nYC-vo7flj2UW<~q)Z6TcO=kY@Z
zCq87ZcRs?LcXX?=^vYOceC`nut0g`CqLUw~2Ymk?lDt>UMy#lfYBhUx<-3iA^-3IU
z5Ua%)P*=*=7VS8YXabR6U3s!nD_d=(#sty9qI+1oLb+Izl3;E8x_A5-4gR(0}H
zN4iyrwMcz~T%tsFB*^10_yL!9OO>&QZne*JY{g-fGCiw~a(7|~T9obO-%E||iv%E=
zsv6Fd=f;`rlk5Eep6N(Unv^MMt8{hd^#WqTw7R){wjXJQI;sl&GF*LteOm0zE1
z%6?gneTFl-f4DGun-Uk@NWNloqzj2>N7tsLNm#wy3>lipZA!LJy((Ly64{sKBTf*C
zOZ|P@*!a>Lp>(+*(|2jMcFUKrS6^4uFSJ4a9i^;q4dy35Wt^4Sw*Hfryw897dN|}Q
z_un-NCOmiswY{>wU9rA7z&JBas-fOw9XJ^JnJ#}xwJIb=03^bk+
zlq@nYYe|`U2%Lt+zvIN2z(Rrp0JvQR4Q-o#hQ*o&qU}Q=hekqvEJr9vb~}u>a*e92
zf<*s0+!tGXyajGkl&y{4XV}EU)$txAyn|2!skUb{j@^TMM=qz>kbwP#8eMC4>M@JC
zQtTIwB3ZFW(AU3laq^`Gw!GP;7)g3)41q-1COu{X2P7m3(49CZ4SJ*U);iUiy%_wo
zSkyl#rYX_ZZ{O!hb6J8r;b+J7T07Ni%v{XyM1RJ894&DIJKbJfaQI?`j>d+eMA
zqTm3;@p&H`n6exNG8HWAd8IZx**;Is%B9)VYq(;>N+u&*9~MrNwqFN!K1v4v(Es`2
zOBhGiEkt^of16s((0<|XtMJ19
z{mZVXb1E_9od;R$*Dn1@+&!<9o`r1*I3AMDmJXer6_01X`Cr`3c$G#=q~80)-$J>|
zHCTxFLol&?3@8mO2kiII!}L1Myh0#$WS&YtgDOgwcP;v)FMa30-WDa<^PKcYxwr7N
z1~~nH=y%3$<7TBb-eE+4k#g&OIka04;EKXTIVCKeoN7PGNoyvJ_k?0=TIu4FQ;VDgl9O~x0((UmnbvUnjqw&F)Sp4=yS
z6DmWduRp82d;Xz(jSahY+W#(iXVHWEg^((PfoFcMQv01L1p;|6d;d2Met$=yJmD$f
zpe2o_zjj}1mtD%IdtO>2F=1xpD)p+S9CP$~PoB*9AzZ!s2T7#uZCO37w<*EqruFrP
zJCV1B^H1{35&iYA)-|F>il%@D3d&U4??ozoUrhr2l82~DORIZ
zS;xQeEvr2&@4k&JQ^cmRQkx2c-zjHPjz^Hz>NE|Fv22J%NPUSDO4Rq6@l>KyZ<>N;
z6pOXm^=r`h=Wy>KPFA!(?lxnm-W8eL7}VO7c)gJz(yhhX<>NagB!jX#jmr6K8ktY3
zEJB?>s*9+z6Oi*#>Wjc^#fy(R?fOjo@wAd`hY2f@RDV(xCif^bG`y^B8@CQ<;UJm4
zL^PmGUIAf|)5$WNbPMaM3h@J_Czn0-7_aY@KU}z)kH3!nq0Ysk6Ys|_iPb8VrYNW&
zGQM|ZyDokhxK#S3TBK*+#ORfxx*^L}aHHs5Qr?*mXUCvv&BA*{s4(Iva+>EReXacm
z!6?~&294`WNlIUq2K{2ZMUfpIuto$*r;YI!pBAW=pL+;w3P97{`lj)U>FkN|+XfjqratCYj
zsndXNMDvS#_=Rlq_r1wXB*{s<~M{zGwSfnyUVJ`VZJmX7y~u2(lCQK|qpw
zY-Ik(YiH=}m#FLF^%gg!H*G=9$3`aYA+bcylrvceF0fA&!XIxD!*R_@cSmZ^r?ZwuNdyRBHGZ
z1o@sB@gV@Hmmsrc0hd%wVH$J#FA97QpJg36UQ05wo}B;;A43#gVH;|q98BkwN_{e*
z&tBG6blg^r+c9kTCxtJXKobN6PRuYM^`wM;Tq`%0a2q2BA)rrU>a$U*^J07|NhJr+
z@SDnl=uk5s9zeN7np)5DY-u+uUD+!t8HJfEPL
z3f6ngZd2sOAom=9==~{n6^dF4oMO%y)pEoyn9l|lX9?g4ZN_#s3JC)ukJ`Qwv`MoE
zCaXH8_p@)mNXUxg%(*H|yY_GM8S62Shuf=C2MrlhCRtdeS^<%hJkP2)d$p!HY4?(h
znD-(N%B-!zr8oFhq^ZS8V9VfuQy2>KA47`wSrVBoWbvq@tpsRLqWCPfygC7D6AhS=
zpCD53GhFn^618+w@@zfX=GLlCICQxONYWsLn1W+VNeq3e@GSQ0vE})>3|++M_j6#-
zSfNj?i|5MXxsOm3UqCexifJ)1l6Z1GA5Q;Y23qnhKK!e%=Q`}A*~YqqTbQk?fo$|W
zUcJ4*ugx{p->Sbg#bhTMa+>#MVzx&-Cyg_{%Ny@PklXOndvp=32v
zdiTUaX`UI5CA61I_fqP%-+>pLYKCfx`UxpXUKXESd*$J>Dn}P=cjWQ*TH`Uf7XnnH
z)&|jBdf8IRSCr+XSKx$h9QFnRKlg0YM;F8igyKwn3<)+9iZZ;=>&do&y(MNO?1Nb_
z<_|Ne=}0o490I)<3afXTYH%W+EXV~FO{M=6%XfeTewFOxcFsGAKp+xqRs1$RPJbA88Y6##o}olw>+JS=reT;Hfb81)3^Q;o%HyBLFF~71c@DDc%ArlGvv(
z_2=X05_m?mK{BY_TBK~VuKFbeTB&S3G{FNK%JS4s%u!|5spJF2nWD|16cRryGPC6*
zAP8zRT0&{`;dFHgaMUrue8%jWfj`QQ!;6mbM0F$6He^YLoR}-Baf9&^Oz(1q(P3@6
ziN828rWE3!zGAt2Y+|jJJF9TnAXEwvR(M4ZB{j4@+QjAn@3<_jQopUOOTB7W{^^Pq
zElA$+Ux1^-`GG4NW(mE?OISHpXLclM<5Ayc>a`J
zpIQG9c1|<-_DOaiC9<1?e$S;lIaCPM@M{}&aR2bEue+Eb8YZ$*%iGMn;%UEkYX15pA#@m3*B!xm~l)h{QHS
zd4)JjpZ7_)&iEL;2k+^v2CD-p-F=S4(X)QYq?FcZhF)
z`7hSHdmQE=0)Wd_3@#^F4m*ht~4$Kz0IAs{p
z6L!63%Kk?mJ;zR_d-Wuk99$=O(~`aHnEWS-L+Lyul&R3o{w^w60_9a{<5TLD&P?wt
zb+VqXp^%!IYL^H72$jPOCS8qeFE!%!i@jxye+3bsPVfjx?P`Ll4k&Tq%J6?1h}*RP
z-D6!cKf(}SJ@he^gE=qtTQt6Rq+2=rUi`rn@SM5cck;&jBKt@ufqGYlu^EtQ^PS1*
zfB®8xxdAJ;^4$%pp@V>())Sd_ALg@L{eesU+tDG
zo}^v{-K~V=JZ9f-uCvMQP)^kU%s&mkf)%Jdh{Bzy^PyNk&f^0-$&*K%jH_dFoax_j
zu~EfYAJ`$?t#FZ9jm(_3Ka51ssnUnbzyAA?Hnx~8&JGAn4yI#{>LZVBO%)5&dCav3
zRcNv0Maa|t$+j^69j}O&pg*7Rh^R}3qtB}_#^EN10cI79Eqe@YnWzm#4l_b4kofCq`;lA%r!XY*@{+@#f
zM2V)yx~0k>AC)z6sCw0p4zd#<9BWX3w_%_8>$T57;RzbwqriQ^ypIN`O}jIzHM_#2
z1gRE&Pi1ypWs?I%RTwYF+vgA&_)_!j%i@JP^)5CO_ANNtg%D_Y`%8R`Q4Q_Q0)M${
zZ0gIl*U^|O6UszZA)#e84Ej+-nB^PJh(8!~K6rK5Nsw+%6kdcIoCu1gQ6WHJPubed
zrZf>~vNpqreDNZvd)Q5vkmPh@O5qmo7YBw?_z18k<}+wX;=FHXXIGF5r0e>C`e2$h
z9eR`%jF@CLCA2dcP`nslWGmp(8A%r--P2~hoL*tOavw}D*FU`&&Nj_Q5!iG4WK#G3OrSCz3qo<*unP-K!K9DLW56F@{8IQNL4HL|8N-cBP`CWoE85l}G7n8#hD|<1oLzy<=d36{H
zE^_ECD(|G
zvSi5O2hT}b%rogJjghJ-smZFfeDTHf(YQ`UgT5S%@~dnvZ5R@?fd_=dGWD=Zpo%yK
z)m*2nf|v-WXC@)}V1QT*mc}#AgdN#A+_%Xul0Q@iqLgLBo=&xOD)5&lNw_#cXcXU@
z-aH3C@=$OLxp#=MWHP7(Z<4O7V
zQ2*xHzFa_e1%7*evr61Nm>m=CnC01ioq|r1-ENmJORid1**SE%)C)hH8lIBgCg=kI
z^#IVLc|`1UZc8tEti{dIrDD=w9l)C&~{djcVg3YYXC`Of|EgY8mw|c}+Wp*aD0+k)
zyhDuck5y9J@Z0Y(FGo|;mS09DaeUkU%bW1Nv~>U-4_ANleV{uxSZ!&`oku|$;lBoT-!FE*
z1uvSSKciA6
z!E3LpuzoTutcWzCKJT#7@w>6BP92iNm*pnlgWdgflOh9k#P6KhZ)kZ9(dA`@y5b5y
z3>XHyZg^TIcJQ%tl{=Yl&n3LRFcOJ8-Hc5-tcyf_kbp0(YhXoxN6fjGb?g&=ZZqUAo(i6Fk
zXYB4pK{BrzvTvEmqou^6p7(i;BrDIyhHJu$hfgs@ArlfsevdMu&)2pe%WW=0X{LN<
z1ed&g@9#b&$fSJcjA7CRLmva&vk1;!hu$tTJRmFlV}iG10j~j1i@$lC!G5>RZ+F{R
z5f|JO#;G})Ykuc__v^ZD7;<=k!Oy6upJfRr;?MnGFZT`4Vnb#V{GX;^RHVk_o-hQ!
zf45JFNxiHYOqE6|DZf|Yg`63@mQ(TAxxk0zbnU!^#JG|9D==Ih7uf;GPu(VXb5
zG*Re&b2Z-b@9XQgT?cS}JkmeOu*Mv)9dE4T-9`OmLfN!3aFv01y~WAz`JZ>Cc0)z<
z%G&ElA8Ww%>^6kDRU&fuw!Hjav>R%)@940B4k&EWw=sO$
zC?VFJ*!^u@Y<2Mf>1)USCdx;Gn9KBwfA;DYhHL*l3qO&t16~hel>A|JgL3R1-|TKBuY;bBZ8M|d99~K1vZ4Rg?7ktH
zA{=#~wjGzqgXl|Cy&zaoM0jrP?J)ghg&%r!r`cJ9J`LNy-**0Y$!(5CdHrb=C~YVxOoZQh<#JXfEF&3KNpc|c4yC#H~f`Sn^
z$cPddoV+IT3}Pt6{B)W>@TgKYG#@c4J?9QZo=*0A7MId0zkF@a&0TBts10!ZONhj-
ziH7@=Sh1+Eu4L2yzUPvJ4Jp%Yif!Ey@+32jC?0s6(#s3N}978OFj-N|Xv`IQtd{y-Z>etpXn)?<#8(v?L$JqEt
zPR>P+Fcg)_QwU&3A;AoGAX-}jSSXh|o8$N5*4+fy9BshI(C=}hKh1$-kl#UF>SJGn
zvxX$QRhg-UD=zxgKk^==-#NM&n$>zX0`5tc@?Qd4-JHr6_4EVY@-!-x-aq+ph&{aMoEBmo%RV!~>4pO1E~_&JA_0e>;%0bdB|ENBZ@)t&E@KgLP}X|p6sm#kQ;m{~33vEv0IIxF^L
zq#h$-+HN8%IVcB@;wE_&AQ2e(&C(@Ig1^Bvy4y((w@STcUT3VzeNJ&H0YWR&7wCkz
zkMzNvp>pJLajIu=jg9BJ(ZuO=uYfNZx*9UQK-FfxAAPIGQo#K6I--y5-*wj0k$0o|
zROpcNq25=Frwn01z+={gLf*Vy5H
z^Ob%>9)N^64$i%MVnGJf>c+*{f_*(pgY@oO0*KgTQ6#5j|AealDc`Oix_3YpjyMQQ
zvnjbdLt5>I)=n45Yn`|&3f7Zv)@754yfUKD9nUt}g1?D5x<4GmAP>PHn8WBa@PB{l
z(Q4Y@^>npe&hlL#n_|q=x;%DNIHdq%t*XE3cU`5xsARTL*(581XzwY7GCi;9Ew13p
zNKpWU?vT0nS?7L_wW0~{8-G9AnC>2Nuaa+;V?UAo&dITzUw^b>qUuQL{05?|RMpmQ
zlW=49zu$1(k%je-SaxGVpUaR819BM>SB_7Go)|w{jOp^$sQ+a?1h1{~iwFxGx1e8R
z+u<+W-j0cSzNx~=ICUoZahIbo`0in|-M7()ez
z8E+F`ruV1%^N|N>~qSCxHv4G-|fSKdC2$-Qn`+Zk*dpV)@8~SW@CihOMWC-NU(du
zH1`Vx07TTO)^JWEA-jd)X+F-5LPDZyHhj0E*l0t^Vf(D692jN@qo+YAaY&U;3_tO1
z+)5=OP$*TaPGuC{{;LGQ1Hi|!OR0D)w7wl1t|*PG9{+3CtodfRx<-_H3&V^9V!tvw
zX=ue+ObMYkdeIuP>|lNuV~b)h^HoR~dNn2(5hD8oZ}z$=J8m`b
z3!tM#Q|^*?CEDa$z=i@6U3vaqAfxJAPoC2GnY-nF%?)ZViVAb^X3rvIHK1knT`+(`
z8KiX}BmWOWnw&4A(AvFjmc?yl!5oE+0znNva!5Sje#-3aB8leLdyAu=!GF&_G@rXc
z_QaVbPliq=iemwL@$qK~Pt#}W4Ndh2W*+Bv<=}HA{y=znOvxW*p!HMCGykhgStAL5
zbL-=!XWphcJlyHCgQ=PQOsni_+lNy9?&RblC(0IeK(tHGR_I|}qDrrJs&X#MV{kWm
zsYYFczgv~X`&%;*xpHKOP1M?MMxt
z_2sUHr`I&wDjDRyObxdQ&UnW$gu7elk5ojlE
zz2xdbX`En|9Z3)!Grp>$XN(#V8%?(UkJ&GX|Ju_p9t
ztH0e$EHmcNn`ZhhUs3BYejRhfw*o-`DigfXUA@7-I5JtPA_YulvH4(TF0Ii2G6xdu
zgEf4fRDe+S!Azh;mzRl3F+WVkVvjWW_lpPpvF{iARSQ51FNpiSJj`BkfBtetKHT`t
zAmIEcqWRmmvlX(5p)LgYSSn27MH`rGDqWN{IZLdaL_Ydh$#h4#QUDu@VQDFYr+m3I
z$nCZZ5?O6^xnEnW9xDC3MUO8%MM1P%J%8$ZxxAh`o}9>pfFf4Q7mbSq7_QJ<9@Ert
zNtx_g@o|0e1UgRqc1=t=W(V2{2w`?^!qF5qi?sOa>+ADiod@{u_lz*8CI6?RNYLN!
zT=d9VZfGQ5NfXjOW5aSs=U9)u;!ZX^cs;
z#?W@VXS-7d``&$$mPD68cKjXh)(6$kI7Y!R_Qm9x-`#RvetE1(r4#pkxn|C3V_~NY
zo25o+XPcW>-EK2k>IDtF)(zbROk9C?Qv>xApssKrZJNK1=A#VtH&t7LFnYp
zQn|{R4;>tEyPV)*A(2;E(m&3tF~_3crB0V86VaYOn`Cra6I!~n`sqd2Q@Q?*Tnl?sYHAw*B(L2~#RSPDyP1Itv;)-=e#GbFIWK+ix&
zf7M{L=yiK-^Uykg<93@mYKtvCe@0%8a42?w-IDzS%vfqdk$)|x_+LSv{C^92=FgB4
zwi|X+p;)TP5C6~&2pxCtk#L1|*IFJSFdW$Yk$DW|K*`~u(OaeA%T-KY(0SLZ84FFn
z3S}wvFdK8p;~8>*_ic!~^F6Gf@nvw82aK`B(`*B@LRRDq32Mwqh=hCX&^vc@NLv
zLYfa7#4&Xie+a0eD~Y}_8W^(d$E1OBu{N@fLqSd;@9Pn2^=X7fEsr_T(H#EiI$veE
ziVCn+kC0)Fc{FOj1xv=17D2y1`I;TgJ3#+vIxN0b7~Ms(`gT(DdY6x0Yt>s{o>7Rd
zD@7kDRT!&z7M*64bljRU;``*xsSF5Q$eBbb#gMB?+tOwu5DuVC2o4nAK{Cc0
zMDe;lwByNoHGo4%g{MhVHw5R(p^?eF!cYQ(_4S*F+adk0G1%EvIn8t5z-ycRzoSca
zxNCyEtM$K|IdPqP$mA0{17LCz(hOY?&=~JI9~mfj>8m~L9$n=T;9Jktc}|A3ZP5t*
z_g6~b@6z4G*cd;)Xv?bh$HmFK(H231b?^%mY8jB_5^*p%cNe~?yo`W?|1oD$LsRr&
zlcxRNsDU^Bc>dzc{TJqwU;15LYs14MtE@6(=hRyRrroMe1mXTbT8e#tf^afL&@0co
zQF5D{(%DKd^x{azw8BUw`YYQ3sZa|vXMII5Kdz4#txD*|7pqWLyYHtVY=TUif#u^F
z-P>gM*`m5hq@R)_765NruR@0>b>Hp9bZm~}(FU?~itNA%Ky0d2u~+{{65kd9(l}P+
zF>JIN3aIvY59_dbroeE5IsVpW9F1d4yUE*pBIEDjCvUefC>|xI>M#sOzY(3n!0ay__oDJoMh!#xJrW`Ugyes{#YJ;<}vzrh+@?DhheFo2Hnz3oX`NqgP
z9DrQYp^?=gW2fiM{kb_oWHIk$O}LbLyKcYj%#LU@&~1Cm=2$03;Op3u$I`90R|Syl
z^>)YujO8%|ztKOXMSRacX9*4noNZJ5u#AXUI5#MzD(d-R!=G
z!T~VypZ9!4PJ|XtHF!tUyi4po+N#DHe}CN@db=oGCXQG?V_<|!O_h^-!yQ7UZYwQjC%+Gj%vHN`^W=jRqXkw0JGDZ8(
zvLH6Q$7*Z}OC=cvYo*>l4{W^=CK+b36n%%q@DL-h+RjME-ZU|FjA!RTbL*
z)7XDELXnFBVVlo7ADBAKPe|fLho@ajXa1BYXKno);=$`OHS#*t4Lw%VJbO`gF@_^dhb`9GUkcKxG89wF*sm#fUqLV7Ed_IG$RY|ty#C=iF+qq^ti4J
zoa*PvR80+@0Uu|00w8=+sKI#)FLp^-UT|cvHRz_?y~2Rm!^VjZMV`Xw}ZFf8lC!7hzfBx{ion15*(`W>nS~`V7^03*n=sCfD&2-q5AA
zjs+gBH0RP$e?KPkKGd%0fOiCxInL_77gldRh
zvcHX)vUD=_VT3r_XFc2G(9G$?X=5ev4QiDu0nwehbav-bn^G&AhXxP=CiA4rpdx%=
zoNptnLDZ^a*;%2aCc!YoFcfZ}ZLp+s6jzn!|KP@s+Y{7}TGT(oY0;`bEk&eV|Ko4<
zzOsQ)XfnBZZs5;F0dVkyrK+ap&m2Vy%&bkih-VnyoMZPO04^LT>U^oB*4eKL
zOWgww*;FZ$QiN1LVEd#rwrqb?DmOfT-)nuAN}2+YC}vakmo0GtpIaFy5gZEP%JNhJ
zaU!4?Z$zDs%b2Qmr89liiP|y_g5=SM0P-y$s|1__hq
zZp3aVahfAoM(yhwr{?D$OCW4B^wr6A(5pyyihWf#?6*{l#;dCRYhd&7Yn{)_k7Z(-
zQaxD|$l@V65@5!+YRRCjNyR9|r?VtwJ4>f579H~FHTCWn!=i<4#p+KhCyxM&2t{}l
z+pMFbf6n$485m?DCm3S3nsZ`-o>w1->6?kajLqXyES$RfKmvK22<8nxgF(z$9^ou?
zQb3xK*n#Q|)F90oRJ6jQMc=w9=A%Mm1PK7D-hACEIVF6mL|s>lpI`m^RYhs8qEzK1
z=dY|YJUX8DDwbSMD>VUk69nilp_(dXe}8xqQHLfXVAQLQ5Jt;wlUt;Qm}Iufm1N79
z@EwBP6}M)uoU65JzH$s%_phmHE8D?>1@%coQRbN5`VsT%&r(h5wzJOI78DWFOhHT*
zT}uXf%S#%RjSX!pY_+regkDWbJ%H~UGai2OiK_Ih_U24Fgi3-t8!S
z`73WPcm57{jN*iFfw#WZZ5>^3yNT9eI&OYN^b!Fgq!A1i7Tl!AGuZHV)EhATqO4W$
zO>B`hW4MFIkPHfg4ogX;K)mpB+@ztjtRpCNyJW2;N!yxrmD%$5!kIjF0+PGD!M^kJ
z-d^qmjewvI7Z&_{T&Bt}K{my|Kg|~J@_fQysnw(%5ri`N6dzhBqHrN22A?~~Y3UX2
z!1Vdx@=3F~$mwAe_)xas>)$;5`o~
zz8)UQ-{l=a-%~nGXScZ&Kte|(#nhjt=YP_bWR}_#=`j+*z)!iTM2mAP==s{5Uy{FT
zQiX6NQ_G41;jK0Vg94rmM{Y2AiijRfY_~@nCoIHy-}k_6y+Zp!piwC($}se#j)QuP
zGzrfU(*qPS7LH?A4xg%C6_(o0`Y=D>35N`WCr}h8PR=fKlTBFmu}yqytT)EdLUYP=
zlvbV_o|(^(Yg?`()iqjop58U_ce8KwoOg%M?l@ZWg;wLo`TDr9mz;#(t$>toOs(FJ
zot8Fv5qMu}djlYiM`0&5%3sW`7BPB9ULNigJ*)(&u?Z+*Bafe^EApV`A3q%}S;1WU
zvovAGh`<%LvU2FQjDNaYIw20cYx6M@>J_N7#(-B
z8eRW-m*^4Si~II0as;c5wgR=L)IaCdHCj#x99_TLsdsaqzPUUQsp~|5%uW5y?*sxh
zI0tqskH>DMrrVzv7ot9w61K<
z&fBp#O2z{MKIHD^?&kIsX?Eknw3yweLAjm-{L!l0FRfn@=|{PV5YSx%P!aAz0`>{~V;SVi}R1JSwv<{gJ#qEWUHI0UOSElj)
z;));9t-$!1)v8)DJ6t@H8!ArVLj_*_rLJ?@*2Vc*(c_&oIs;xkQ?W9O)i~B2
zY@o;zE_MlqL^LIAE?HDYrRE%d&XYXqQ-SxR$7{H!&drf7b?&n++>G_RI8S95(ntRZCCD)NVaPofSRdLyPx(
z%WY*0j2egvYCU`sT3^*ye>G&xMJrU{+$PYvcz}Fewu;5HCN#e69)tZCu(C|dT+(cK
zPDt((+J$))Z3vA21pl+7+jU}T*??z2>m}$iSKe#DBN{|`S038wD#EHnL2~O;;%s|+
z6?b}cvmM1PM8G#vS@i-PL@3GS2-qBNWez?
zf;B&Xtt+nhiN-}Eo7<1Ni3VR-Z@_l$zEVZn8jF;j$x4cXWIe|@?otDQGf9WrXeetdA
zK|4H{I)yVM=Er2HnL!(6kX8L|-Bx`JaG+apJu@B>&~wF;vYKWkyJSe6{I5jjp22?%>AJMs*ahod-4yB2Pu~i
zg&(#yYkAST&YFcre`MXw%^qvksB6|cNmm-s@WIB)X^!rW*4*j^9r-karI>7WVT$*H
z4c!56m>cV^x3RHH5&cYUu<+?x2=Z#rxS+m}#t5%%rDnkMazUf#`da53Y#dO1B3kK>
z5AzOdZT|MMAE(3FG=5}%RM$oSqCoSkE3CUQ+7n{@?fBo_^SM3C<|yl%+O>1>LDmV#8k1GkSvT0(q3%%E%tLhpH*2x=is6La
zImaO6^|cqQgZWhcxOf2ov8~|e%Q{`?M2+s_aGk(AUi~lP0fG@*vGA96?m|yD>!QMS
z(}|9;p+;Qsy*rn}fizvBE8Vu(0=qg@jV-YKtINGUagw3JCjif9M3?wCS~gPs_NI{G
zFBbj9=$l+cKRAFGL&=}S{1Kz~DGP)*=ZpEA&8JlfP0okM=DesIssE-;82et=eg&+M
z##)fU(Uj)G^<`HFT~WUl|BR0Q+E33fDhR_KtJJ2l_lQqpeucK_a@LpEFPd%9q1&;M
zB-jgjS8^{xN)FmA4v1o=Geb10stmil>`S$|;>xo);Nje!u(7e?&q&9+3$j0=a0c+i
z-g{spSL3R{a;OW33cRtuG#Jx3JjvjEnCh`6{T+bJc(L^FQ_)yho)Y4zq4Xn#vDC8v
z+CylIM1}c*YszZs%m{#6%W4+^-8?60>+D4Od@Moa_BQKfk`BG&g+`WXd>U1R$yM0-e@knB2NUTZS+_%&}n509EebnZ@0y9k7W(~R%TT!P<
zA(lLk3f*fECI?i2T$idf%Zx(6!NT244CL;yV6umnb$+2Za{fjV4s)6TOmob3EvUM%OKGhVU7CU2hY^9GcyP;EWOqE^BlX2
z#dISsprUvhMz5Fh-+)-wFQV5}miq()B_#eX9J`(_dAk(VegAM3ZW?gBKT~rqo2H1!
z^mr%HnJQkvT}L1H-q;yJU%GWz2!tz1Wgi^it$C(EPzsSP&v8m-ZV?|B*ChNvj<6r=
zG};0n((c=I+N+Kc5~anc%)G9Lv8fmYD=DID4Rmx`VcWk?RnJpjUj%ad(5Hm&fI>$_
zs`lo9OajE*CwB4hq+Pu~hdheiG`D4Roqp0Y!GmuG%^Nw4R0=E%9+;cC>~{M4v4m+
zEk5tSy{V;13qp)qx0Q%mv~yJ|*Pd2>_t(XaDcbs94!$NjWpmRU%Z=%+HN|pfEM2ZtRhSjt_GmHx1G{)U-Qz&4#^TbC_4|F8G#O;QA+S0kd;i)|{%TVhIxa0-
z9w$-QVE2pyfa&tGlH%%07A}9Oon=C{r+yMXbXr@I{iA_wR#kn92a<;($Wl#aD_STL
z<%<@C*Kwgu^C=XQM?>*4ZIHI7|Z{z@pq@(;BsGmxR?ro%*4?vBoDjfkw=1P)pz)vItVHU
zoTVmPHmzq#s+8Fjg!?E(hk=G3yuYoxi7
zMeoDrHab37XCqXbKC7_A`>qq^#Zoc?dw>4?8T~o=CMQD*snAKDkLP#V&$$HEfW3#k
zzoT|@jmcsm;(xMK>C=`cf{)x4vD$~AS(9Q@$W@IKjg4X6?HXi@asYV%KtgL4qmNB%
z&-E*D47k(5mN~heZOGxMQXlxR8jp4eLy&cOq?va4lfVE!u)B@qDe|(wI?~Q&+DaMOR
zmMpx%%?=+SLx+YVrkqNdO&B5zS?sfvkb;^7q3H8tOkMGR$)E5bpgg!bdUTC53Qz$qIJVZnnna4Z<{~j(Z?tJm-KP(Dag-yE!dfm+$aHakx!u$bl6zExUM8bM1*z)~*4@`JO
z@hNz4Ur>J^YDtK312p42ne<&fzc~p0)&+fB1)}Zmgg@M`lEhFvPWn>o+2cRe|BfNT
z!`9c*skEYg$NEz2$1CGD*_+1tV|O%td}MOfJ08ubJB1y*9C5*D3!jy)+4_fTAXWaZ
zJ=|c?0=1t<#_6;dh7OOeB|G?)q_g1a66y$I_HAwhKe7lF#n+eg{h2+Hf=zQlOi$GHgxb?5TV@gt^Em(@TXG?=Du{j4v-Zx=TVHJ_5|CAFeE1-(FvW7-L(rPagK1
zR!*f!Ri=LCq9P~-whOMe?o=f2VTQFldQSyk_=@D0JA$haa`S_8#_Z(HjqHeuJvf8c(r$+w>P;5K`vtQGK^I%V_LMj0Pxd8`BIEI77gzh6gAFk_=0q~ucV?p{Pa1^x(zJsGAI;eI
zrIKDk>n+RlKk22H-nqS+XNAOakN>0}zF1FJi=#dB?*s!#wwj%~YEotx))l!R#k
z;Hcaa6lu5HU4tIQCVf`{t#M0qR5%8O|BY}Se;{Qdv*$TSG~lGopprlPORnJi!BE+4q%OPGi&?4f
zVR(b2R!CNR6-Dsher7!c)*4o;tMiy6LN5Q*zwEXK`t}2C`$js%Y-vnk#+HdyT~N#~
z%w}HzFoTd@Qg-gB>Tf@fvz+sdD{a_M7xu=^gZ`O{Qf{0)KX@~LRiNKju%CJ|Q;-!g
z!FbL_(TFd34J6fP@X}qw&yJIwGVwP%qQPm)*~#x~{aTVNN|OsICS}cXwh<0FLiieO
zdhqXupc?ApsM5`;+3U?lU=4up?cc5H)D@kcBbfAp(G5ZJw&0=0DrwpPoC0=w`c?+z
z`f%VjeS&p>N5VtVwt$)w6l1{7UAwTHB5{n9i0xk=+R><;Rehe+%1{LKMyZZ|c%IJ80*
zvU+vsVm96P+Ml!lV&Qz6$w2MWCN`vre|O&JtLvu*C9`6&g_G+mZNYmUd@ETq!C
zzgWy8E9DcM3NtJJ#jS|M>LBakYOg<>s|A+hXkKr&pNvseXMhc$_HezxKk0++_#z6x
zoBb|=Z$gUZf0~1aYx+GIz@M@VIF;6Xc1&eFGc?J1YM{MLLA+g#QQ=Xs_uqS3{}p-T5H)p*uqn!Vb$&N*{Gr5fO-
zGVVoa0wy(OkYw~}rP1gR5pAA{sF^SOvHbI1j;t(QxvDu=AAfwtpzE=eBok-M<*VeZFe~tL*{PdXc=yBuWCGsU~$Yu5A@5Z@TBFCigI|nvYD|p1OZoFV>s#}*&
z)^rNrH`NGi5CH`d-w5G?(q96QXTE6|wg&FZ?C%%d4BYr*U7O7vE3waR6--G;ie#yh
zl{jGf*LE~LXTNFQ5#;i44R3Y6{SjXkU9D#kHj$FAan1Zd-(P<^82=3z^OKQ|)uzOP
zimt_%*PAFFKZVI1KhKs64Gtt=W@2dOu%Pr=+(ldvKyV7nY2hkDKLdUJDYi*a8q
zo0a9A16UTXkg>?lCM@p_Uj|JfMV8S)k?d*TPu~@$dpHyw@_6v}Rgi@JL@=b;+awe>
z?6KayVOFopj|&f#PACC^+s*EagMsPs3dE6b%7$3JwJ5zaf?!;fV95MY1-_Bn`Kc5
z;`idxhW-e6a&tW}^O?0|E%|T^p-h5ID;yrtu29@EP0Sn~%d}Qz_Iar)fEgorM}!FR!Js~i*A(SUTXy{I8?MiXnV9mDw@csPR4GEs0!~bs`(?o@u@1{m+ZP1Pwj*p
zK>A}e**KftF1tDIBlxgUg&4hk4#slUUQojIH(I$D2o9e(U78L<+gk`VbHPeuHP
zsY#RVG_92W?_F*)_6El5_nXU)3;X`{oppaA+DwPjGu1?3_B)AcpxP;623ES=Yq33d
z(n-)zz|&5pi+T?!3SHRmp5F)mxZOUrt{T2A^&X>8lC@$c&KkJx-%DSj@2Md2fQ!pg
zin+^FIkpWBet#f3*f6Sgd46ur4nr7p7FpSl^mP-uOpU-u#{g?W9JoxXUP`ug;lDC4
zYD%64U0mdZ%QJhAH(V}5m5hu8n=^@ZiP6;=5^UX12Vd8?aS~Orp|XIBp=gxmf$pBh
zJ%7*B@W}bQh)rNFbrMdvReZ0Vi+h+x3e$6I+L+!KDfYQc!Nuk(<8}RYeJF|7@?*R4
zL+94-$-d5LQ4<_e6=BV^O!L$Cf@^>40W7^&9^RyKsdIPsLGl(L%u$ZBjoiH$<*>w5aveTel;{5O0
z+Bv4k6{A?|3s3f?b&$=~V)wETC)xP(PCH6KKs&)Dm?)A_;Zb7vKd^xsavXu3?{(;`
zo4CHIe&rsp-(c78*2_`;cf|w(^SZT{?;AE|N8iOCm5=nYZ?Am;sc?B%#SY30J`1Aj
zS>tW9OQ~6VVW3I-mXLD^!45wup)dAxYb)=}xZVe|TPgWa2nxkoQ>n%Rl>V0yq`|lX@cX!ViHWUv8;5MZg?0{mu
zKAz)l&nyXY(~`cVRz8-=vymQBsK_keZxU+}Mmdy;#8b7*+Fm1nFusc@o;#k(E#l0k)&3G>9C
z6v;tQu}Yw1=1BOkQCAXP@KVq-{(1J?mXy|hS6P)hn0nlH$Ma;uLy^F>C4`$U+&VWG
z^vRbTR6n^c9^%My=w5~r(GoVxLbuBvF02Z>6_SBJ`lf4Tyw@`sV+2qCN~q^-tv*#1
zt3cY{7;E;2e9kZXO-zhGWq6VyeWYx=b>2rFsZdTL`1N&mWli3*3P<#c=c`a-8_M0=
z-yRyV!H%DEK3n+<&>%GcFWWp(-u(GPChz7|9&s*_CAI9xnXtTD7Wa#$x{8&_-15$
z8D0M@V?)#sO3qo$!Hk_6E%9U}%)>peOnfY)Yw%{N_lEwWU}U|36~NP5D`b?L4HvP~
zN9BSTn8B2Wks*8gZ?}gzr1(Kuc#Z4%(
zR-oe}HSzfr9B}Cq`(O3^Mv!`05(_jwqhgIMKaPqrt2=AKjn@Kyoh1m*_mU9vi24X9
zVcmhJLxc~7{hL?Ux_y%NkotfsJJUHhsv5bzl5U1onyflX
zav$UlCa*0t4uyA;iLRO(L+>J`6$SJ-=1JI)fB88HqGd$YO46u>-#=lNz5<_jBwu&V
zL*Aa^Tp}4?P=}St6ksRk|E0JzJw2Po#K26Sjr3z6Kg);Y5Z|Y(fadcd_v;r9kH?&z
zaFVTg7x(jUesDBB
z@9i`I3$Vj}!HfuOdP*%2ecPGJxu}=xf}u=Z^1Lhz|8v6J<`DU_QXl%>;kix756ll2
zzRpM&J~jKtcPehGVgX(=zb#Lmf5d-1*oh%{x%bg|Jlf_^={TyfQWvy?5Tsdrm7A^I
z0qrv5dJ_U1HkIXvqJ3>y%s7=WNN2Ldn`GG5FB>2jOGdi%8RxXrpfU<7+V_
zvot|71+ZqV>Hj~GACSrRyVuqBkVz48KuMfA>SVXg#4-)Cv;$D6gHNI>dh;DWi4@Od
zYhV<|i#=L~|C#;4t@F7}=Cy+k>+OOr#w#5Gpr_%@jsO3Bg)042#0-l&cMAeVyq7^0dQ+%`dq{wxHi1os#ki0w5>Xnu`1gbN*I3(s
z#p_Pi!)CSc(3bK6cFg1=;(gYx|NX_8b|qw+;8H@9F>7|ecUUhx@w4aFbdrTOmrIpd
zTU8W{8jo5Aq!;gU^3CU2_`!0sJUTr>N(e)DVk>HYb~N5=CIq$`vJrWf<3dt|;*H19
zQzAy)ubPXtDSZpLusdaSvIMUF`FLqe2f984H{r_W&svz4;M#FZYO2|LI
z$_C5+xsza%S@L&q*bx-0E09mZ#!-#hq5#+E
zgsVHRoZs5kIadm-18ZK@_9%`eCs)W5kB9ZB(3{9umkL
z@Uv%C_vlGS&f9Mf==f1hD`cWvTbC`31x7C>|bIM^Z2gzc$+#bkU6zK4oRf)6oONcHFIf8
z^{|PF{fPaxjv_Z)xx12m9-_Yfx#a519MzRH?e|sV^5}w1=VA_SHaJ_)@O5i##GJPf
zRf-*`r(4~9_hnv^Y#gV1_6Me>PQi?^!-2-`X=~r^!w*cEAEfgG6aK`Q%`1DS9@Kk1
z!mC&i{lX2SMTW{!aIwv}aenLP0(FK5FRv#H?jU>_8GQ|H6+SPMifWfkH-hP{g2}*r
zQ)_kP3Q+LYjA7*Wk;5h`-U}Cvll4DT5;pD%E^#X^F1?N9#@N_3eWhyEUA{Iseiad9GXIKE%YnvHDOJBSM?$=L(
z>7*Q+R-GG2bcwU&s4Q}sy7UdaZ|n#y#7>K2%~q|IFvOsOKL4nNVE!s(CMDoxBc
zD)OF9KJ_U)o(i)5Zy4yruvXtUjx9gPbbYqOxEauxrf7?ZJGXwFUflYhwK|2y8s
zz1xJ1XRf;vNeRrPl;x@5yY&d1o-E7{06-5J18aVK&=7)O;i12a-_t?@a#NBTwIOT&
zRA*Hv_>*ghZ_#*cAB&Bku2BmXvuQO&(eqQ5?mPVy{{nfMxATCHV;L)%Z=iOAe|d3~
zXsY2y7oC#1V)uNY{q$~yYUti#e>P}rom`Gzag649K6)=-0`p89@m@pXi=FiOYhR%#
zckOTB^)N=YrCc?)>qbkH33bxh6P|l_IBX3lHZ|0_e-7&GrM|uE`wrTWRht9jEOmKzL#Qx~aZa0>jka$Cvf9oMk8|U$GvD?q}s_uyTN7YH>
ztRChlX_2w#PB>0=HFpy+#eo0Bs*TC9+LI(Kbc0#bS74xw<3yK=_t1ay2P~NTmB3VX
zlBbBBpddKDayI|2^>HVe{tUh&D$1#jh+HgGAfK5FkR)??K2X<2tf8c{;Hw;*ftdpNEsr?5=?C;^-L+JN7zO4~D5Pz?N}aBnRe$v?rtQCW3-!Ppcf
zo?Z4}ShQ|v=&a{~PA`3^jIuV_uM(yWV0pNG+@9%GtgrlVjMMJ9l9N5gJ|P3gJQCHm&i|p>2tBr(P=1d^Asv@{PFxi&G@U7!^NzE
z^wbcWekB+4sdMX(+LD0~>H!6Nf^I;W0WT5gc`1ctVwdFvXRX{0_mP1z=Y#=iNFg6p;_!vM=%W~O0+<9k=f
z?*p&SLS(l|@}~aeFp06`v@hzKic1DDX4k7eXsT!^*gtT4h2KU`Lg$qwj2t+*f#rL~
zszXxn0jm^PQELYMh%6upBhx=E4a+RHUgSc|PdmUq&-wYt@{~Ud_CloNv>P00mysP=
z?^RrI`qBdYgKAOxspA8fP1yZh&|`GxV7_P>I>4+vN|+yswFsu>)eWekbJ|7w65OkR
z|7WscL%bHkBP{+Zq&2Pw9vh2m3`>@dh`5q&<^%hAU;FOH^H0ZND8)fRjk@EduuUN^
z1y*~f`$rvEV&UZ0OIZ&TIG?h@hEYb#G>r_M8DZ_3)q0o@Tua?*InaZxaBH`4M-Xyu93RoNvppQX$GbjSyY%4Gwg5#edS~
zyG)OSI*p|pb5^jm9eek=*jou#!O#&7YA+M%hrT?|S&1
zPR`dV>4hZvX2Knghbmj?!2Q!A!Hyg6)er-n9?)6qS7uMkcVpm}Z#=xuliyRgLKc6J
zmC=!C=&9wU011lsBOlX#da+K}Q@2{eKh=`Lx*eWekq@3|Q1Pk=9`
zt9N$@@N@7Ba(Dk60HtK>Fg04GSA;osT?a((d^^Y_c52n-Pj%d*yfeU`gx7GK`@CON
zpSqUXO2e0LdmR|$P&;3m9&11q2W*I%wRrPA?3YEYtjN*~XmwzNFDcV7bJ|Y;kj@F(7j*ScDgmp;$q}BZR;tB*1k=$7APGd9U4M#F9
z5oI!Z{fPs9@_R&H!~9n7o8tGKf=YHTg{!9R9ZhvL#@zP$q2>+0OGy%5!d-k0eGv)8
zt@ahu2W6n9I)zLCOW@RMT3LqF|Tj)a=4n=_NPMDa23$wXV9_-
zR=_sMtZMS_WoVQA7sl(T*l7V$DMD@>asC#h?_`^86Dhv!Du~GgG`*l54N@_=_C+$2
zbHu6st(NpnEA{Zbgj(#JE~c#wGgUguL=24jP}6Ec%)J`HY@zpfq4AEN{5+qQ7c^Dp
zbvT6Jz&2k_+t*j^;7_uQ%QPz%DH<*5vXPP(C|Ku#Y4k(W|Bi5#0d`*w+P>L;q4{#+
z2Oil;>r#{^i_j^k^Z)dL;>Q{UP9Q;kf1z|BmRDxi9JjS;{jwwO24;F+{k6oiw~u4?W#7YIQv)
zDveI=H(#qvYgdE%m}83p`J))1Q+xO);uTB7DX`o76Evq{FCBm$xkt=!1aTOU!8We{
zDevjJTl81KXx_MJdRbopaugWoww)U}@-4Q(*eNK$^Rq>f=`^7fq(7J`I{cyksxN{b
z(=Z=KXRm8&TW7N&tTd<7uZPS|^i5j${4J)1Nh=9BI>DqX$rCgM3fM?%c}hxwU@T@d
ztqBjOqsQnIu9bt|!?CS^$^)f|bf0#|Wf0&kiTQS|4(HDRAycdijlEfd=dT6_ahF{{Z2~#c=C1
zjrXAPlrj#p_M+W%WBZ9AS%A5C9<qV`+@4{*X>}U |