The PHP update is available.
How do you prove the exposure is closed?

1. Find the PHP that actually serves requests

Build a workload list across the accounts, Regions and environments in scope. Include the application owner, instance or container identity, runtime source, package or image revision, and evidence time. Reconcile scanner findings with deployment inventory so an unscanned workload stays visible as a gap.

Distinguish three observations:

• Built: the approved image or package contains the vendor fix.
• Installed: that artifact is present on the intended workload.
• Serving: the process handling application requests uses the fixed runtime.

A shell version check alone may describe a different PHP installation from the web service. Collect evidence through approved operational tooling and connect it to the actual serving process. Keep diagnostic output private.

Cover running replicas, scheduled workloads and replacement capacity. Update the source used for future deployments and scaling, then verify a newly started workload too. Record anything you cannot inspect, with its owner and next check.

2. Prioritize with reachability and permissions

For each affected workload, ask who can reach its PHP request handlers, which customer journeys depend on it, and what data or cloud operations its identity can access. Include internal paths and direct origins alongside the public front door.

Use this context to sequence urgent work and review temporary containment. A private subnet or filtering rule is context, not evidence that PHP is patched. Record containment separately, with an owner, expiry and remaining exposure. If a workload role is broader than necessary, prepare a separate permission review with its own approval and application checks.

3. Approve the exact update and recovery plan

Name the service owner and administrator authorized to approve the change. The proposal should identify the exact action, target workloads, package or immutable image, relevant configuration changes, current-state preconditions, rollout stages and acceptance checks.

Keep administrator approval separate from execution. Before dispatch, the execution boundary must recheck the action, target, artifact, conditions and approval validity. Reject revoked or expired approval and changed or stale proposals; obtain renewed review before proceeding.

Agree what happens if the update breaks a required workflow. A rollback must not silently restore a known vulnerable runtime. Review a fixed recovery candidate or separately authorized containment, including service impact and outstanding risk. Record uncertain or partial deployment effects before retrying.

4. Let Green execute the approved plan

In Cotton’s target workflow, Green would apply the supported update through a scoped deployment integration. The administrator reviews the concrete plan; Green handles its approved stages and records the effects.

Execution needs separately granted permissions limited to the intended actions and resources. Read access and an approved plan alone cannot supply those permissions. Start with the agreed rollout stage, inspect its results, then continue only while the approved conditions hold.

Stop progression on a service regression, failed precondition or uncertain effect. Reconcile partial state and request review for any recovery action outside the approved plan. Green’s completion report goes to the verifier; it does not establish closure.

5. Require security evidence and real application checks

Collect fresh runtime and fleet evidence after deployment. Retain the vendor advisory, artifact identity, serving-workload observations and any scanner reassessment, including what each source actually inspected. A successful pipeline run establishes that a deployment step completed; closure needs the resulting state.

Test the customer work that must survive: login, an upload or import, an API transaction, a scheduled job, or another journey affected by your change. Establish a working baseline and compare the result after rollout. A health endpoint alone may miss the operation your customer needs.

Any adversarial check needs explicit targets, methods and stop conditions. A failed exploit attempt cannot prove that a runtime is fixed. Give a separately governed verifier access to inspectable evidence and authority to withhold closure. Missing security evidence, an unknown replica or a failing required service check leaves the outcome unresolved.

An AWS example: the image is fixed, one task is still unknown

Synthetic example of the intended Cotton workflow. A customer portal runs PHP in an ECS service behind a load balancer. Its task role reads customer documents from S3. An administrator approves a supported image update and its exact rollout plan. Green executes the controlled rollout; a separately governed verifier checks the serving runtimes, login and document retrieval.

If document retrieval fails, investigate the service regression before closure. If the role also has unnecessary access, track that separately. Neither the PHP update nor a passing retrieval test establishes least privilege.

Where Cotton’s intended workflow fits

Cotton is being built to connect investigation, approved execution and outcome evidence. Blue would combine supplied runtime findings with AWS reachability, permissions and ownership. Red would test an agreed adversarial path within explicit limits. Green would prepare and execute supported updates after administrator approval. Separately governed verification would assess security and service results before closure.

This is the target experience. Cotton currently provides concepts and synthetic demonstrations; live AWS connections and PHP update integrations are not available yet. Proposed AWS configuration reads do not inspect installed PHP packages or grant patching access. This workflow requires runtime evidence, supported update integrations, scoped execution permissions and validation.

Explore the same evidence pattern in the worked cloud-remediation case. Use the evaluation checklist to challenge approval, execution and missing-evidence behavior.