[REVIEW] dast-config: add authenticated stateful scan safety gates

[shensz2017]

Skill Being Reviewed

Skill name: dast-config
Skill path: skills/devsecops/dast-config/SKILL.md

False Positive Analysis

Benign authenticated DAST setup that should not be flagged just because it exercises state-changing flows:

env:
  contexts:
    - name: staging-shop
      urls: ["https://staging.example.com"]
      includePaths:
        - "https://staging.example.com/shop/.*"
      excludePaths:
        - "https://staging.example.com/shop/account/delete.*"
      authentication:
        method: browser
        verification:
          method: response
          loggedInRegex: "\\QSign Out\\E"
          loggedOutRegex: "\\QSign In\\E"
      users:
        - name: dast-buyer
          credentials:
            username: "${DAST_BUYER_USERNAME}"
            password: "${DAST_BUYER_PASSWORD}"
state_safety:
  environment: ephemeral_staging
  seed_data_reset: before_and_after_scan
  anti_csrf_tokens: refreshed_by_sequence
  mutation_budget: low_value_test_account_only

Why this is a false positive risk:

The current skill correctly requires authenticated scanning, excludes destructive endpoints, and warns against production active scans. But reviewers can still overcorrect by treating every authenticated state-changing flow as unsafe. Some business-critical surfaces only become testable when the scanner follows a sequence that creates a draft object, refreshes anti-CSRF tokens, and mutates seed data in an ephemeral environment. The skill should distinguish safe stateful DAST from unsafe stateful DAST.

Coverage Gaps

Missed variant 1: active scan runs authenticated business flows without seed/reset evidence

jobs:
  - type: spider
    parameters:
      context: app
      user: admin
  - type: activeScan
    parameters:
      context: app
      user: admin
state_safety:
  seed_data_reset: missing
  post_scan_cleanup: missing
  mutation_budget: unrestricted

Why it should be caught:

The skill says active scans should target staging and exclude destructive endpoints, but it does not require reviewers to record whether authenticated state-changing requests are constrained to disposable users, seeded data, a mutation budget, and reset/cleanup evidence. A scanner can create orders, update profiles, trigger emails, consume inventory, or pollute logs without hitting a literal /delete path.

Missed variant 2: CSRF/anti-forgery tokens are stale in replayed authenticated requests

sequence:
  login: captured_once
  checkout_post:
    csrf_token: static_value_from_har
    refresh_strategy: missing

Why it should be caught:

ZAP can support authentication verification and sequence-based scanning, and form auth may need anti-CSRF token handling. If a DAST plan replays stale tokens from a HAR or captured request, coverage can silently fail: the scan appears authenticated but most state-changing requests are rejected as invalid, producing false confidence.

Missed variant 3: multi-step flows are spidered out of order instead of scanned as sequences

flow: add_item -> create_draft_order -> apply_coupon -> submit_payment
scanner_behavior: generic_spider_then_active_scan
sequence_evidence: missing

Why it should be caught:

Many modern apps require ordered state transitions. Generic crawling may miss later steps, skip required token refreshes, or hit endpoints in invalid order. The skill should require sequence evidence for stateful flows such as checkout, account recovery, onboarding, subscription changes, and admin workflows.

Edge Cases

• A state-changing request is not automatically unsafe when it uses a disposable user, seeded tenant, bounded data set, and verified reset/cleanup.
• Excluding every POST/PUT/PATCH/DELETE path creates blind spots; the better gate is risk-based inclusion with safeguards.
• CSRF token refresh can be handled by scanner configuration, browser auth, sequence scripts, or app-specific hooks. The review should record the evidence rather than mandate one tool.
• Production passive scans may be acceptable, but authenticated active stateful scans need explicit approval and rollback evidence.

Remediation Quality

• Fix resolves the vulnerability
• Fix doesn't introduce new security issues
• Fix doesn't break functionality
• Issues found: Add stateful authenticated scan gates that require sequence evidence, anti-CSRF token refresh handling, seed/reset controls, mutation budgets, safe test users/roles, side-effect exclusions, and post-scan cleanup validation before considering authenticated DAST complete.

Comparison to Other Tools / Sources

Tool / Source	Catches this?	Notes
ZAP Automation Framework	Partial	Supports contexts, authentication, users, job order, job tests, and sequence jobs, but the skill does not require reviewers to capture stateful safety evidence.
ZAP Authentication docs	Partial	Covers authentication methods, verification strategy, users, and anti-CSRF token handling for form auth.
OWASP WSTG	Partial	Requires authenticated/session/CSRF testing but does not by itself define CI seed-data and mutation-budget gates.
Current skill	Partial	Covers authenticated scanning and destructive endpoint exclusions, but lacks an explicit stateful scan safety matrix.

Overall Assessment

Strengths:

• Good ZAP Automation Framework examples.
• Good separation between passive PR scans and active staging scans.
• Good basic authentication verification and scope management checks.

Needs improvement:

• Authenticated DAST should not be considered complete without stateful flow coverage evidence.
• Reviewers need a concrete decision matrix for state-changing requests that are safe to scan, unsafe to scan, or only safe with sequence/reset controls.
• Output should record token refresh, seed/reset, mutation budget, test user role, side-effect exclusions, and post-scan cleanup evidence.

Priority recommendations:

1. Add a Stateful Authenticated Scan Safety step after authenticated scanning setup.
2. Add finding triggers for missing sequence evidence, stale anti-CSRF tokens, unrestricted mutation budget, privileged test user, missing seed/reset, and missing post-scan cleanup.
3. Extend the report template with a stateful scan safety table.
4. Add vulnerable and benign fixtures showing unsafe authenticated active scans vs controlled sequence-based scans.

Sources Checked

• ZAP Automation Framework: https://www.zaproxy.org/docs/automate/automation-framework/
• ZAP Automation Framework sequence support: https://www.zaproxy.org/docs/desktop/addons/sequence-scanner/automation/
• ZAP Authentication: https://www.zaproxy.org/docs/desktop/start/features/authentication/
• ZAP Authentication Methods: https://www.zaproxy.org/docs/desktop/start/features/authmethods/
• OWASP WSTG session management testing: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/06-Session_Management_Testing/README

Bounty Info

• I have read and agree to the CONTRIBUTING.md bounty terms.
• Preferred payment method: GitHub Sponsors if accepted, otherwise private payment details can be provided after acceptance.

[rock2089]

I'd like to work on this bounty.

[JamesJi79]

/attempt #2109

Will submit VALID GAP analysis.

[JamesJi79]

/attempt #2109

VALID GAP — Authenticated stateful scan safety gates

Why Valid (FP confirmed)

The current dast-config skill correctly covers authenticated scanning via OAuth 2.0 tokens, session cookies, and Basic Auth, as well as API key usage. A scan using a dedicated test account with scoped permissions and automated session refresh is properly assessed. The gap is that the skill does not require gates for safe stateful scanning: ensuring the DAST scanner does not modify production state, trigger side-effect workflows, or leave behind test artifacts.

Coverage Gaps

Gap 1 — Scanner can modify or delete data through authenticated session — An authenticated DAST scanner with write-scoped tokens or cookies can create, modify, or delete records in the target application. This can corrupt data, trigger downstream workflows (email, billing, alerts), or leave test artifacts. Need gate: Read-only scope verification for DAST credentials; write-action detection in scan results.

Gap 2 — Stateful session handling can leave orphaned resources — A scanner that exercises stateful flows (registration, checkout, form submission) may create test accounts, orders, or records that are not cleaned up after scan completion. Need gate: Pre-scan state snapshot and post-scan cleanup verification with evidence.

Gap 3 — Scanner authentication secrets stored insecurely or shared — DAST credential secrets committed to CI config, shared across environments, or lacking rotation schedule increase the blast radius if the CI system is compromised. Need gate: Secret storage audit (e.g., GitHub Secrets, HashiCorp Vault, or equivalent) with rotation evidence.

Suggested Gates

1. DAST-STATE-01: Verify scanner credentials have read-only scope on the target application. Evidence: OAuth scope configuration, token introspection response, or application RBAC policy.
2. DAST-STATE-02: Verify stateful scan targets have a documented cleanup procedure and post-scan state verification. Evidence: cleanup script, rollback verification log.
3. DAST-STATE-03: Verify scanner authentication secrets are stored in a secrets manager (not in config files or CI variables as plaintext) and have a rotation schedule. Evidence: secrets manager access logs or rotation policy.