the agent's patch validation only re-ran the scanner on the lockfile - the deployed image still had the old layer

TL;DR

The lockfile is a promise; the deployed image is the reality. The agent validated the promise and declared victory while production still ran the old layer. Rebuild the image, rescan the actual deployed digest, and close the finding only when the artifact evidence shows the fix. Validation must follow the deploy, not the commit.

the agent's patch validation only re-ran the scanner on the lockfile - the deployed image still had the old layer

Use this when

• A CVE is marked fixed but the running image still flags on rescan.
• Validation steps run pre-deploy (on the repo or lockfile) and never post-deploy.
• Image builds are cached and the "new" image reused the old layer.

Not for this skill when

• There is no image (serverless, SaaS, lockfile-only services). Then lockfile validation plus a dependency-tree check is the right scope.
• The deploy genuinely shipped the fixed layer and the scanner agrees. Then validation worked.

Steps

1. Rescan the currently deployed image digest right now. Verify: you see whether the CVE is actually gone in production or still present.
2. Rebuild the image without layer cache for the changed stage (or verify the digest changed after the bump). Verify: the new digest differs from the old and the layer history shows the updated package.
3. Deploy the rebuilt image through the normal pipeline. Verify: the orchestrator reports the new digest running.
4. Rescan the deployed digest and confirm the finding is cleared. Verify: the specific CVE no longer appears for that digest.
5. Move the validation gate to post-deploy: the finding closes only on a clean scan of the deployed digest, never on a lockfile scan. Verify: the agent's close-finding tool requires a digest-scoped clean result.

Variant phrasings

patch validation lockfile only

The short phrasing.

deployed image still vulnerable after fix

The symptom search.

validated lockfile not the image

The scope phrasing.

Compatibility: Docker, OCI images, any build-then-deploy pipeline; the "validate the artifact" rule is universal.

Why it happens

The agent's mental model ended at the code change: lockfile updated implies fixed. But container deploys add two more steps (rebuild, redeploy), each of which can silently keep the old bits. The validation checked the earliest artifact in the chain instead of the last one.

Edge cases / pitfalls

• Layer caching is the usual culprit: a cached layer means the "rebuild" produced the old digest. Verify digests changed, not just that a build ran.
• Rolling deploys leave old and new running side by side; validate per-digest and only close when no running digest still flags.
• If the pipeline cannot rescan post-deploy yet, keep the finding open with "fix merged, deploy pending" rather than closing early.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_qlwNFJPKBLQHITJalRSN3A