Skip to content

Incremental Scanning and Configuration Overrides

The Challenge of Full-Stack Security Testing in CI/CD

Modern applications consist of hundreds or thousands of API endpoints, web pages, and user flows. While comprehensive security testing is essential for production releases, scanning the entire application surface for every pull request or merge request creates significant operational challenges:

  • Extended Pipeline Duration: Full application scans can require 15-60 minutes, blocking merge workflows and developer productivity
  • Resource Consumption: Comprehensive testing consumes compute resources and API rate limits disproportionate to the actual code changes
  • Alert Fatigue: Pre-existing vulnerabilities unrelated to the current changes generate noise that obscures new security issues introduced by the pull request
  • Cost Inefficiency: Testing unchanged functionality repeatedly incurs unnecessary scanning costs

Escape's Incremental Scanning Architecture

Escape has been architected from the ground up to support Incremental Scanning—the ability to narrow security testing scope to only the application components affected by code changes. This capability is available for both API Testing and WebApp Testing testing modes and integrates seamlessly with CI/CD workflows.

Escape does not detect code changes for you. The platform does not read your Git history, merge request diffs, or source tree to infer which routes, endpoints, or pages changed. Whatever scope you want tested must be computed outside Escape (for example in your CI/CD job) and passed in explicitly through configuration overrides. If you start a scan without those overrides, Escape runs against the profile’s normal scope—not against “what this PR changed.”

How Incremental Scanning Works:

When a scan is initiated via the Escape CLI or Public API with configuration overrides, the testing scope is constrained to the specified endpoints, URL patterns, or operational parameters. That scope is whatever you supply; it is not derived automatically from the difference between branches or commits.

Architecture By Design:

Unlike security testing tools that require complex filtering or post-processing to achieve incremental behavior, Escape's scanning engine natively supports scope limitation at the configuration level. The same testing methodology, vulnerability detection algorithms, and reporting infrastructure operate on the constrained scope, ensuring that incremental scans provide identical security coverage to full scans within their defined boundaries.

CI/CD Integration Workflow

The typical incremental scanning workflow integrates with merge request or pull request automation. Steps 1 and 2 are your responsibility in the pipeline. Escape only receives the final override payload when the scan starts; it does not run diff analysis or map files to URLs for you.

1. Code Change Detection

Your CI/CD automation analyzes the code diff to identify modified files, changed API routes, or affected web pages. Escape is not involved in this step. Typical approaches include:

  • Git Diff Analysis: Parsing commit diffs to identify changed backend routes, API endpoint definitions, or frontend page components
  • Framework-Specific Detection: Using framework metadata (OpenAPI specifications, route registries, component mappings) to map code changes to runtime paths
  • Static Analysis: Analyzing import graphs and dependency chains to identify indirectly affected endpoints

2. Scan Scope Calculation

You translate the affected application paths into Escape configuration overrides (still entirely in your pipeline or tooling):

  • API Testing: Specific REST endpoints, GraphQL operations, or API route patterns
  • WebApp Testing: URL patterns for affected pages, navigation flows through modified components

3. Incremental Scan Execution

The CI/CD pipeline invokes Escape with the calculated scope. Escape applies exactly the overrides you pass; it does not re-check the diff or widen the scope to match “actual” code changes. Results are reported within the merge request context, enabling developers to address security issues before merging.

4. Merge Decision Gating

Security findings from the incremental scan can block merge approval, ensuring that no code changes introduce new vulnerabilities without explicit review and remediation.

Configuration Override Capabilities

Configuration overrides are specified via the -c or --config flag when initiating scans through the CLI, or via the configuration parameter when using the Public API. Overrides support both scan behavior modification and scope limitation.

WebApp Testing Scope Limitation

Use Case: A merge request modifies the checkout flow, affecting the cart, shipping, and payment pages. Testing is focused on these specific user interface paths.

Implementation:

escape-cli scans start [profile-id] -c '{
  "frontend_dast": {
    "allowed_url_patterns": [
      "https://shop.example.com/cart",
      "https://shop.example.com/checkout/shipping",
      "https://shop.example.com/checkout/payment"
    ],
    "hotstart": [
      "https://shop.example.com/cart",
      "https://shop.example.com/checkout/shipping",
      "https://shop.example.com/checkout/payment"
    ]
  }
}'

Configuration Parameters:

  • allowed_url_patterns: Defines the URL scope boundary. The browser-based crawler will not navigate beyond these patterns, preventing exploration of unchanged application areas.
  • hotstart: Specifies explicit entry points for crawling. The scanner will navigate directly to these URLs and begin exploration from each, rather than discovering them through link traversal from the application root.

REST API Testing Scope Limitation

Use Case: A pull request modifies the /api/users and /api/orders REST endpoints. Testing is constrained to these specific paths.

Implementation:

The regexes here block all paths excepted the users and orders.

escape-cli scans start [profile-id] -c '{
  "rest_api_dast": {
    "blocklist": [
      {
        "path": "^(?!.*\/user).*$",
        "method": "POST"
      },
      {
        "path": "^(?!.*\/orders).*$",
        "method": "GET"
      },
    ]
  }
}'

Pattern Matching:

The allowed_url_patterns configuration accepts glob-style patterns, enabling flexible endpoint targeting:

  • Exact path matching: "/api/users"
  • Wildcard matching: "/api/users/*" (matches all sub-paths)
  • Parameter segments: "/api/users/{id}" (matches parameterized routes)

GraphQL API Scope Limitation

Use Case: Changes to the GraphQL schema introduce new fields on the User and Order types. Testing is constrained to these specific types and their operations.

The regexes here block all queries and mutations other than user and order.

Implementation:

escape-cli scans start [profile-id] -c '{
  "graphql_dast": {
    "blocklist": {
      "query": [
        "^(?!.*\/user).*$"
      ],
      "mutation": [
        "^(?!.*\/order).*$"
      ]
    }
  }
}'

Behavioral Override Examples

Configuration overrides are not limited to scope control. Any scan profile parameter can be modified at runtime to adjust testing behavior for specific CI/CD contexts.

Read-Only vs. Read-Write Testing

Use Case: The production scan profile is configured in read-only mode to prevent data modification. For staging environment PR validation, write operations should be tested.

Implementation:

escape-cli scans start [profile-id] -c '{
  "rest_api_dast": {
    "read_only": false
  }
}'

This override enables POST, PUT, PATCH, and DELETE operations for the duration of the scan, allowing comprehensive testing of state-modifying endpoints.

Authentication Override

Use Case: Different authentication credentials are required for the staging environment used in CI/CD compared to the primary scan profile configuration.

Implementation:

escape-cli scans start [profile-id] -c '{
  "authentication": {
    "users": [
      {
        "name": "staging_user",
        "credentials": {
          "username": "ci-test-user@example.com",
          "password": "${STAGING_PASSWORD}"
        }
      }
    ]
  }
}'

Environment variables can be interpolated into configuration strings, enabling secure credential management within CI/CD secret stores.

Security Test Selection

Use Case: A specific pull request modifies SQL query construction. Testing should emphasize SQL injection and related database security tests.

Implementation:

escape-cli scans start [profile-id] -c '{
  "security_tests": {
    "sql_injection": {
      "skip": false
    },
    "nosql_injection": {
      "skip": false
    },
    "orm_leak": {
      "skip": false
    }
  }
}'

This configuration ensures that database-related security tests are executed even if disabled in the base profile, while other tests follow the profile's default configuration.

Real-World Integration Examples

GitHub Actions Integration

Example workflow shape for incremental scanning on pull requests. The Detect Changed API Paths step is a placeholder: Escape does not implement this logic—you must replace it with real diff-to-path mapping for your stack.

name: Incremental Security Scan
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  security-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
        with:
          fetch-depth: 0  # Full history for diff analysis

      - name: Detect Changed API Paths
        id: detect-changes
        run: |
          # Extract changed files from the PR
          CHANGED_FILES=$(git diff --name-only origin/${{ github.base_ref }}...HEAD)

          # Parse API route files and extract affected paths
          # (Framework-specific logic would be implemented here)
          AFFECTED_PATHS='["https://api.example.com/api/users/*", "https://api.example.com/api/orders/*"]'

          echo "paths=$AFFECTED_PATHS" >> $GITHUB_OUTPUT

      - name: Run Incremental Scan
        run: |
          escape-cli scans start ${{ secrets.ESCAPE_PROFILE_ID }} \
            -c "{\"rest_api_dast\": {\"allowed_url_patterns\": ${{ steps.detect-changes.outputs.paths }}}}" \
            --wait
        env:
          ESCAPE_API_KEY: ${{ secrets.ESCAPE_API_KEY }}

GitLab CI Integration

Example pipeline for incremental WebApp Testing on merge requests. Path derivation from git diff is your pipeline’s responsibility; Escape only consumes the JSON you pass to -c.

incremental_security_scan:
  stage: security
  image: escape/escape-cli:latest
  script:
    # Analyze merge request diff to identify affected pages
    - |
      AFFECTED_PAGES=$(git diff $CI_MERGE_REQUEST_DIFF_BASE_SHA...HEAD --name-only | \
        grep "^frontend/" | \
        sed 's|^frontend/pages/|https://app.example.com/|' | \
        jq -R -s -c 'split("\n")[:-1]')

    # Execute incremental WebApp scan
    - |
      escape-cli scans start $ESCAPE_PROFILE_ID \
        -c "{\"frontend_dast\": {\"allowed_url_patterns\": $AFFECTED_PAGES, \"hotstart\": $AFFECTED_PAGES}}" \
        --wait
  only:
    - merge_requests
  variables:
    ESCAPE_API_KEY: $ESCAPE_API_KEY

Benefits of Incremental Scanning

These benefits apply when your pipeline computes scope correctly and passes it via overrides. Escape does not validate that the scope matches the Git diff; incorrect or empty overrides mean you are not testing what you think you are testing.

Accelerated CI/CD Pipelines:

By constraining testing to modified components, scan duration is reduced by 70-95% compared to full application scans, enabling security validation to complete within typical code review timeframes (5-15 minutes).

Focused Security Feedback:

Developers receive security findings directly relevant to their code changes, eliminating noise from pre-existing vulnerabilities and enabling immediate remediation within the development context.

Cost Optimization:

Computational resources and scanning costs scale with the size of code changes rather than total application size, making continuous security testing economically viable for high-frequency deployment workflows.

Shift-Left Security:

By integrating incremental scanning at the merge request stage, security issues are identified and resolved before reaching production, reducing the cost and complexity of vulnerability remediation.