PHP Site AuditVerification
How can a site owner confirm a PHP patch deployment?
Close a PHP patch task when the owner can match an authoritative vendor advisory to the package or image installed on every in-scope serving workload, confirm the relevant workers or containers now use it, and pass agreed application checks. Keep externally observable response results separate from host-only package evidence. A scanner can report what it saw publicly; it cannot certify patch contents, cover hidden services, or guarantee security.
Define workload scope up front
A good ticket names the exact domains and environments, production origins or hosts in scope, PHP handler or managed runtime, package stream, vendor advisory, and who can provide each piece of evidence. Include web requests, CLI tasks, queue workers, scheduled jobs, and persistent application workers when they use separate runtime deployments. The evidence should connect the advisory to the installed package or image and then connect that artifact to the process actually serving work.
Match vendor evidence to deployed artifacts
Ask the operator for the vendor and OS or platform release, package revision or image digest, advisory/CVE mapping, deployment time, and restart/replacement confirmation. For a backport, require the distribution or provider’s record for the exact package stream. A dashboard saying ‘current’, a shell command from an unrelated account, or a public version banner may be useful leads but does not by itself establish that the relevant production worker contains the fix.
Classify each workload accurately
Mark a workload fixed only when the package evidence, target mapping and process activation all agree. Mark it unresolved when the vendor record says the package is affected or a required deployment step has not occurred. Mark it unknown when you cannot identify the package source, host coverage, or runtime behind a service. These categories prevent ‘not observed’ from being reported as ‘fixed’ and make it clear which owner needs to respond.
Track evidence in a per-workload ledger
A practical ledger row can contain hostname/workload; environment and region; PHP SAPI or platform; package/image and revision; advisory reference; process restart or rollout timestamp; application test result; evidence owner; and status. Keep host-only evidence in the operator record and point from the owner-facing ticket to its reference.
Run acceptance checks and state limits
After attaching operator evidence, run the owner-selected smoke checks: homepage and key routes, authentication where applicable, a representative form or transaction, and background or scheduled work. Review logs and service health for new failures. External checks can report availability, TLS or visible technology signals, but cannot read the package database, inspect private endpoints, verify backport contents, cover every origin, or determine whether a host was compromised.
Close with a concise statement of what is demonstrated and what remains outside scope. For example: ‘The provider supplied advisory and package evidence for the named production pool; the pool was replaced at the recorded time; public route and owner-selected checkout checks passed. The separate reporting worker was not included and remains unknown.’ Do not call a public scan a certificate, a clean response a security guarantee, or a passing test a substitute for server-side evidence.
Agree on an observation period and responsible contact for errors after rollout. Where a service has multiple origins, regions, or scheduled workloads, require each owner to return evidence in the same ledger format. Keep a timestamped copy of the package or image reference because an unqualified statement such as ‘updated’ may become difficult to verify after the next automated deployment.
Common questions
What is the strongest patch evidence?
A vendor advisory matched to the exact installed package or image, plus confirmation that the serving process uses that artifact.
Can an outside website scan close the task?
No. It can provide bounded public observations but cannot inspect server packages or prove all runtimes are covered.
What if one worker group is not confirmed?
Keep that scope unknown or unresolved and name its owner in the closure record; do not generalize from other pools.