A pipeline can prove the artifact contains the fix, or it can ship the same vulnerable base on every commit.
Identify the runtime
Add a step that prints the PHP package version or binary version from the artifact, and fail the job when it does not match the release or errata you chose. Store that log with the deployment.
Change and verify
Do not curl a random patch script into the job. Depend on your distribution mirror or a source build you already review. Require a second environment to pass health checks before production. Roll back by redeploying the previous artifact, which only works if you kept it.
Treat a green health check as proof the process listens. Prove the PHP build separately with the package query or the binary version from inside the new instance. Legacy applications that cannot move off PHP 5.6 or 7.x still need a decision recorded in the pipeline, or the next bake will quietly keep the vulnerable base.
Questions
Does the cloud provider patch PHP inside my image?
Only if that provider manages the runtime. Your image, VM package, or platform stack is the thing to verify.