THE CLUSTER OFWACKRoadmap

WACK-PT-RESEARCH-0001 / Research lab

THE ATTACK SURFACE
AFTER CARD DATA LEAVES.

A provider-hosted payment form may narrow the card-data path. It does not erase the identities, code, credentials, webhooks, control planes, operators, and alternate journeys that can still change the security story.

See the two paths Read the source posture

Figure 01 / WACK-PT-FIGURES-0001

Two paths. One attack story.

A narrow provider-controlled account-data route can coexist with a broad customer-controlled security-influence route. Neither path alone is a scope conclusion or a penetration-test plan.

DATA

Account-data path

Where can account data be collected, displayed, transmitted, stored, logged, exported, or recovered?

  1. 01Customer browser

    Begins the payment journey

  2. 02Provider-hosted Checkout

    Collects payment data on the ordinary path

  3. 03Provider processing

    Processes the provider-controlled payment event

  4. 04Token or signed event

    Returns a non-PAN result to the customer boundary

INFLUENCE

Security-influence path

Which customer-controlled capability can alter the route, identity, credential, code, trusted event, or resulting action?

  1. 01Identity and administration

    Assigns effective human and workload authority

  2. 02Source and CI/CD

    Changes the code and configuration at the boundary

  3. 03Keys and secrets

    Authorize customer-controlled calls and event trust

  4. 04Sessions and webhooks

    Create payment intent and consume provider events

  5. 05Support and failure paths

    Refund, retry, fallback, and incident routes

JOIN

Claim-and-evidence junction

What bounded conclusion can these two observed paths support for this implementation and period?

  • testing proposition
  • candidate population
  • authorized technique
  • retained evidence
  • limitation or conclusion

Figure 02 / WACK-PT-CASE-0001

The provider hosts payment entry. The merchant still has an attack surface.

fictional teaching case pending practitioner review
Fictional entityNorthstar Outfitters / Hosted Checkout
Named integrationStripe-hosted Checkout with Checkout Sessions and a customer-operated webhook
Ordinary payment path
  1. 01Customer browser
  2. 02Northstar storefront
  3. 03Stripe-hosted Checkout
  4. 04Stripe payment processing
  5. 05Northstar success route
Customer-controlled populationEight durable subjects surround the hosted form.
01application

Storefront

Initiates checkout and chooses the customer-visible journey

Evidence owed
  • route inventory
  • release digest
  • browser trace
02serverless workload

Session function

Creates Checkout Sessions using customer-supplied business context

Evidence owed
  • effective IAM
  • deployed artifact
  • request validation tests
03credential

Restricted API key

Authorizes named Stripe API operations available to the session function

Evidence owed
  • permission inventory
  • secret access policy
  • rotation history
04internet-facing trust boundary

Webhook endpoint

Accepts signed events that can trigger downstream action

Evidence owed
  • signature and timestamp tests
  • endpoint configuration
  • delivery records
05container workload

Fulfillment worker

Ships an order after the application accepts a provider event

Evidence owed
  • queue authorization
  • artifact digest
  • adverse event tests
06control plane

CI/CD delivery plane

Can change the session function, webhook, and fulfillment worker

Evidence owed
  • deployment identities
  • approval history
  • production provenance
07human administration

Provider administrators

Can change provider configuration and credentials within assigned roles

Evidence owed
  • role export
  • MFA evidence
  • activity history
08operating path

Refund support route

Initiates post-payment financial action outside the ordinary checkout path

Evidence owed
  • role design
  • case samples
  • exception history
Proposition switchboard

Choose a proposition. The candidate population changes with the question; the result does not exist until authorized work produces evidence.

Question

Can one user create or modify a session for another user's order or alter the trusted amount, object, or redirect?

Candidate population

All production session-creation routes and material authorization variants

Teaching-case result

not tested teaching case

Bounded claimFor the named hosted-Checkout journey, payment entry follows the provider-hosted path; customer-controlled session, credential, webhook, delivery, administrative, fulfillment, and support capabilities remain separately inventoried and require fact-specific assessment and authorized testing.

This fictional case illustrates proposition design. It does not state that Stripe, Northstar Outfitters, or any comparable implementation is compliant, out of scope, sufficiently tested, or accepted by a compliance-accepting entity.

The review surface

Twelve claims. None silently approved.

Every statement names its authority class, source relationships, architecture evidence need, provider fact need, and current review state.

WACK-PT-CLAIM-0001PRACTITIONER POSITION

An assertion that entity personnel and systems do not directly access CHD is narrower than a conclusion about PCI DSS scope, testing coverage, or retained responsibility.

Architecture evidence
Named actors, account-data states, interfaces, alternate paths, administrative capabilities, time period, and negative-path observations.
Provider fact need
Exact service and integration mode, not the provider brand alone.
pending practitioner review4 linked sources
WACK-PT-CLAIM-0002PRACTITIONER METHOD

Provider evidence must be matched to the exact service, responsibility seam, assessment period, and customer implementation before it can support a customer claim.

Architecture evidence
Service inventory, current AOC, responsibility matrix, contract, integration configuration, and change history.
Provider fact need
Current service-specific coverage and customer duties.
pending practitioner review3 linked sources
WACK-PT-CLAIM-0003PRACTITIONER POSITION

A maintained penetration-testing methodology starts from the current attack story, complete candidate populations, material variants, and authorized source positions—not from the final report template.

Architecture evidence
Scope snapshot, data and influence paths, threat history, target universe, variant model, rules of engagement, and change triggers.
Provider fact need
Testing restrictions, authorization process, prohibited techniques, and evidence available from the provider.
pending practitioner review2 linked sources
WACK-PT-CLAIM-0004PRACTITIONER POSITION

Stripe-hosted Checkout can move the payment-entry surface to Stripe while customer-controlled session creation, redirects, application code, API credentials, webhooks, administration, and failure paths remain separate attack propositions.

Architecture evidence
Browser trace, Checkout Session creation path, redirect allowlist, key inventory, webhook configuration, IAM, deployment lineage, and alternate payment journeys.
Provider fact need
Selected Checkout UI, enabled payment methods, API version, account model, current AOC, and responsibility matrix.
pending practitioner review4 linked sources
WACK-PT-CLAIM-0005PRACTITIONER POSITION

The absence of PAN in merchant application responses does not remove the need to test whether customer-controlled credentials and administrative paths can alter payment behavior or expose provider-held data.

Architecture evidence
Credential permissions, vault and CI/CD paths, administrator roles, audit history, restricted-key policy, and adverse-capability tests.
Provider fact need
Current credential types and resource permissions.
pending practitioner review2 linked sources
WACK-PT-CLAIM-0006PRACTITIONER METHOD

A Stripe webhook is a customer-operated internet-facing trust boundary whose authentication, replay handling, endpoint authorization, event selection, secret rotation, and downstream side effects require explicit testing propositions.

Architecture evidence
Raw-body handling, signature verification, timestamp tolerance, endpoint inventory, secret lifecycle, event handlers, retry behavior, and downstream authorization.
Provider fact need
Endpoint-specific signing secrets, delivery mode, API version, and event configuration.
pending practitioner review1 linked sources
WACK-PT-CLAIM-0007PRACTITIONER POSITION

Lithic Embedded Card UI can keep displayed card details on a browser-to-Lithic path while the customer backend that creates short-lived sessions and the frontend that mounts the embed remain security-relevant implementation surfaces.

Architecture evidence
Session authorization, user-to-card binding, browser route, CSP and script inventory, frontend release, callback behavior, and alternate display flows.
Provider fact need
Exact embed mode, session lifetime, mounted fields, and production configuration.
pending practitioner review1 linked sources
WACK-PT-CLAIM-0008PRACTITIONER POSITION

A Lithic environment may contain both an embedded display path and PAN-capable API paths; the narrow path cannot support a no-access claim while a broader credential or endpoint remains reachable.

Architecture evidence
Complete API endpoint and key-capability inventory, runtime call graph, network egress, code search, logs, and negative testing of prohibited paths.
Provider fact need
Production eligibility, API-key privileges, endpoint availability, program configuration, and support paths.
pending practitioner review3 linked sources
WACK-PT-CLAIM-0009PRACTITIONER METHOD

Lithic event and authorization integrations create signed inbound trust boundaries; signature, timestamp, secret-rotation, program isolation, replay, retry, and decision side effects are part of the customer attack story.

Architecture evidence
Subscription inventory, HMAC verification, clock handling, program-to-secret mapping, rotation records, replay tests, event retention, and authorization decision flows.
Provider fact need
Enabled event types, per-program secrets, delivery contract, and current product restrictions.
pending practitioner review2 linked sources
WACK-PT-CLAIM-0010PRACTITIONER POSITION

Cloud IAM, workload identities, CI/CD, secrets, routes, logging, serverless functions, and managed containers are durable attack-surface objects even when runtime instances are ephemeral.

Architecture evidence
Logical workload inventory, artifact digests, deployment history, effective permissions, route state, secret access, runtime observations, and reconstructable in-period population.
Provider fact need
Exact services, shared-responsibility boundary, service coverage, and customer-configurable controls.
pending practitioner review2 linked sources
WACK-PT-CLAIM-0011PRACTITIONER METHOD

Representative testing is defensible only after the full candidate population and proposition-specific material differences are known; different trust or segmentation mechanisms are not equivalent merely because they share a template.

Architecture evidence
Population source, variant attributes, selected and represented subjects, equivalence rationale, exclusions, limitations, and expiration triggers.
Provider fact need
Regional, tenant, service, control-plane, and restriction differences.
pending practitioner review2 linked sources
WACK-PT-CLAIM-0012PRACTITIONER POSITION

Cloud and TPSP restrictions belong in the rules of engagement, but an unavailable test position must become a documented limitation or alternate evidence plan—not silent coverage.

Architecture evidence
Provider authorization, approved techniques, prohibited targets, monitoring, stop conditions, alternate evidence, and retained limitations.
Provider fact need
Current provider testing policy and customer contract.
pending practitioner review2 linked sources

The practitioner decision cockpit

Eight decisions. One honest gate.

The brief is approved. The claim map is not. These are the exact paper-shaping questions that must receive Scott Norton’s named disposition before the full white paper earns its way into production.

  1. W/?01
    WACK-PT-DECISION-0001capability language

    Is security influence sufficiently precise for this paper, or should the claim map use a narrower capability taxonomy?

    Decision needed
    Accept the term with an explicit definition, replace it, or identify the capability classes that must sit beneath it.
    Acceptance test
    A reader can distinguish direct account-data access from the ability to change the security story without treating either relationship as an automatic scope conclusion.
  2. W/?02
    WACK-PT-DECISION-0002normative mapping

    How should PCI DSS v4.0.1 Requirement 11.4 be mapped without allowing older supplemental guidance to supply current normative wording?

    Decision needed
    Name the current requirement and testing-procedure anchors, then bound every use of the 2017 penetration-testing guidance as supplemental method context.
    Acceptance test
    No sentence makes an older information supplement sound like current PCI DSS text or silently translates former requirement numbering.
  3. W/?03
    WACK-PT-DECISION-0003acceptance case

    Which Stripe integration mode should anchor the fictional acceptance case?

    Decision needed
    Confirm hosted Checkout, embedded Checkout, or another named mode and enumerate the customer-controlled session, key, webhook, redirect, administration, and failure-path capabilities retained in that fiction.
    Acceptance test
    The case is precise enough to test and teach, but never claims that the provider name establishes the customer’s scope or compliance result.
  4. W/?04
    WACK-PT-DECISION-0004issuing case

    Which Lithic capabilities are enabled in the fictional issuing case, and which are deliberately unavailable?

    Decision needed
    Name the display, API, key, event, dashboard, support, program, and environment capabilities used by the teaching case, including the negative capability assertions it expects to prove.
    Acceptance test
    The narrow embedded-display path cannot conceal a broader PAN-capable interface, credential, administrative path, or production eligibility fact.
  5. W/?05
    WACK-PT-DECISION-0005paper architecture

    Should PCI DSS scope and penetration-test scope be explained in parallel sections or through one integrated graph?

    Decision needed
    Choose the teaching structure and preserve an explicit distinction between system applicability, candidate test population, authorized execution, and the conclusion each result can support.
    Acceptance test
    A reader cannot mistake a penetration-test target list for the complete PCI DSS scope or use scope inclusion as proof of executed testing.
  6. W/?06
    WACK-PT-DECISION-0006provider restrictions

    Which provider testing restrictions can be described generically, and which require customer-specific contract, account, or authorization evidence?

    Decision needed
    Separate public provider rules from tenant-specific permission, contractual restriction, support authorization, and evidence-availability facts.
    Acceptance test
    An unavailable test position becomes a named limitation or alternate-evidence plan rather than silently becoming covered.
  7. W/?07
    WACK-PT-DECISION-0007public safety

    Which negative-path tests are safe to describe publicly without turning the paper into an exploitation recipe?

    Decision needed
    Set a publication boundary for propositions, evidence patterns, and defensive validation while reserving actionable exploit detail for authorized rules of engagement and controlled workpapers.
    Acceptance test
    The paper teaches how to ask and evidence the security question without supplying unnecessary operational instructions for abuse.
  8. W/?08
    WACK-PT-DECISION-0008authority boundary

    Which conclusions belong to assessor judgment, and which remain practitioner method?

    Decision needed
    Classify the major conclusion types and identify where assessed-entity representation, assessor evaluation, and compliance-accepting-entity acceptance remain separate decisions.
    Acceptance test
    No practitioner method impersonates PCI SSC language, an assessor’s fact-specific conclusion, or a compliance-accepting entity’s acceptance decision.

What this does not do: public visibility does not record a practitioner decision. The exact canonical digest must still be dispositioned through the owner-local W/ Operations Desk.

What this release proves

The research structure exists. The technical position is still at the gate.

This inventory separates PCI SSC authority, provider-published product facts, architecture evidence needs, and practitioner analysis. It does not determine scope, testing sufficiency, provider or customer compliance, or a compliance-accepting entity's decision.

Source posture

Authority first. Product facts second. Customer conclusion last.

01 / Current standard

PCI DSS v4.0.1

The current PCI DSS document library supplies the normative baseline. The research does not rewrite it.

Open PCI SSC document library
02 / Supplemental guidance

Penetration Testing Guidance

The 2017 PCI SSC paper informs methodology and rules-of-engagement questions; it does not replace or supersede the current Standard.

Open PCI SSC guidance
03 / Provider facts

Exact service and interface

Checkout, key, and webhook documentation establishes named product behavior—not the customer's assessment result.

CheckoutAPI keysWebhooks

Next governed move

Review the exact digests—then earn the paper.

Practitioner reviewed / 2026-09-08. Practitioner reviewed / 2026-09-09. The Owner Desk keeps these as separate digest-bound decisions. Both must be current before the 3,500–5,000 word publication, DOCX, light PDF, dark PDF, carousel, and training derivatives move forward.

Return to the roadmap
Search