This message was deleted.

I would give up on trying to reverse engineer that entirely and exclude the image filesystem (the location where docker/containerd stores container layers) from your scans. If you want to do vuln scanning on container images, use a tool that scans container images.

That's the right answer, but it's not the answer that the security people who the system owner has to appease will accept. If I don't do it, he will and from a combo of me having a bit more skin the game and not wanting to be a pest to someone whose computers I'm basically squatting on anyway, that's where I'm sadly going to have to poke around and find some answers.

I think you’d have to poke around in the bbolt database file and try to engineer a reverse lookup of directory to image layer to image. It is going to be a huge waste of everyones time and even if you do it there will be no actionable outcome. “Yes its from an old tag of an image that something is dependent on. Yes I’ll get around to updating it eventually. No you can’t delete it, I still need to use it now.”

My problem is a bit weirder, so I might get something useful. This morning I spent a few hours where one of the vulnerabilities was an image I knew what it was from the directory naming and a coworker had deleted it yesterday and there was no trace of it that I saw but the directory was still there.

docker container prune

,

docker image prune -a

, &

docker system prune -a

didn't get rid of the directory. K3d was still running and it wasn't in a running pod, but after killing my k3d cluster and doing another image prune -a it was finally gone...along with a couple hundred other images and I only had two left in the systems' local cache. So I'm trying to get something to let me match what's what so I can at least know how things are targetted scan-wise and go around pulling strings to find out what needs to let go for specific items to be able to get rid of them.