Difference between trivy fs and trivy rootfs

[ghost]

What is the difference between trivy fs / and trivy rootfs /? They seem to produce different results but are scanning the same directory.

[afdesk]

@frederickalcantara thanks for your interest in trivy!

these commands scan different languages/files. you can take a look here:
https://aquasecurity.github.io/trivy/v0.24.4/vulnerability/detection/language/

[ryanbrainard]

@afdesk Any reason these two aren't combined into one command?

[afdesk]

fs and rootfs are used for different cases.
Read more here: fs and rootfs

[itaysk]

@AnaisUrlichs this sounds like a good documentation enhancement, to explain the rationale behind the two targets

[rhino5oh]

Nearly 3 years later and the documentation is still horrendous on the difference between fs and rootfs.

fs aka filesystem is to "Scan your local projects". What is a 'local project'? Why is it called 'filesystem' then? Can I/Should I use it on a running VM to scan the root of the filesystem, e.g. trivy fs /?

rootfs simply says "Rootfs scanning is for special use cases such as: Host machine, Root filesystem, Unpacked filesystem"

If you click on "Root filesystem", the only example is how to "Embed in Dockerfile". OK? then why is it called root filesystem? Can I/Should I use it on a running VM to scan the root of the fiilesystem, e.g. trivy rootfs /?

What is the actual difference between these two commands?

trivy fs /
trivy rootfs /

Because right now, I'm getting vulnerabilities when scanning the SBOM generated using rootfs that I am NOT getting when scanning the SBOM generated using fs on the same machine. What is going on here? Which one should I use on a running VM if I want to scan everything starting from / to generate an SBOM?

I saw the "Language-specific Packages" page (linked to above), but its strange to me. For example, when looking at NodeJS...why would you look at package-lock.json with fs, but not with rootfs (it instead looks at the regular package.json file)? package-lock.json is a snapshot of what is actually installed. So rootfs is looking at what could potentially be installed (with npm install), instead of what is actually there (the lock file)? Very strange.