Clean up downloaded images from daemons

[houdini91]

What would you like to be added:
Introduce an automatic “cleanup” step that runs after every Syft/Stereoscope scan, deleting any image layers or temp data the providers created—so disk space never accumulates between runs.

Why is this needed:
Running syft scan or syft attest against images pulled from Docker or Containerd leaves those images—and their layer files—inside the local daemon. On CI runners this causes disk usage in /var/lib/docker/overlay2 (or the Containerd content store) to grow continuously, eventually filling the filesystem. Previous discussions (e.g. stereoscope #161, syft #416) covered temporary directories, but did not address the persistent layers created by daemon-based providers.

Additional context:
Patches are intended as a proof of concept: feel free to ignore them, cherry-pick pieces, or push changes directly onto the branches if there’s a cleaner way to fold this into the projects’ architecture.

Draft Suggestion

• Suggest Image cleanup flow #3986
• Suggest Image cleanup flow stereoscope#413

---

Syft patch

Area	High-level change
Lifecycle support	Introduced a new Cleanup(ctx) method to the source.Provider interface.
Central helper	Added syft.CleanupSource() to iterate over all candidate providers and call their Cleanup.
CLI wiring	Updated getSource() to return (src, cleanupFunc, err); syft scan and syft attest now defer both src.Close() and cleanupFunc().

Stereoscope patch

Area	High-level change
Interface	Added Cleanup(ctx) to image.Provider.
Docker daemon provider	Implemented Cleanup by calling Docker’s ImageRemove to delete the analysed image.
Containerd daemon provider	Implemented Cleanup via ImageService().Delete() to purge the image from Containerd.
Other providers (OCI dir/tarball/registry, SIF, etc.)	Implemented no-op Cleanup that just logs a debug message—these providers don’t leave persistent state.
Common code	Updated provider factories and helper functions so all providers now satisfy the new interface.

---

Together, these two patches establish a complete create → use → cleanup lifecycle across both projects.

[houdini91]

Hope this makes sense ..

[houdini91]

I am concerned about the cleanup operation potentially removing images that were already present and not explicitly pulled by Syft. If you want to continue with this suggestion we may consider an approach to retain this context, ensuring cleanup targets only images pulled during Syft operations.

[AustinAbro321]

Not sure if my issue relates or is a separate problem anchore/stereoscope#387, but stereoscope leaves behind extra layers when it runs on an OCI directory

[kzantow]

Hey @houdini91 the biggest concern we have is exactly what you pointed out: we don't want to blindly delete the image, as this is often something built locally that will be used after it's scanned with Syft. However, we do explicitly issue a pull and track the progress in the GUI, so if we had some flag to indicate that syft caused the image to download, we might be able to use that knowledge to determine whether or not to delete when we're done.

In the meantime, if you are intending to download things from a registry, you can explicitly use the --from registry flag to cause Syft to directly download the image rather than use the daemon.

[houdini91]

Great—we’re on the same page.

Latest approach

• Dropped any changes to the Provider interface.

• When constructing the image.Image, I now pass an optional provider-level cleanup callback.

  • The callback is only populated if the image had to be pulled.
  • If the image already existed locally, the callback remains nil, so we leave the file system untouched.

Repo updates

• stereoscope – the provider now attaches the cleanup function directly to the Image instance when needed.
  PR: Sh 3985 Daemon Cleanup Pulled Image feature flag (disabled by default) stereoscope#417
• syft – during its normal cleanup phase, Syft simply invokes any cleanup function registered on the Image.
  Actually NO change is needed on syft it calls source.Close already which in turn calls the image cleanup internal callback.

I have not aligned the syft to my fork in the draft PR.

You can try the draft out by running syft

docker image rm alpine:latest
syft scan alpine:latest -v # Expect cleanup Log at the end.
syft scan alpine:latest -v # Expect cleanup Log at the end (because it was cleaned by prev command)
docker pull alpine:latest
syft scan alpine:latest -v # No cleanup should be done, no log at the end of the run.

[houdini91]

@kzantow Any thoughts on this direction?

[kzantow]

Hey @houdini91 -- I think what you have in the stereoscope PR looks pretty good. There shouldn't be any Syft changes required (I see you noted that in your last comment, but I followed links to this PR: #3986). My only question is whether we need it to be configurable, in which case we would need a syft follow-on, and if we would potentially want to default to the current behavior of not deleting these images (there are some valid reasons to want to keep images, for example if you're running repeatedly, but I think the default of deleting images we initiated the pull for makes the most sense). I'll run this by the team, but overall this looks a lot like I would expect -- maybe you can get the DCO fixed in the meantime? Thanks for looking at this!