Assume we have a directory containing an unpacked container image in the target directory:

$ echo "FROM alpine" | docker build -o type=local,dest=target

We could also create target.tar out of this same target directory:

$ tar cf target.tar target/*

If we scan this as a directory source, we can note a couple warning message that indicate that syft is scanning directories that weren't intended by the user:

$ syft -o spdx-json=out.json dir:./target -v
[0000]  INFO syft version: [not provided]
[0000]  WARN unable to access path="/bin/busybox": lstat /bin/busybox: no such file or directory
[0000]  WARN unable to access path="/run/brltty": open /run/brltty: permission denied
...

These warnings start to appear because of the symlinks /bin/tar to /bin/busybox and /var/run to /run. I would expect these contents to be resolved entirely within the provided path, but it seems like this behavior is intentional, though I'm not sure of the context: see https://github.com/anchore/syft/blob/main/syft/source/directory_resolver.go#L530-L532 introduced in #442.

What's even weirder to me is this behavior is identical even when scanning file:target.tar (since it shares the same directory resolver code, after unpacking it into a tmp directory):

$ syft -o spdx-json=out.json file:./target.tar -v
[0000]  INFO syft version: [not provided]
[0000]  WARN unable to access path="/bin/busybox": lstat /bin/busybox: no such file or directory
[0000]  WARN unable to access path="/run/brltty": open /run/brltty: permission denied

After raising on the community slack, @kzantow suggested a possible new source type, root-dir (or similar), where all content could be resolved internally, additionally, with the same cataloguers as the image: source (since those also differ).