How do you trigger a vulnerability rescan after a deploy?

To rescan after a deploy, trigger a job from your deployment event, resolve the exact image digest now running, and scan that digest against current advisory data. Compare the result with the build time scan. The difference tells you what was published since the build, or what the build did not test.

Why scan again after a deploy

A pull request scan checks what you intend to ship. A deploy rescan checks what you did ship. They can differ for three reasons:

• Days passed between build and deploy, and new advisories arrived.
• The deployment pulled a tag that moved to a different image.
• A base image or sidecar was injected at deploy time.

Steps

1. Pick the deploy signal. On GitHub, the deployment_status event fires when a deployment status is provided by a third party, and a status of inactive does not trigger a workflow (events reference). In other systems, use the pipeline's post deploy stage or a webhook from your deploy tool.
2. Resolve by digest, not by tag. Tags can move. Ask the cluster or registry for the digest of the running image and scan that.
3. Scan. Run the same scanner and policy you used at build time so results are comparable.
4. Diff. Compare findings against the build time record. Report only new ones.
5. Decide. If a new critical finding has a fix, open a ticket or a fix PR. If a policy says block, roll the deploy back or pause the rollout.
6. Store the result. Attach it to the deployment record. It becomes evidence of what you checked and when.

on:
  deployment_status:

jobs:
  rescan:
    if: github.event.deployment_status.state == 'success'
    runs-on: ubuntu-latest
    steps:
      - run: ./scripts/scan-digest.sh "$IMAGE_DIGEST"

What a deploy scan will not do

It does not replace scheduled rescans. Once deployed, an image keeps ageing. A scan at deploy time is a snapshot, and tomorrow's advisories need the nightly job. See how often to rescan deployed container images for that side.

It also does not see runtime behaviour. If you need to know what is executing, that is a different tool class.

Try it yourself

In the demo, scan an image and read how findings are grouped by layer and package. Look for which findings come from the base image rather than your own code.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• GitHub: events that trigger workflows

Last reviewed: 19 October 2026.