Payment-handling components of the deployment are network-isolated by a control that selects them, receive gateway secrets that no other component gets, and log to a sink of their own. No AI engine is involved: the verdict is reproducible from the manifests alone.
Inputs
Deployment manifests of the checkout, parsed (not pattern-matched): docker-compose (services, networks, env_file, environment, secrets, logging, network_mode, and the per-service .env files they reference), Kubernetes and Helm YAML (workloads with their labels, namespace, container env and secret references; NetworkPolicy, Cilium/Calico policies, Istio AuthorizationPolicy and Sidecar), Terraform/HCL (ECS services and task definitions with container definitions, Lambda, EC2, App Runner, Cloud Run, Kubernetes deployments; vpc_config, network_configuration, security groups, subnets, log configuration), CloudFormation/SAM (YAML or JSON), serverless.yml (functions, provider environment and vpc), SST configuration (sst.config.ts components with environment, link and vpc) and Dockerfiles (ENV/ARG). A component is a payment component when its name (service, workload, resource, function or container) says payments or names a gateway, or when its environment, secret references or env file inject a gateway secret variable. Paths listed in excludes (test, spec and tmp files, __tests__, __mocks__, fixtures, test, tests and audit-scripts folders) are never analysed. Nothing of the checkout is executed.
Decision rule
Not applicable when the checkout has no deployment manifest, or when the manifests declare no payment component and inject no gateway secret anywhere. FAIL (HIGH, with the line) when a gateway secret variable, secret reference or env file entry is injected into a non-payment component (a provider-level environment of serverless.yml shared by every function counts); when an env file is shared by a payment service and a non-payment service; and when a payment component has no isolation control SELECTING it while at least one other component shares the deployment — a NetworkPolicy, Cilium/Calico policy, Istio AuthorizationPolicy or Sidecar whose selector matches its labels in its namespace (an empty selector covers the namespace), a Kubernetes namespace no non-payment component uses, a compose network attached to payment services only (or network_mode none), a VPC config, security group, subnet or network configuration on the Terraform/CloudFormation resource, a function-level or provider-level vpc in serverless.yml, a vpc on the SST component. A logging sink (awslogs-group, log group, fluentd/syslog/loki/gelf/splunk address, tag, else the driver) shared by a payment component and a non-payment component is MEDIUM (blocks in this Extended suite). A deployment whose only component is the payment component has nothing to segment from: not reported, stated in the summary. PASS when every payment component is isolated, receives its own secrets and its own sink; the summary names the control per component. Not judged by this check (declared): the isolation of a Dockerfile-only component (an image is not a deployment), what a NetworkPolicy allows once it selects the component (ingress and egress rules), secrets baked into image layers (gateway-secrets-out-of-repo), a shared env file whose content is not in the checkout, cloud-side controls outside the manifests, and Helm templates whose values are rendered at deploy time.
Type
deterministic
1.1.0: deterministic: the rule runs over the static analysis kit (tokens, function units, calls, imports, routes) with no AI engine; exact decisionRule and languages published; not-applicable with the reason when the checkout gives nothing to evaluate. Manifests are PARSED (light YAML with key lines, JSON, light HCL with jsonencode, Dockerfile ENV, referenced .env files) into a component model; payment component = named for payments, else the holder of gateway secrets; isolation = a control that SELECTS it (NetworkPolicy/Cilium/Istio selector matching labels, own namespace, compose network attached to payment services only, vpc_config/security group/subnet, function or provider vpc, SST vpc); a gateway secret in a non-payment component or a shared env file = HIGH, a shared logging sink = MEDIUM; a single-component deployment has nothing to segment from. Not judged: Dockerfile-only isolation, the content of policy rules, Helm templating. (1.0.2: never analyses temporary files (*.tmp.*; spec.excludes follows AUDITOR_ANALYSIS_EXCLUDES). (1.0.1: never analyses test, spec, fixture and mock paths nor the auditor's own scripts (spec.excludes = AUDITOR_ANALYSIS_EXCLUDES); a fixture-looking secret (sk_test_, example, dummy) in real code is LOW, informative; every model call stays under the engine prompt cap (spec.promptMaxChars = AUDITOR_AI_PROMPT_MAX_CHARS): assess mode sends the candidate set in parts and aggregates the verdicts (a HIGH in any part is a FAIL, an unsatisfied part is a FAIL).))
// manifests are PARSED (light YAML by indentation with the line of every key, JSON, light HCL with blocks/attributes/jsonencode, Dockerfile ENV) into one component model:
const PAYMENT_NAME = /(?<![a-z])pay(?:ments?|s)?(?![a-z])|payment|billing|checkout|stripe|paypal|adyen|braintree|mercadopago/i; // or a gateway secret in its environment
// isolation = a control that SELECTS the component: NetworkPolicy podSelector matching its labels | namespace of its own | compose network attached to payment services only | vpc_config / security group / subnet on the resource | function or provider vpc
// payment component without one (and another component in the deployment) -> HIGH; gateway secret in a non-payment component -> HIGH; env_file shared -> HIGH; logging sink shared -> MEDIUM; no manifest or no payment component -> not-applicable
The full script is disclosed on request in a read-only viewer (never published on GitHub); the attestation binds to this exact hash.
