Scan a buildpack-built image the same way as any OCI image, by its digest, because that is what it is. What differs is the fix path: operating system findings usually come from the run image and can be addressed with a rebase, while application findings come from your code and dependencies.
What a buildpack image is made of
The Cloud Native Buildpacks documentation describes a builder as an OCI image that holds an ordered set of buildpacks, a build-time base image, a lifecycle binary and a reference to a runtime base image. A build runs buildpacks against your source to produce a runnable OCI image. The run image is the base for the app image.
So the final image has two origins: the run image supplies the operating system layer, and the buildpacks and your source supply the runtime and application layers.
Scanning is the same, reading is different
Any scanner that reads OCI images can scan the output. There is no special mode to ask for. When reading results, sort findings by layer origin:
| Finding is in | Likely origin | Usual fix |
|---|---|---|
| OS packages | Run image | Rebase onto an updated run image |
| Language runtime | A buildpack | Update the buildpack or builder |
| Application libraries | Your dependency files | Update the dependency and rebuild |
What rebase does
The documentation explains that rebase lets app developers or operators rapidly update an app image when its runtime base image has changed. Instead of rebuilding from source, the tooling swaps the base layers under your application layers. That makes OS patching faster, since you do not need to run the whole build.
Rebase only changes the base layers, so scan the result afterward rather than assuming it worked. Read the rebase documentation for your platform before you automate it.
A routine that works
- Scan the image by digest after each build.
- Group OS findings and check whether a newer run image exists.
- If it does, rebase, then scan the new digest and confirm the findings are gone.
- Handle application findings through your normal dependency update flow.
- Rescan deployed digests on a schedule, since new CVEs appear after release.
Run image mirrors
The docs also describe run image mirrors, which are alternate locations for a run image used during build or rebase. If you use mirrors, make sure the mirror is updated at the same pace as the original, or a rebase may pull an older base than you expect. Record which run image digest each app image used.
Common mistakes
- Assuming the builder's name tells you the patch level. Check the digest.
- Scanning only source dependencies and missing the OS layer.
- Rebasing without scanning afterward to confirm the fix landed.
A worked example: an OS finding and a library finding
A team builds a service with buildpacks and scans the result. The scan returns two notable findings.
| Finding | Layer origin | Who acts | How |
|---|---|---|---|
| A flaw in an operating system library | Run image | Platform team | Move to an updated run image and rebase |
| A flaw in a web framework library | Application dependencies | Service team | Update the dependency and rebuild |
The service team tries to fix the first by editing its own dependency file and sees no change. That is the typical confusion. The operating system library comes from the run image, so the right action is on the base, not on the app.
Because the documentation describes rebase as a way to update an app image when its runtime base image has changed, the platform team can publish an updated run image and let every service pick it up by rebase, without a full rebuild from source in each repository.
Step by step: a patch routine for buildpack images
- Inventory which builder and run image each service uses. Record digests.
- Scan every app image by digest.
- Split findings by origin using the table above.
- For OS findings, check whether a newer run image exists and whether it fixes the finding.
- Roll the updated run image out by rebase, service by service, starting with a low risk one.
- Rescan each new digest and compare with the old result.
- Handle library findings through your dependency update flow.
- Record the run image digest used for each release.
Testing a rebase before you roll it everywhere
A base update can change behavior, so test it.
- Run your normal integration tests against the rebased image.
- Compare the scan results of the old and new digest, and check that new findings did not appear.
- Roll out to a canary first, then widen.
- Keep the old digest available for quick rollback.
Questions for a vendor
- Can you scan an OCI image from my registry with no special buildpack knowledge?
- Do findings show which layer introduced a package, so I can tell run image from application?
- Can you report the base image digest for each scanned image?
- Can you compare two digests and show what changed?
Common mistakes
- Treating all findings as the app team's job.
- Pinning to a run image tag and never updating it.
- Running a rebase without a rescan.
- Using mirrors without checking that the mirror is current.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how findings split between operating system packages and application packages.
Where Safeguard fits
Safeguard scans image contents and dependencies and can open fix pull requests for application dependencies when you enable that. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Do I need a special scanner for buildpack images?
No. The output is an OCI image, and standard image scanning applies.
Does rebase remove the need to scan?
No. Scan the new digest afterward to confirm findings are gone and that no new ones appeared.
Who should own the run image?
Usually a platform or base image team, so one group updates it and every service benefits. App teams own their own dependencies.
Sources
Last reviewed: 19 October 2026.
