Verification has three layers.
The package or image digest matches the advisory you cited, or the binary is an upstream build at or above the fixed release for that branch.
The process start time is after the install. For FPM, that is the master process. For mod_php, that is the Apache children. For containers, that is the new pod or task, not the old one in Terminating.
A request through the public hostname hits that process. Use an application route you understand. Watch the error log during the request for fatal errors that would mean the new build is up and the app is not.
Document the three layers in the ticket. If any layer fails, the change is not finished. A clean historical log from before the change proves nothing about the new binary.
Scanners that flag Ubuntu’s 8.3.6 string after USN-8948-1 need the package version attached to the exception. Do not “fix” the scanner by replacing a good backport with an unpackaged tarball.