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 DAST and WebApp DAST testing modes and integrates seamlessly with CI/CD workflows.

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. This enables precise targeting of security validation to the attack surface modified by the current code changes.

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:

1. Code Change Detection¶

CI/CD pipeline automation analyzes the code diff to identify modified files, changed API routes, or affected web pages. This can be accomplished through:

• 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¶

The affected application paths are translated into Escape configuration overrides:

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

3. Incremental Scan Execution¶

The CI/CD pipeline invokes Escape with the calculated scope, running security testing exclusively against the modified attack surface. 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 DAST 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 DAST Scope Limitation¶

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

Implementation:

escape-cli scans start [profile-id] -c '{
  "rest_api_dast": {
    "allowed_url_patterns": [
      "https://api.example.com/api/users",
      "https://api.example.com/api/users/*",
      "https://api.example.com/api/orders",
      "https://api.example.com/api/orders/*"
    ]
  }
}'

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.

Implementation:

escape-cli scans start [profile-id] -c '{
  "graphql_dast": {
    "allowed_operations": [
      "Query.user",
      "Query.users",
      "Mutation.updateUser",
      "Query.order",
      "Query.orders",
      "Mutation.createOrder"
    ]
  }
}'

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¶

A complete GitHub Actions workflow demonstrating incremental scanning on pull requests:

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¶

A GitLab CI pipeline configuration for incremental WebApp DAST on merge requests:

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¶

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.