Hi @0xnishit
Sorry, I thought I covered that. As I explained, syft needs arbitrary file access.
None of the supported or unsupported ‘known categories’ cover what syft does. In the section ‘criteria’ for things that might need classic, I think this line covers it best: ‘access to files on the host outside the snap’s runtime (eg, /usr)’
Developers and enterprises use syft in various ways. Some will use it to scan remote and local docker containers. Others will use it to scan tarballs of filesystem exports of containers. The big one that fails is scanning arbitrary filesystems or directories.
If you run syft and look at some examples, random files, and directories are well documented as standard use cases for the application. We cannot know in advance where people put their code repos, containers, etc.
You can also explicitly specify the scheme to use:
syft scan docker:yourrepo/yourimage:tag explicitly use the Docker daemon
syft scan podman:yourrepo/yourimage:tag explicitly use the Podman daemon
syft scan registry:yourrepo/yourimage:tag pull image directly from a registry (no container runtime required)
syft scan docker-archive:path/to/yourimage.tar use a tarball from disk for archives created from "docker save"
syft scan oci-archive:path/to/yourimage.tar use a tarball from disk for OCI archives (from Skopeo or otherwise)
syft scan oci-dir:path/to/yourimage read directly from a path on disk for OCI layout directories (from Skopeo or otherwise)
syft scan singularity:path/to/yourimage.sif read directly from a Singularity Image Format (SIF) container on disk
syft scan dir:path/to/yourproject read directly from a path on disk (any directory)
syft scan file:path/to/yourproject/file read directly from a path on disk (any single file)